BrasÃlia is a remarkable, bizarre city. The vision of architect Oscar Niemeyer, it was built in just four years, from 1956 to 1960. More than 50 years later, its beauty and elegance are renowned.
But Brazil’s capital city is known for something else as well: how difficult it is to live there.
A “shiny citadel” from far away, as The Guardian once wrote, up close BrasÃlia has “degraded into a violent, crime-ridden sprawl of cacophonous traffic jams. The real Brazil has spilled into its utopian vision.”
This problem echoes across today’s web landscape as well, where the needs of ordinary users spill constantly into designers’ utopian vision. 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?
The rise of usable, useless products
We’ve long accepted that for a product to be useful, it needs to have acceptable levels of both utility (“whether it provides the features you need”) and usability (“how easy & pleasant these features are to use”). Yet far too often, we seem to ignore the former in favor of the latter, ending up with lots of easy and pleasant applications that have no reason to exist. One could argue that the first version of Color fell into this trap. And when’s the last time we heard something about Path?
One of the major problems that new products in particular run into is a lack of product/market fit, as Marc Andreessen has noted:
The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have? The size of a startup’s market is the the number, and growth rate, of those customers or users for that product…
The only thing that matters is getting to product/market fit. Product/market fit means being in a good market with a product that can satisfy that market.
The problem arises when startups and companies don’t spend enough time to increase the likelihood of good product/market fit before they start design and development. The Lean Startup concept of “Minimum Viable Product” is certainly useful, but shouldn’t we rather focus on Minimum Desirable Products? What’s the use of fast iteration if all it does is get us to the local maximum more quickly?
But before we get ahead of ourselves and discuss how to fix this, let’s jump into some of the all-important “why” questions.
Why products fail to fit
BrasÃlia’s biggest problem is that the architects who designed it didn’t consider how the city would be used once millions of people were living there. They exhibited Architectural Myopia—designing for industry, not people. I’ve written before about a similar phenomenon in our industry, Designer Myopia. Lured by the recognition (and clients and VCs) they deserve, designers are drawn to being featured in galleries and list-driven blog posts that drive tons of traffic.
There is nothing inherently wrong with that need for recognition—but it is a problem when it hurts users. If BrasÃlia teaches us anything, it’s that becoming blind to the needs of users leads us down a dangerous path where we lose control over our products, with no way to get it back. Once something has shipped, you can either iterate or pivot. Iteration is great if you’re on the right path. Pivoting is dangerous because changing course can wreak havoc on employees and users alike.
Product discovery: a better way
If we want to design better, more useful products, we need to stop designing solutions too early and start instead with product discovery: a process that helps us understand the problem properly so we don’t just design things better, but design better things.
Product discovery consists of three steps:
- Step 1. Frame the problem and maximize the opportunity
- Step 2. Explore and assess multiple solutions
- Step 3. Prioritize and plan
1. Frame the problem and maximize the opportunity
It’s hard to argue with Einstein:
If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.
Step 1 of product discovery is that proverbial 55 minutes. Here, you should discuss and answer questions such as:
- For whom are we solving this problem?
- Which user needs are we trying to address? For existing products, what are the shortcomings we need to fix?
- What customer insights do we have available to inform the solution (customer support, analytics, market research, user research, competitive analysis, etc.)?
- How will solving this problem help our business?
- Why is our business capable of making this solution a success?
- How will our success be measured?
There are several techniques to structure the discussion and make it easier to get to the bottom of these questions. Fishbone Diagrams and The Five Whys are two root-cause analysis techniques that can be applied very effectively to defining a problem in terms of user needs and business goals.
This phase always—without fail—produces insights the team finds incredibly valuable. Startups gain clarity about what to say “yes” and “no” to in their product, and large corporations learn how to go beyond customer-centricity buzzwords and discover which benefits they should be selling to their users. As just one of many examples, I was once in a workshop that revealed the executives had a completely different vision for the company than the designers and developers. It was an awkward two hours, but in the end they agreed on the tough but correct decision to suspend their e-commerce plans until some of the content areas on the site had been sorted out. It’s great to see a statement of purpose emerge from these sessions—one that finally gets an organization to agree on what the product’s focus should be.
From this step, I produce a problem-frame diagram, which is simply a visual summary of the main takeaways in the form of three overlapping circles:
- User needs
- Business goals
- Core competencies
Every decision the team makes should be anchored in at least one of these circles—preferably in the overlap of all three. Design decisions should focus on meeting those needs and capitalizing on the business opportunities by using the core competencies identified.
Customer journey maps are another useful output, and Megan Grocki and Jamie Thomson’s take on them is very informative. Journey maps are visual representations that help to summarize research, highlight and prioritize opportunities, and get buy-in from stakeholders.[1]
Once the problem has been defined (and agreed on by all stakeholders), it’s time to start thinking about solutions.
2. Explore and assess multiple solutions
The takeaways from problem-framing lead into a period of divergent thinking, where you produce many different possible solutions as quickly as possible—visually. Break out the pencils, and lots and lots of paper.
Rather than open your laptop too early in the design process, use sketching to produce a variety of solutions in a short amount of time. Sometimes “Move to Trash” just doesn’t cut it when you need to let go of an idea you wish you never had. There’s nothing as satisfying as crushing a bad idea and throwing it over your shoulder in disgust.
In this phase of the process, you work together to come up with storyboards, sketches, and low-fidelity prototypes to visualize ideas. It’s also a great time to start getting feedback from potential customers. And yes, let’s say it together: Everyone can draw. If Dan Roam says so, who are we to disagree?
3. Prioritize and plan
I talk to many teams who complain about “analysis paralysis”—an inability to make decisions because there are just too many factors (and people) involved. Good prioritization methods give teams comfort that even though they’re not focusing on everything at once, they are focused on the right information to make good decisions.
You can do this with a phase of convergent thinking that narrows down which ideas and solutions to explore further. There are many established processes for this type of prioritization, each designed for a different scenario:
- With the KJ-Method, you group similar issues together and use a voting mechanism to rank those issues in order of importance. It’s best when you have a large group of stakeholders who all have strong opinions about the product and you want to make decisions quickly.
- The Kano Model uses a two-dimensional axis to group issues into one of three categories: basic expectations (features that users expect as a given), excitement generators (delightful, unexpected features), and performance payoffs (features that need continuous improvement to increase user satisfaction). This method works when you want to ensure you have a balanced roadmap that addresses basic requirements, as well as innovative features that might help the product pull ahead of competitors.
- Amazon’s approach prioritizes large themes first, before going into individual features/projects to address those themes. It’s a good approach when the sheer number of features or improvements required feels overwhelming, and you need a way to structure and make sense of all of them.
These methods work because they facilitate teamwork without falling into the traps of “design by committee.” Everyone gets a voice, but not everyone gets to make decisions. That’s an essential attribute of any good prioritization method, because as Seth Godin says, “Nothing is what happens when everyone has to agree.”
In addition to providing the necessary structure to reach prioritization decisions quickly, these methods also produce tangible artifacts that can help you sell your ideas to internal stakeholders. User experience is often much less a design problem than it is an organizational problem. As much as we just want to do our work without obstruction, we can only be truly effective if we also make a compelling argument to people in other parts of the organization. These structured prioritization methods make that step reasonably painless by helping you produce written and visual records of your thought process.
Once done, you should be able to narrow down ideas to a select few you want to build and test—and be comfortable that those ideas have the best chances of meeting your user needs and business goals.
The output
The artifacts produced during product discovery depend on the scope and nature of the project. Sometimes it’s a few sketches on the back of a napkin that a developer uses to start prototyping; sometimes it’s a big PowerPoint document summarizing the process and key takeaways in an effort to bring senior executives along for the ride.
Regardless of the physical output, at the end of the process you should be able to answer the following questions with ease:
- What is the problem we are trying to solve?
- For whom are we solving it? Why should they care?
- What’s the vision for the solution?
- What’s in it for us?
- What’s our implementation plan?
The real power of this process is that it will give your team comfort that you’ve introduced enough variation into the design process to ensure you’re not climbing the wrong mountain to a local maximum.
That’s fine for you
“This is nice,” I hear you say, “but we’re a fast-moving startup and we don’t have time to sit around and talk.”
You do if the alternative is failure, brought on by an unhealthy addiction to pretty things that lead to 15 minutes of fame, but not much else.
We’re entering an interesting era in web design. Retina displays might not have mass adoption yet, but it’s only a matter of time before they become the norm. We’re also seeing a level of interest in typography and graphics last experienced when color CRT monitors became a thing. There are many shiny objects out there, and if we focus on those (or focus on impressing the VCs that are focused on them) to the neglect of usefulness, we might find ourselves in a situation similar to that of only a few years ago, when we built Flash intros on every site just because we could.
In other words, product discovery is essential for startups precisely because we’re in a time of such exciting visual innovation.
We cannot let the allure of the visual tear us too far away from the usefulness of the products we develop. It is true that failure teaches us a great deal about what works and what doesn’t. But it’s so much cheaper and more effective to fail at a variety of ideas on paper than it is to fail at one full-blown, VC-backed idea. As Color can probably attest, it’s hard to come back from that.
Together, we can avoid building digital BrasÃlias—projects that generate buzz, but don’t meet the needs of the people who live there. So let’s discover before we build. 
References
[1] If you’re new to journey mapping, see: The Anatomy of an Experience Map, Using Customer Journey Maps to Improve Customer Experience, and Building a Vision from a Journey Map.
Translations:
Italian
- Illustration by Kevin Cornell
RSS readers: Don't forget to join the discussion!