Gathering Requirements

Every stage in the Design Thinking model involves an element of learning. During the discovery stage, designers need to learn tentative answers to the following:

What’s the problem?

Who has the problem?

How can the problem be simplified to its most basic elements?

What’s been done already?

What needs to be redone or improved?

What are the most pressing concerns?

What are the constraints?

Where applicable, it’s also good to tack on a “why” to the ends of these questions. The “why” helps you figure out what problems really need solving and where you the designer can make the greatest impact.

“Requirements are assumptions.” ~ Jeffery Gothelf, Lean UX

A good thing to keep in mind when gathering requirements is that without hard evidence (which is often the case early on in a project), requirements are really whatever you believe them to be. Even with hard evidence, assumptions are still interpretations that could very well be wrong in light of what you have yet to learn. Beliefs are based on assumptions. Shaping your beliefs to fit a pre-existing product idea can be tempting, but it can also lead to solving problems that don’t exist.

Instead of setting yourself on an unalterable trajectory toward a single solution, first try to figure out if you’re asking the right questions. Instead of asking “How do we build a bridge?” ask “How do we get across the river?” That’s where understanding the “why” and knowledge of your customer comes in. Sometimes, it might be appropriate to build a bridge, but if you don’t have to build a bridge, don’t build one! Do something else. Maybe pull an Oregon Trail, caulk the wagon, and float that baby across!

No Problem? No problem!

After you take on a few projects, you’ll start to see that the relationships between the product you’re building and the problems you’re trying to solve can be a little opaque. That’s fine. In 2003, no one had any concept of the awesome power of a “like” button. If you can’t quite articulate the connection between a problem and a solution, it doesn’t mean you should abandon the idea. These ideas come from real places of need, often at the sub-conscious level. The more you understand about the landscape of those places, the closer you’ll find yourself to the best solutions.

In Hooked: How to Build Habit Forming Products, author Nir Eyal talks about how there are two kinds of products in this world: “vitamins” and “painkillers.” Vitamins represent solutions for non-urgent problems. They’re nice to haves, they improve something (supposedly), but the world would most likely go on just fine without them. Half of the items you might find in Brookstone or the Sharper Image could fall into this category. Painkillers, however, solve more urgent problems. It’s easy to confuse the two, but they can be distinguished by the emotions they incite and the impact they have on the market.

When you’re building a new product or market with no real precedent to guide you, figuring out if the thing you’re designing is a vitamin or a painkiller can be tricky. If this is the case, ask yourself how the problem is currently solved and what the outcome is like. Even if your solution is more efficient than what’s currently out there, if the outcome is the same, odds are your product will fall into the same category. From a business perspective, it makes sense for stakeholders to prefer painkillers because people are more dependent upon them, which makes them easier to sell.

On the other hand, every once in a while a rare vitamin comes along and changes the course of history. How does this happen?

“Over time vitamins can become painkillers.” ~ Nir Eyal

It’s good to remember that when you’re dealing with vitamins, the problems they’re associated with might not exist… or might not exist yet. A product designed with the foresight of changing market conditions will undoubtedly have better odds of transforming from a vitamin to a painkiller, which is all the more reason you should always keep a close relationship with your user base.

Conversely, a good strategy you can use to curb your product toward the path of the painkiller is to work habit forming mechanics into the foundation of the user experience:

Image Credit: Hooked Canvas, Nir Eyal

Trigger: The event, often an emotion or external event that compels someone to use a product. Ex. hunger, commercial for Wendy’s.

Action: The event one engages in order to satisfy the trigger: Ex. checking FB satisfies need for social interaction; checking Google satisfies curiosity, etc.

Reward: The emotion or event that happens as a result of the action: Ex. the surge of pleasure you feel when someone you’re attracted to “likes” your FB post; the instant gratification you feel when Uber pulls up within seconds of your ride request (and of course the actual ride home). The more variability a reward may have the more valuable the reward will appear to be.

Investment: What users give for the promise of a future reward. This loads the trigger for the next cycle through the hooked loop. It also increases the value of the product. The more you invest, the better the payoff (ideally). Ex. producing the content for a FB post, which you will check for likes next time you login.

When gathering requirements keep a close eye on the interplay between the product’s user experience and these four components. If these components enhance the user experience, the product likely has the potential to be a painkiller. If you’re uncovering risky assumptions left and right, check them against the hooked loop. You might just discover some new habits waiting to be born. Eg. the entire casual gaming industry.

Whatever you do, don’t force the hooked loop into your UX. Many have tried. Many have died! :)