Speaking of Ryan Singer, I recently re-read his answer on the Quora startup thread Should I focus on a good user experience, or push something out quickly? He makes a really good argument for investing in design very early in the product development process:

Design is a path-dependent process. That means the early moves constrain the later moves. On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it’s not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don’t want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that’s the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations.

This is why variation, not just iteration, is so important during the early phases of a product.

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.

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.

One of the hardest things we have to do as a User Experience Design agency is to sell usability testing to clients. The concerns are usually some combination of the following:

• It will take too long (no, it won’t).
• It’s too expensive (not if you consider the potential ROI).
• You can’t learn much from 6 users (yes, you can).

But we keep at it, because we know that if we’re successful in our efforts to convince clients to try it just once, we’ll never have to sell it to them again. It’s a methodology that completely sells itself. Once a client sees real users struggle with their product, they immediately become believers and staunch evangelists of usability testing.

The situation was a little different for a recent project we worked on with Obox, creators of premium WordPress themes. They came to us already sold on the benefits of usability testing, they just needed our help with research design and execution, and to work with them on some of the design recommendations based on the data we collect.

Yesterday, CEO and co-founder David Perel did a write-up of the project where he explained the process and the changes they’ve made. It’s great to see such an open discussion about how they are implementing their relentless pursuit of delivering value to their users. And even though they already understood the value of usability testing going into the project, I still loved this sentence from The User Experience Experiment:

The bottom line is it doesn’t matter how good looking your site is. Watching a layman use your product will blow your mind. You cannot even begin to imagine how your users interact with it.

If that’s how they reacted, just imagine the power such a revelation can have on people who don’t believe in the method. David also says this in his post:

We’ve been so taken aback by what we learned that when we looked for new office space, the most important requirement was that it had an extra room for user testing.

I know this means that they won’t need to hire us again, but I don’t care. That type of full-scale adoption of user-centered design makes me infinitely happy.

Be sure to read the full post, it’s a great case study.

One of the questions that really interests me is why certain digital products succeed and others fail — even if they look great and are easy to use. What can we learn from the failures to ensure that there are less of them? Is there a process that can help increase the likelihood of success?

The answer to these questions is the focus of my first article for A List Apart, entitled Usable yet Useless: Why Every Business Needs Product Discovery. From the intro:

All around us we see beautiful, empty monuments erected not for their users, but for the people who built them—and the VCs who are scouting them. Even sites and apps that go beyond beauty to usability often fail because they can’t find a big enough market.

Why can’t some interactive products find enough users to be sustainable? Why are there so many failed startups, despite a renewed focus on design? Most importantly, what can we do about it?

It was an absolute pleasure to work with the ALA team. I especially want to thank Sara Boettcher for being such a tough, gracious, and encouraging editor. I learned so much through this process — lessons I’ll take with me in my all my writing going forward.

So if these are questions you struggle with as well, have a look at the article. My hope is that we’ll see more businesses trying out the Product Discovery process as a way to build products that people love.

I can’t quite figure out why, but I really like this photo I took in our office earlier this week. I just think it’s such a great summary of everything I love about doing user experience work.

I spent the afternoon sitting on the floor, surrounded by sticky notes, drawing out insights that are based on data we collected from in-person usability testing and customer interviews. And I got to do it while listening to stuff like this.

I guess I’m just really grateful that we get to be in the business of understanding human behavior, and using those insights to make things that people care about. We might not always succeed, but the journey sure is gratifying.

Happy Friday, everyone.

(If you’re wondering, those are Sennheiser HD 380 headphones. Highly recommended.)

A couple of articles caught my eye today because they tie in well with my Intuition vs. Science in design post from yesterday. In Design and uncertainty Ellen Beldner writes about an essential characteristic for every designer: acknowledging that your assumptions will be wrong more often than not. She also makes a great case for usability testing:

The problems come when you don’t admit, as a designer or product person, that intuitions based on your mom or yourself may or may not extend to what most other people actually do. So a designer who seems like a hotshot Howard Roark out of college may be great for that one particular project. But when you ask him or her to work on a design for a domain that they don’t “intuitively” understand (since they don’t have years of experience being within that particular community) they’ll flail if they don’t know how to turn to research and data to inform their opinions.

I also love John Lilly’s advice to design like you’re right; listen like you’re wrong:

You should always design the product you think/believe/know is what people want — there’s a genius in that activity that no instrumentation, no data report, no analysis will ever replace. But at the same time you should be relentless in looking at the data on how people actually use what you’ve built, and you should be looking for things that show which assumptions you’ve made are wrong, because those are the clues to what can be made better.

This all comes back to that necessary balance between science (hard data) and intuition. Usability testing and contextual research help us understand unfamiliar domains enough to kick off the design process. Intuition lets us meet those users’ needs in creative ways. And analytics, combined with qualitative user research methods, help us figure out where we got it wrong and how we can do better.

I’ve written before about the importance of using both iteration (progressively solidifying the details of a product) and variation (coming up with ideas that are very different from the current iteration). We now know that Apple does that all the time; but it also recently became clear that they don’t view their unused variations as failures. Kyle Baxter makes a good point about this in Apple’s iPhone Prototypes:

But what’s fascinating to me is that designs rejected during the development process for an earlier version of the product may come back in future versions. That initial first step, where many unique designs are created, becomes the grist for the future of the product, a conceptual mine to return to for ideas. A particular design may have failed during an earlier product development process but could become the basis for development of a new design. Earlier rejected designs became the iPhone 3G and iPhone 3GS, and others became the iPhone 4 and iPhone 4S, perhaps Apple’s most iconic iPhone version yet.

It’s worth remembering: never underestimate the future value of what might seem like a bad idea at the time.

Jon Kolko’s Iteration and Variation is a great article on some of the dangers of iterative design, and how to avoid them. Jon’s main point is that iteration solidifies ideas:

Once this broad stroke has been created (drawn, wireframed, coded, etc), further iterations assume the basic framework as fact. The initial iteration acts as a constraint, and becomes rigid: I’ll refine details and extremities, review and change aspects of the idea, but the idea itself has come to life. […] Each further iteration serves to solidify details, and they become taken for granted: they become facts.

One way to avoid getting stuck on the wrong path is through variation:

Variation is a way of adding a sense of objectivity to design exploration. Variation is an exploration of alternatives. […] Where an iteration moves an idea forward (or backwards), a variation moves an idea left or right, and is not productive in a typical engineering sense: the expectation is that all of the variations (except one) will be rejected. But variations act as provocations for what-if scenarios.

My immediate thought was that even though this approach sounds great, it just won’t fly in most software development processes — especially if the process involves Agile methodologies. Today, Joshua Porter got to the core of why UX and Agile are often difficult to integrate in Is design building interfaces or solving problems?:

But if you view design as “problem solving” then all bets are off. In this case it may take an hour or a week to figure out a solution to a design problem — It depends on the problem and the tenacity of the designer. This makes the initial design phase more unpredictable because your first decent guess is almost always wrong or inelegant (as usability testing often shows). And this makes it more difficult to schedule — and it’s why design doesn’t fit into fixed-time sprints very well.

And that’s the thing. Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

This is, of course, where Lean UX comes in:

We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process. While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building

My biggest concern about this, from a practical point of view, is if it allows for enough leeway to test/research different variations, or if it just streamlines the iteration process to get you to the local maximum faster. I don’t know the answer to that, but all I can say is that I’m glad I’m not the only one struggling with these issues.

I’m linking to Sam Biddle’s Does Google Have Any Social Skills at All? with some caveats. I’m not a fan of headlines like that (here’s why), and there are way too many hyperbolic, trolling statements like “Nobody really uses Google+”. Still, the article makes some good points about Google’s lack of understanding of their users:

The keynote sounded one futuristic clarion call after another: Glass, the wearable computer; Google Now, a smartphone system that provides intricately tailored life information; the Nexus Q, a social media streamer; and a fancy new way to throw parties with Google+. But underneath each of these feats of technology you could see a hollow, lurching weirdness that makes you wonder: Who will use any of this stuff besides the actors in Google’s promo videos? [”¦]

In each case, Google has balanced on golden fingers a product — clearly with a lot of time, thought, and money behind it — that just doesn’t seem to jibe with the way we actually live our lives. There isn’t any lack of effort or innovation here, but rather a gaping disconnect between the way data geeks and the rest of us see the world.

I know Google does a lot of user research on their flagship products, but it doesn’t look like they do any Product Discovery or user need analysis on these new products. Maybe they’re genius designers, so they don’t need to do research. Or maybe not.