Design

Label-less Buttons

| Jorge Arango

From a report on The Verge:

Starting [February 27], Spotify is rolling out a new look to its iPhone app. The changes prioritize universal icons and visual indicators over written words, which Spotify says makes the app a more accessible experience for users all over the world.

In other words, the app is ditching labels in buttons, and going only with icons.

As noted above, the objective is to make the experience more accessible globally. I’m taking this to mean that interfaces with few or no words on them are easier to translate into different languages than those that include words. But that’s a gain for designers and developers, not necessarily for users.

This label-less approach to buttons works best when working in a domain that already has rich iconography. Spotify operates in such a domain — i.e., music players. If you had to design an interface with buttons to play, pause, go backwards or forwards, you’d have a clear starting point; we’ve had devices with buttons that accommodate these behaviors for a long time. My preferred music player (Apple Music) also has label-less buttons for those actions:

Apple Music

Modern music-playing apps must also accommodate other actions that may not have well-known icons. For example, the video above highlights the user downloading a track to their phone. In the new Spotify UI, the button for this action shows a downward-pointing arrow inside a circle. Downloading tracks from the internet to local devices hasn’t been around as long as play/pause/rewind has. I’d bet more folks would get tripped up by such a button in the absence of labels.

Note in the video that some buttons in the new Spotify interface don’t have icons at all; they consist solely of labels. For example, the “Follow” button simply consists of the word “Follow.” When pressed, the label changes to “Following” to indicate the object’s changed state. This is a rich interaction that would be difficult to communicate clearly using only icons.

Spotify is rolling out a new look for iOS that ditches word-based buttons

Designers as Team Players

| Jorge Arango

A useful reminder by Enrique Allen in Designer Fund’s blog:

Often as designers, our natural tendency is to emphasize the importance of our craft, instead of focusing on the impact it has on the bottom line.

The post goes on to describe a high-level framework of twenty areas (“levers”) where design can impact the bottom line, including specific ways that the organization can make and save money.

For designers to be effective, we must be aware of the business’ needs and aspirations. We’ll only be taken seriously to the degree that we can help the organization succeed towards the dimensions it cares about.

Of course, that doesn’t mean these are the only dimensions worth pursuing. For example, the design process may uncover a situation in which a particular business decision may be at odds with the needs and aspirations of the organization’s customers. Designers can then help resolve the impasse.

But we can only do so if we’re taken seriously by our colleagues. And we’ll only be taken seriously to the extent we’ve shown commitment to helping the business grow. As I’ve written before, it’s misguided to think of design as “fighting for the users.” Instead, our aim should be to bring various forces – including the users’ needs — into balance.

Designers enjoy a unique vantage point in the organization. We are connectors. We’re tasked with understanding the needs and concerns of various stakeholders — including our users — and making things that meet those needs efficiently and effectively. We test and refine these things, over and over. Through this process, design can bring alignment and clarity to the organization.

There’s incredible power latent in modeling possibilities. The degree to which we can employ this power towards the common good will depend on the degree to which we act as team players.

The 20 Levers for Return on Design | Designer Fund

LEGO: An Appreciation

| Jorge Arango

I took Christmas Day off: no client work, no podcast editing, no writing. Instead, I spent the day playing with my kids. Mostly, we built LEGO sets.

Although I am not an AFOL, LEGO is an important part of my life. I use it in my systems class and have written about some lessons it holds for systems thinkers. More importantly, I love playing with LEGO. It’s my favorite toy — and has been since I was a child.

Yesterday, as I helped my daughter build set #10260, I reflected on why I love the bricks so much. It boils down to the following:

Continue reading →

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.