Design

Abstraction and Implementation

| Jorge Arango

In his book Where the Action Is, Paul Dourish surfaces a key distinction in software: that of the user interface as an abstraction of the implementation details that underly it:

The essence of abstraction in software is that it hides implementation. The implementation is in some ways the opposite of the abstraction; where the abstraction is the gloss that describes how something can be used and what it will do, the implementation is the part under the covers that describes how it will work. If the gas pedal and the steering wheel are the abstraction, then the engine, power train, and steering assembly are the implementation.

Designers often focus on this abstraction of the system — the stuff users deal with. As a result, we spend a lot of cycles understanding users. But for the interface to be any good, designers must also understand the implementation — the system’s key elements, how they interact with each other, its processes, regulation mechanisms, etc.

Sometimes, as with a new (and perhaps unprecedented) system, this implementation itself is in flux, evolving subject to the system’s goals and the needs of the people who will interact with the system. That is, it’s not all front-end: the implementation is part of the design remit; both the implementation and its abstraction are the object of design.

Design Requires Trust

| Jorge Arango

Last week I wrote about something I learned from Brad Stone’s The Anything Store, a history of Amazon.com. It’s enlightening to read about the genesis and evolution of one of the most important information environments in the world. Here I’ll share another insightful anecdote from the book, which has to do with the design of the first Kindle.

Kindle is much more than a product; it’s an ecosystem. The product wouldn’t have succeeded if enough of that ecosystem weren’t built out at launch. It wasn’t enough that the team delivered a beautiful, useful, usable reading device; many other pieces needed to be in place on day one. For example, there had to be e-books available for the device. Amazon CEO Jeff Bezos set a target: 100,000 titles for launch. His team had to convince publishers to convert and offer their books to a new format.

Customers also needed a way to get those books onto their devices. The obvious precedent was the iPod/iTunes/iTunes Store ecosystem, which required that users connect their devices to a computer where they’d purchase and download music files. Because of that decision, the iPod could be simpler since it didn’t need a built-in communication stack.

However, this also made the process more complicated for users, since it required that they have access to a computer and know how to set the whole thing up. As always with design, it was a tradeoff. Mr. Bezos wanted Kindle users to bypass this complexity by buying and downloading books from the device itself.

Amazon hired Pentagram to design the device, and the designers were having trouble with these requirements. Having customers easily buy and download books from the device implied having a cellular radio inside each unit. This radio and its required wireless plan would affect the product’s financial viability. It was hard for the designers to see past the implications:

Continue reading →

Design for the Relationship

| Jorge Arango

I’m currently reading Brad Stone’s The Everything Store, a history of Amazon.com. One of the early chapters is about the very early days of the company, which at that point was only selling books. In addition to showing information about products, founder Jeff Bezos wanted the site to include customer reviews of individual books.

Of course, some customer reviews were negative. Mr. Bezos received an angry letter from a book publishing executive, arguing that Amazon was in the business of selling books, not trashing them. But that was not the Amazon way. Per Mr. Bezos,

When I read that letter, I thought, we don’t make money when we sell things. We make money when we help customers make purchase decisions.

These two sentences struck me as a key insight: the particular sale isn’t the ultimate goal of the interaction; building the overall relationship with the customer is.

Long-term thinking is rare in business — especially in a fast-paced environment such as the early web. Nascent Amazon was under a great deal of pressure to prove itself, to grow. Driving more immediate sales would’ve seemed the more prudent approach. And yet, the team chose the long-term relationship. That’s values in action.

In your work, you may sometimes be called to choose between a feature that “drives the needle” in the short term versus one that builds an ongoing relationship. How do you choose? How do you measure the cost either way?

Photo by Steve Jurvetson via Wikimedia

Shanghai Disneyland

| Jorge Arango

Folks who know me well know I’m a fan of the Disney theme parks. I consider Disneyland among the most successful places designed in the Twentieth Century. I’ve written about some of the reasons why (and about what UX designers can learn from the park) in a post titled 3 Placemaking Lessons From the Magic Kingdom; I recommend you read that before proceeding so you can get a sense of the lens through which I see these experiences.

I visited Shanghai last month for work. While there, I had the opportunity to visit the newest Disney theme park, which is in Pudong. In this post, I’ll share some of my impressions of Shanghai Disneyland and contrast it with the other Disney “castle” parks. (I’ve visited the parks in Anaheim, Orlando, and Paris.) There are many similarities between these Disneylands, but also significant differences.

Let’s start with the similarities. The most obvious is the structural layout of Shanghai Disneyland. There’s a castle in the center of the park that serves as a focal point. (A “wienie,” to use Walt Disney’s term.) The castle — Shanghai’s is the largest of all of Disney’s parks — helps guests orient themselves and navigate the environment.

Enchanted Storybook Castle in the center of Shanghai Disneyland.
Enchanted Storybook Castle in the center of Shanghai Disneyland.

Continue reading →

Paola Antonelli on the Role of Designers

| Jorge Arango

MoMA Senior Curator of Architecture and Design Paola Antonelli in an interview with Core77:

In 2008, I did an exhibition that was called Design and the Elastic Mind where I came up with this idea that I use a lot: that designers are enzymes, they are the ones that make innovation, whether it’s scientific or technological into life. So that’s how I always think about it, whether they’re working on a product or on an interface or on an exhibition design, designers are the ones who make sure that there’s a synthesis happening and the synthesis that can be communicated to other human beings.

So if they are exhibition designers they make sure that the idea of a curator is tangible and is understandable by other people. If they are product designers, they in the simplest of cases become an interface between the engineering department and the public.

So it really depends, but I believe the designers are naturally extroverted professionals. Not that they are individually extroverted, maybe not, they might be shy or mostly introverts. But their role is to become catalysts, enzymes and to put the pieces together, they’re very good at that. Their role in the future continues to be that and I hope that this exquisite characteristic they have will be used and exploited in areas that are not necessarily the usual one. I hope that they will be included in political discussions, I hope that they will be almost like philosophers who are society-wise people that are consulted whenever there’s a big decision to make.

Design isn’t just a way of making better products and services, it’s also a way of knowing the world. (I love that Ms. Antonelli extends the scope of design to include politics, which has more to do with tweaking social and economic relations than with making stuff.)

Paola Antonelli on the Urgent Role Designers Will Play in the Future

Understanding Customer Mental Models

| Jorge Arango

How well do you understand your customers? Do you know how they make decisions? How they see your business’s domain? What makes them tick?

Everyone understands things a bit differently. Nobody has a perfect, complete understanding of the whole of reality. A neurosurgeon may understand the human nervous system but be unable to successfully configure the security settings of her smartphone. Knowledge of one domain doesn’t necessarily translate to another.

You carry around in your mind internal representations of how things work. These representations are called mental models. Wikipedia has a “good enough” definition:

A mental model is an explanation of someone’s thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person’s intuitive perception about his or her own acts and their consequences.

The more accurately these representations mirror the way things really are, the more skillfully you can act. If you understand the distinctions between the components that define your phone’s security and how they relate to each other, you’ll be able to make good predictions about the consequences of your decisions.

Forming good mental models for complex domains isn’t easy. Modeling calls for thinking in abstract terms. You may be tempted to apply a model from one domain you understand well to another you don’t. (E.g., “I bet this works just like x.”) We aren’t formally trained to model the world. Instead, we form mental representations ad hoc, filling out the broader picture as we go along. Thus, we have imperfect models of much of reality.

Ideally, you want your customers to have good mental models of your business’ domain. This is easier to do in well established domains than in new ones. For example, more people are likely to have good mental models of the process of renting a car than securing their smartphone.

It’s important that you understand your customers’ mental models for your domain. This isn’t something you can ask them about in an interview. We don’t express our mental models overtly. Instead, they manifest indirectly in our actions. What to do?

One way to go about it is to observe them interacting with prototypes and making note of how they interpret its major concepts and their relations to each other. Another is to engage customers in co-creation sessions to design solutions for the domain.

In this second approach, we don’t expect the solutions that emerge to lead directly to products or features. Instead, the artifact functions as a MacGuffin that allows us to map the customers’ mental models of the domain. This approach is especially useful in early stages of the design process, when we don’t yet have a prototype to test.

With a better understanding of how customers see the domain, we can design solutions that allow them to make more skillful decisions. This may call for producing means for them to adjust their mental models to more closely align to reality. Or it may require that we adjust the system we’re designing to better match the models users bring with them.

In either case, we’re not starting from a blank slate: we must meet people’s understanding of the domain. This requires that we understand their mental models.

How Designers Can Help Bust Silos

| Jorge Arango

When I talk with folks in large organizations, I often hear a familiar lament: “We’re very siloed here.” By this, they mean the organization is divided into​ groups that don’t play well with others. Each group functions like an isolated “silo” that acts independently from the rest. They each have their own internal goals, incentives, processes, etc. which make it difficult for them to collaborate.

Siloing impedes the organization’s ability to respond effectively (and in a timely manner) to changing contextual conditions. Because it involves organizational cultures and incentives, it can be a tough challenge to overcome. People in silos have an especially hard time seeing things from others’ perspectives — especially their colleagues.

A big part of the problem is that people in these situations​ tend to communicate in abstract terms. Often they’re unaware of using language that reinforces the distinctions between them. With our emphasis on making things tangible, designers can help them bust through these barriers.

Continue reading →

Designing the Right Things

| Jorge Arango

At a high level, design teams in organizations face two challenges: Doing things right and doing the right things.

“Doing things right” is about efficiency: making the best use of time and resources. When seeking efficiency, leaders ask questions about their team’s production function:

  • Do we have the right roles?
  • Are relationships between roles organized optimally?
  • Do we have the right people in those roles?
  • Do we have enough people in the team? Do we have more people than we need?
  • How do we recruit the right people into our team?
  • How do we nurture leaders?
  • What tools, systems, and processes can help us do our jobs better?
  • What mental models can help us do our jobs better?
  • Is our team culture conducive to producing good work?

For the most part, leaders trying to answer these questions have peers in the organization they can partner with: HR, IT, and operations. As design matures within organizations, there’s also more professionalization of the discipline without; this manifests in the growing interest in design operations and the documentation and sharing of best practices.

In other words, when looking to do things right, today’s design leaders have several starting points. But what about doing the right thing?

Continue reading →

What I Unlearned From Architecture

| Jorge Arango

I got an interesting question via Twitter:

“What were some of the mindsets, habits of thinking you had to unlearn transitioning from [architecture] to [information architecture]?”

The answer that comes immediately to mind is: “not that many!” I consider architecture a perfect training ground for information architecture. There are many more architectural mindsets that apply to information architecture than mindsets that require unlearning. That said, as I’ve thought about it I’ve realized there is, in fact,​ a mindset I picked up from architecture that I’ve had to unlearn over time: the idea of the architect as the central element of the design process.

Architecture is rife with what are referred to as starchitects — practitioners whose work and style is known around the world, and whose fame influences the work. Clients seek out Frank Gehry because they want a Frank Gehry building. Gehry’s office is bound to produce buildings in the Gehry style regardless of what contextual conditions call for.

When I was a student, most of the works we looked at were produced by starchitects. The implication was that that’s what we ought to aspire to. The first few years of my career, I labored under the delusion that I was at the center of the work. Over time, I came to realize that effective designers (in any field!) primarily serve not themselves or their architectural ideologies, but the work. I came to suspect the idea of having a “house style” — something I longed for at first.

To put it bluntly, I left architecture school with an inflated ego. The main mindset I had to unlearn as I transitioned to information architecture was the centrality of my own ideas, desires, and “style” in the design process. Instead, the core of what I aspire to now is form-context fit. This calls for understanding through collaboration; it calls for research and open-mindedness. Experience is primarily in service to the process, not the other way around. Getting my ego out of the way — embracing beginner’s mind — took many years of practice.