In his introduction to a very interesting user research case study on the MailChimp blog, Gregg Bernstein writes:

Here at MailChimp, we’re realists—as much as we love email and all the things you can do with it, we understand that building a campaign is a task, not a life event. You want to get in, get done, and get on with things. Duly noted.

The post goes on to explain how they managed to shave an average of 32 seconds off a core email campaign creation task at MailChimp. But it’s that opening sentence I’d like to dwell on for a bit.

I wish more companies understood this crucial point. As designers and product managers we obsess over every detail of our product, but it most likely makes up a minuscule part of our users’ days. Unless you work for Facebook or Twitter users don’t wake up wondering what new features you’ve released, how your conversion rate has changed over time, or what awards you’ve won. They care about getting a task done, and they care about nothing getting in their way — they care about getting on with their lives.

Yesterday The Onion published an article that is such a spot-on commentary on how we’re mostly ignoring this reality. From Internet Users Demand Less Interactivity:

Tired of being bombarded with constant requests to share content on social media, bestow ratings, leave comments, and generally “join in on the discussion,” the nation’s Internet users demanded substantially less interactivity this week.

Speaking with reporters, web users expressed a near unanimous desire to visit a website and simply look at it, for once, without having every aspect of the user interface tailored to a set of demographic information culled from their previous browsing history.

Exactly. We’re in an environment where too often products and functionality are shaped by who we are and what’s technically possible, not by what user needs call for. XKCD called us on it years ago, but we’re just not listening:

The solution to this problem is to get out into the world and understand how our products and services fit into the lives of our users. How we can help them accomplish their tasks more effectively. Mark Hurst summed this up well in his post What is a career in user experience really about?:

Good user research isn’t a matter of learning the steps of some trendy methods, as though one were just following a cookbook. Instead, good UX work requires a genuine interest in observing, listening to, and learning from other people: primarily the customers themselves, but also the organization that owns the product. That observation, and that listening, must stem from a genuine human interest in people.

We can all do with a shot of humility about our products. We might think what we’re making is a gift to humankind that deserves proper respect — and we absolutely should be proud of our work. But a bit of human empathy will show us that most users have only a passing fly-by relationship with our products. That’s ok though. Understanding how our products fit into people’s lives realistically will help us to improve that fit and (hopefully) become indispensable to them. That’s our job as User Experience Designers.

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)