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”.
But the answers to some questions, I’ve found, are essential to any design project. When I had clear answers to start with, I was always glad I did. When I didn’t, I always regretted it. So I wrote these questions down. As a sanity check, I compared my list to advice on product visions developed by Scott Berkun and Marty Cagan – smart people who have thought about new product development even more than I have. I made some adjustments, but I found their lists were pretty similar, although they discuss some organizational, engineering, and marketing concerns that I’ve omitted for the sake of focus.
Here’s the list:
Sum up the idea in one to two sentences.
When you bump into that busy executive in the lunch line and he asks you what your new project is all about, what do you tell him? Better yet, what do you tell a friend who knows nothing about your company’s strategy, politics, and culture? A strong, jargon-free focus statement helps everyone remember what you’re making and why. Be brief and memorable. Avoid buzzwords and bureaucratese.
You may want to revisit this one after answering the rest of the questions, since you might find they make you think about the idea differently.
Who is this for? Who is this not for?
Describe your target user. What is she like? Which of her characteristics are most important to your design project? Depending on the project, these characteristics might relate to what she wants, how she behaves, what she knows (or thinks she knows), who she is, etc. Get them down, get them clear, and get them concise.
Likewise, describe any users that someone might THINK you are designing for, but that you are not. Pay special attention to users that you will be tempted to listen to (perhaps they are particularly vocal, available, or powerful) but who are dissimilar enough from your real targets that they may lead you astray.
What problem(s) is this going to solve for them? What problems will it not solve?
Although it might seem obvious, be sure to pick problems your users really care about. Lots of design projects fail because they go after problems that, while real and obvious, just aren’t very important to users.
Make sure you aren’t trying to boil the ocean. Pick ONE or a small number of really important problems and solve them really well. If there are problems people might think you are trying to solve but you aren’t, make that clear.
What are these people using today to solve this problem? How will our idea make life better for them than what they are using today?
There’s almost always an existing solution in place, although it isn’t always a high-tech one. List popular competing products, but don’t forget popular analog solutions – printed signage and scribbled notes are still preferred over digital technology for many, many purposes.
You need to know what people are using today because that’s what your users are going to compare your product to when deciding whether they really want it. During design and throughout the project, you should be making this comparison too.
What risks do we run of failing to solve this problem for these people?
From an experience perspective, what might we plausibly do that could cause the solution to fail? Knowing what users are using today and why competing products have failed or succeeded in this space can really help answer this question. Perhaps certain tasks might be too hard to learn, or too tedious to perform repeatedly. Or perhaps the product might feel too clunky and ugly to carry around, or appear too boring to stand out when compared with other alternatives.
What qualities must our solution have to successfully solve this problem?
Learn from users’ existing solutions and the risks you identified. If you think your solution will fail if it doesn’t feel snappy and performant, then “snappy and performant” had better be somewhere on the list!
I usually like to list these qualities in the form of design principles. Sometimes more visual approaches are appropriate, such as mood boards. In old school organizations, these qualities might masquerade as high-level requirements.
How will we know when we have solved this problem for these people?
Many designers forget to decide up front how they will know when they are done – how they will define success. We all want our designs to be great… but what is “great” for this project? If you’re unclear on this, you might waste time over-optimizing a part of the design that doesn’t matter, while much more important qualities get the short shrift. Or, worse, when push comes to shove and deadlines are looming, you might settle for a solution that doesn’t make the grade.
Objective metrics can do wonders since they’re hard to argue with (either the user study participants completed the task or they didn’t), but not all important design qualities are easy to measure objectively. Even for fuzzier qualities like “trust” and “fun”, decide up front how good is “good enough”. I find comparisons are helpful, e.g. “the design needs to feel at least as trustworthy as Bank of America’s website”.
I always get answers to these seven questions for every new design project I start. Often, the answers aren’t clear at the outset, and I need to do some design research to help me answer them. But even when there’s no time for research, even when we think we’ve got the answers all figured out in our heads, its still critical to write them down. If it saves me even one wasted design iteration, one misunderstanding with a product manager, developer, or other designer, then it’s paid for itself many times over.