Smart teams begin new design projects by getting to know their customers through design research. The best ones build models of those customers, their goals, their behaviors, and/or their environments. Models like personas do an awesome job of describing what the customer’s world looks like today. However, building models of customers and their work is only a means to the end of designing great products. Many teams struggle with using research models to inspire design. It’s just too big of a jump from a persona writeup to a new product concept.

The context scenario bridges this gap. A good context scenario clearly articulates a working hypothesis of how the customers’ lives will improve when the new product* exists. Unlike a workflow or task analysis, a context scenario is an act of design—it imagines the future, rather than describing the world as it is today. Because context scenarios can be created and iterated on very quickly, they are often the first design act the team undertakes.

I recently finished reading “The Lean Startup” by Eric Ries. If you haven’t read it already, I highly recommend it – the book is full of great insights on how to make new products, whether you’re a startup or a big, established company. I’m not on board with all of his recommendations (e.g. split testing every little change) but he gets so much right (small batches, experiment-driven product development, stay stubborn on vision but flexible on execution, etc.) that I can’t help but look past the occasional lapse in the details.

In this post, I’m going to discuss a simple technique that Eric mentions near the end of the book: the technique of the Five Whys. The goal of the technique is to help us look past the immediate cause of a problem to find more systemic causes. These systemic causes often indicate bigger problems with the culture and structure of the organization.

During my time as a UX professional, I’ve worked on a number of newproducts. All of these products began with an idea, and when we were smart, we spent some time defining and refining that idea to build clarity and to make sure we were all on the same page. But a good idea alone wasn’t enough. We needed a vision – a picture of how this product would make the world a better place for our customers (and for us).

But what is a vision? Visions are nebulous – unlike wireframes or comps or specs or code, they don’t have a clear form. There’s lots of advice out there on what qualities make up a good vision (Simplifying! Engaging! Unequivocal! Unifying!) but not much on what you need to actually make.

Great product visions are usually composed of three types of artifacts. They are the business case, the proof of concept, and the context scenario. Usually, all three are required for a successful vision.

Are you a design researcher, interaction designer, product owner, or other product-maker-type person? Have you used personas to represent your customers on at least one product you’ve been involved with?

Then you may have run across personas with names like: Harry Hobbyist, Denise Designer, “Jay Vah the Java Developer”. You may even have created some of these personas yourself.

Stop that immediately.

Personas are stand-ins for real people. No real person has a name like “Harry Hobbyist”. You’re not describing a real person, you’re describing a role.

All design projects start with an idea. Sometimes it’s a big idea – a new product, service, or business. Sometimes it’s a small idea – a minor tweak to something that already exists. But big or small, the quality and clarity of the idea can put the design project on the path to success or send it immediately into a tailspin of endless revisions and unmet expectations.

Unfortunately for designers, good quality, clearly communicable ideas don’t just pop into the world. Someone has to do work to refine a half-formed idea before it’s ready to inspire design. All too often, that someone is the designer himself, whether or not the idea originated with him.

Even more unfortunately, I’ve found there’s little guidance in UX design best practices on how to do this. What sorts of questions should a designer ask about an idea before he starts in on designs? The answer seemed to be the ever-frustrating “It depends”.

Some of you have probably seen Nest, the learning thermostat. For those who haven’t, I’d strongly recommend taking a look and watching their (short) intro video.

I’m impressed by Nest, and not just by their elegant design and eco-friendly overtones. What impresses me most is the strength of their core insight. Although it’s going to seem pretty obvious, its the kind of insight few companies in the tech industry seem to get. It goes something like this:

To summarize, Jared’s team worked on an ecommerce site that required a login/registration to complete the checkout process. They did some design research and found out this step was chasing away huge numbers of potential customers – first-time users were resistant to registering, and even repeat users frequently forgot their usernames and passwords, causing frustration. When they eliminated the registration requirement, sales increased by $300 million in the first year.

“Well, duh,” I thought. Registering with a new and possibly unknown site is a serious commitment for many people. Of course it would chase them away. If the designers were any good, they wouldn’t have needed a research study to tell them that.

Business folks like to talk about the “Minimum Viable Product“, generally defined as the smallest product (in terms of functionality) that will still be accepted by the market. It’s an important concept – possibly the most important concept in new product development. Unfortunately, it’s often understood in a way that leads teams to failure. In this incorrect sense, MVP is understood to mean “what’s the least amount of work we can do and still succeed?”

The problem with focusing on “least amount of work” or “smallest number of features” is that it can simultaneously lead you to do less work than you must to be viable and more work than you must to be minimal. Let’s look at each.