Even though it’s used quite extensively, I’ve never liked “the fewer clicks, the better” as a metric for good usability. Chasing that metric can easily result in an interface where every feature is within a click or two’s reach, but the thing is so crowded that users have trouble figuring out where to go. In Satisficing Lukas Mathis draws from psychology to explain why this metric doesn’t make much sense:

A great user interface is not one where each goal can be reached with the smallest number of clicks possible, or where the user has to pick from only a small number of choices at each step, but one where each individual click is as obvious as possible. If your users have a clear goal in mind, each level of the hierarchy should have one option that clearly satisfies their goal—or at least gets them closer to that goal. As long as users feel that they are getting closer to their goal with each step, they don’t mind drilling down into a deep hierarchy.

It’s also worth skimming the Wikipedia article on Satisficing for some further background on the theory.

Here’s an important reminder that tools don’t matter as much as we think they do. What matters is how the tools enable people to accomplish their goals. From Chana Joffe-Walt’s Why Legos Are So Expensive — And So Popular (my emphasis added):

But Lego did find a successful way to do something Mega Bloks could not copy: It bought the exclusive rights to Star Wars. If you want to build a Death Star out of plastic blocks, Lego is now your only option.

The Star Wars blocks were wildly successful. So Lego kept going — it licensed Indiana Jones, Winnie the Pooh, Toy Story and Harry Potter.

Sales of these products have been huge for Lego. More important, the experience has taught the company that what kids wanted to do with the blocks was tell stories. Lego makes or licenses the stories they want to tell.

No one cares about your product as much as you do. But they do care about their stories. And understanding that can help you make better products.

I know I’m late to the party, but I finally saw Looper last night. It is, of course, as brilliant as everyone says it is. After watching the movie I went back to all my Instapaper’d articles about it, and my favorite so far is an interview with the director called Noir to near-future: ‘Looper’ director Rian Johnson talks sci-fi, Twitter, and the fate of film. This answer, in particular, jumped out at me (my emphasis added):

The minute you say “science fiction,” the question of world creation comes up. Was that something you were thinking about when you were writing?

No, that was the production designer. When I was writing I was really just disciplining myself to focus on getting the narrative as tight as possible. To tighten the screws on everything, and to make sure that it ticked and that it ran from start to finish and that it had a solid spine.

And so I was focused on that and I wasn’t even thinking about the world-building elements at all. Which I think was good because it meant the designers and I just worked together. Every design decision, it wasn’t preconceived, it came out of the needs of the story. And so making the world seem like such a desperate place was a way of accentuating that feeling of “you better hold on to your slice of the pie, or else it’s destitution,” you know?

I love that approach, and I think we need more of it in web design as well. Start with the story — the core functionality of the product. Then look at that functionality, and only add the “production value” (styling) that will help tell that story. Nothing more.

It reminds me of a point Ryan Singer makes in his article UI and Capability. In the excerpt below, think of story as “capability”, and production design as “style”:

Affording a capability and styling it are both important. But it’s essential to know which one you are doing at a given time. Style is a matter of taste. Capability and clarity are not. They are more objective. That person standing at the edge of the chasm cares more about accomplishing their task than the details of the decor.

It’s worth reminding ourselves that, just as we’ll forgive a movie’s shoddy special effects if the story is great, users will forgive a style they don’t love if a product helps them to accomplish a goal effectively.

Look at your feature roadmap right now. Are there major initiatives and ideas that were generated directly from your designer or design team? If yes, was design in the room when the other items were created and prioritized? Congratulations, you’re design-driven.

— Cap Watkins, Building a Design-Driven Culture

Abby Covert wrote a very important article on the just-relaunched Boxes and Arrows. I know we’re all pretty tired of the “What is UX?” debate, but A Perfection of Means and a Confusion of Aims addresses the damage that the umbrella term “user experience design” is doing to specialist UX functions. Some key passages (but you really should read the whole thing):

I am afraid that there is a shortage of specialist jobs, and it isn’t because those specialities aren’t needed. I believe it is because the value of those specialities, and the impact of not considering each carefully, is in too many cases not clearly called out to our clients and partners. […]

In my experience when “UX” is the term sold-in, the resulting project plans are less likely to reflect the points at which various specialities will be relied upon to progress the team. Often prescribing a stacked to the gills list of tasks reduced to the nebulous “Design the User Experience” on the Gantt chart. The makers of these types of plans leave it to “UX Designers” to divide the time they have amongst the various specialities of a “UX” and arrange their time against it. […]

The worst case scenarios result in teams jumping right to wireframes, prototypes and documentation. I see far too many UX designers that have become wireframe machines.

This is, by and large, an agency problem (but you see it in some internal design teams too). As agencies start to see the value of selling “this UX thing” more and more, many put out unicorn job specs that aim to find some generic skill combination that can be sold to clients as user experience work. And I’ve talked to several people who fell into the trap of these jobs, only to find that their new realities consist of making wireframes and getting dirty looks because their colleagues feel they’re just slowing down the design process.

I have nothing against wireframes — in fact, I remain a huge proponent despite some recent calls to move away from it. It’s not the focus of this post, but I still find huge value in wireframes (particularly HTML prototypes) to (1) work through the complexities of finding elegant solutions to difficult interaction problems, and (2) get early user feedback before moving into high-fidelity design and development. But the point of all this is that wireframes are not the end goal of user experience design, they’re part of the process. A process that involves research, information architecture, customer journey maps, content strategy, and all the other specialities Abby points to in her post.

And that’s where I’m 100% in agreement with Abby. That we have generalised User Experience Design to a black box process that makes it very hard to convince clients (and some agencies!) that the specialist functions that go into designing holistic experiences for people are absolutely essential. We need agencies to:

• Understand the different specialities that make up the User Experience Design process (I’ve taken a crack at a model here),
• Hire specifically for some sensible combination of those skills, and
• Educate clients on the value that each of those specialities can add to make their products successful.

Yes, UX unicorns do exist, I won’t dispute it. But they’re few and far between. The rest of us need to know that there is value in becoming really good at our chosen specialities, and we need to be confident that we can sell those skills to our clients.

So, I’m not arguing that we should throw away the title of UX Designer, as some have suggested. I’m saying that we have a responsibility to know that the field is made up of many specialities, and if we ignore those we do ourselves, our industry, and our clients a huge disservice.

Neil Hunt, Chief Product Officer at Netflix, wrote a good answer on Quora to the question Why doesn’t Netflix offer “Advanced Search” on their site? It’s a great Product Management lesson:

Nothing is purely additive unless everyone uses it. If there’s an affordance to use a feature, the affordance is a distraction to everyone, while the positive value accrues only to the users and potential users. The net value of a feature is the value to the users of the feature, divided by the distraction of the affordance to everyone. Advanced search ends up being used by such a tiny fraction of users (sub 1%), that it can’t possibly pay for its cost.

This is a good way to decide if a feature is worth adding or not. The question isn’t simply “Can we do this?”, or “Will users like it?” The question is, “Will enough people use this feature to make it worth the development and maintenance cost?” In the case of Netflix, the cost/benefit calculation just didn’t work out on Advanced Search, so they wisely decided not to launch the feature. But Neil goes further to say this:

But let me share that what does work well is making simple search deliver the advanced results.

That’s an important point. Advanced Search solves a particular user need, but it solves it in an expensive way. The need doesn’t just go away though, so they spend their development efforts on developing solutions that meet that need for all users, not just those who might have used Advanced Search.

The lesson here is obvious. Instead of implementing features just because other products have it, ask what user needs are met with that feature, and then look for cheaper and/or simpler alternatives to meet those needs. Luke Wroblewski’s New Approaches To Designing Log-In Forms come to mind as a good example of this approach.

John Gruber wrote the following in the context of recent leadership changes at Apple, but it’s applicable to life in general. From Seriously, Apple Is Doomed:

What you want is to be (1) right more often than wrong; (2) willing to recognize when you are wrong; and (3) able and willing to correct whatever is wrong. If you expect perfection, to be right all the time, you’re going to fail on all three of those — you will be wrong sometimes, that’s just human nature; you’ll be less willing or unwilling to recognize when you’re wrong because you’ve talked yourself into expecting perfection; and you won’t fix what’s wrong because you’ll have convinced yourself you weren’t wrong in the first place.

I’ve mentioned before that the ability to admit that you’re wrong is an essential characteristic of a good designer. I maintain that some of the biggest product failures can be traced back to a refusal to recognize that the idea/design isn’t perfect.

“Design like you’re right, listen like you’re wrong.”

Des Traynor shares some insights on how he works with startups in Asking Questions beats Giving Advice:

The first question I ask (though sometimes I just ask myself) is an easy one: is this viable, feasible, and desirable? The answer has to be yes on all three counts—no two are enough. In fact, pick any two, and you’ll think of a start up that failed because they missed the third.

This approach shares parallels to the “problem frame diagram” approach I discuss in Usable yet Useless: Why Every Business Needs Product Discovery. The goal with that approach is to identify the user needs and business goals of the product, as well as the core competencies of the organisation.

Des goes on to describe some of the key things you have to think about before launching a product. If you do Product Management on the web, his post is highly recommended.

Micah Baldwin in Silent But Deadly:

Yet, there is something amazing, maybe even beautiful in execution. In silently creating something of immense value without the need to be everywhere to be seen by everyone. That our worth as entrepreneurs is built through our products, not through our names.

It’s a great story and a great post.

(link via @PaulCartmel)

Most successful applications do a good job of onboarding users to teach them how the basics work. After that, good applications also make it easy to learn more advanced features simply through repeated use. You might make a wrong turn once, but if the application corrects your course, you never make that mistake again.

But sometimes there are features that fall between the cracks of onboarding and self-learning. It usually happens when there is some unique behavior in the app that is not only presumed to be commonly known by all users in the community, but is also small enough so that it’s not worth making a big deal out of during new user onboarding.

I recently thought of two such examples that I wanted to share, along with some suggestions for addressing the issue.

Twitter mentions

First, there is the issue of Twitter mentions. I still see people who I know have been on Twitter for years, who don’t know that if they start a tweet with ”@”, not all their followers will see it. This information is buried deep in Twitter’s Help section, where I’m guessing very few people venture to. From Types of Tweets and Where They Appear:

Users will see @replies in their Home timeline if they are following both the sender and recipient of the update. Otherwise, they won’t see the @reply unless they visit the sender’s Profile page. 

This is fairly clear, but if you don’t think about this as an issue, you won’t know to ask the question, so it’s not information you’re likely to seek out.

Instagram replies

Second, there is replying to comments in Instagram, which I’m sure trips up quite a few people. If you comment on one of my photos in Instagram, I will get a notification. But if I respond to your comment without including your @username, you won’t get a notification. This is not how it works on Facebook, where you get notified of five comments after the one you posted1. Instagram does have an easy way to reply to people with their usernames, but it’s a slide gesture I discovered by accident:

So the easiest way to reply to someone is to slide from left to right on their comment, then tap on the arrow. Or you can start the comment with an @, which will then autocomplete the name as you type. But it’s not something they tell you about explicitly. It’s also, again, not information most people will seek out actively, since they’re getting notifications for each comment on their own photos, so why worry?

A proposal

My proposed solution for this type of situation is fairly simple. In the case of features that don’t behave as people expect them to, show a lightbox-type message to explain how it works just one time — the first time they perform the action. For example, the first time a user sends a tweet that starts with an @, show a message to explain who will see it. And the first time a user comments on one of their own photos in Instagram, show a message that explains when people get app notifications.

These are small but important details, especially for social services where understanding exactly what happens when you hit “Post” is essential to the enjoyment of the app.

Related post from the Elezea archive: Best practices for user onboarding on mobile touchscreen applications.

---

1. I think it’s five. But I’m not 100% sure. Come to think of it, it’s probably a good example of this type of confusing behavior as well. ↩