Does your work ever feel like a circus? Yeah, mine too. I feel like I am always performing. My most popular performance is the balancing act – it turns out that product design is a series of balancing acts.
As designers and product managers, we are always balancing the good-cheap-fast triangle. No time to fully consider a design? Whiteboard it and check off “cheap” and “fast”. The lone UX designer with a bit of lead time? Check off “good” and “cheap”. Sometimes, the balance is determined by outside forces. Other times, we have more influence.
Let’s take a look at one of the most popular balancing acts that I call “Thinking vs. Doing”.
Thinking vs. Doing
How much time should you spend understanding the problem you need to solve and finding the best solution before starting implementation? You can ask this question when embarking on a new product design or when adding a small enhancement. Of course, the larger the project, the more important it is to understand the problem before getting too far with design. Larry Marine likes to say you should “avoid solving the wrong problem very well.” He’s absolutely correct.
Now, I use “thinking” facetiously. Understanding the problem requires more than thinking. It’s research and research is work. From the outside, though, it may look a lot like thinking, so you may be tempted to cut corners at this early stage. For example, I know that an idle engineering team can result in pressure to speed things up.
Here are some tips to do the right thing while keeping things moving and knowing when you are done.
Start with Assumptions
List your and your team’s assumptions about the product/feature as soon as you can. Involving the wider team will ensure you generate a comprehensive list. These assumptions include the market, users, proposed functionality, and technology. You can capture these as simple lists, provisional personas, requirements, business plans, or whatever combination works for you.
Next, for each assumption, determine your confidence level. Items with high confidence should still be validated, but these are also areas where you can press forward with design and implementation right from he start.
Involve the Entire Team
Is that idle team pressuring you? Get them involved in the research. At all times, it’s best to have engineers tag along on research activities and help analyze results. But, if the team is truly waiting on the research, you could quickly train a few people (who have the proper aptitude) to do some independent research activities.
Enough is Enough
Do enough research to validate or invalidate these assumptions and better define the problem space. The best guideline I’ve heard is to research until you are no longer surprised. As soon as commonalities start appearing, you should be able to firm up some of the initial assumptions and commit to bigger decisions.
You should also continue research activities throughout the life of the product (for example, regularly usability testing), so it’s OK to shift focus to solutions as soon as you can.
Solving the Problem
Once you think you’ve got the problem defined, it’s time to design the solution. This is another activity that needs careful balancing as you could easily search a long time before you find the “best” solution. At this point, I like to bias the effort towards finding a “good enough” design quickly.
Determining “good enough” is a blog post (or book) of its own. However, your problem definition will help determine what that means in the product’s context.
Keep Moving
It’s important for the entire team to continuously make progress. As a designer or researcher, one of your responsibilities is to communicate with the team. This communication needs to include more than deliverables – it needs to include the entire process so everyone shares a sense of progress.
Finally, after doing such a good job at balancing the problem discovery work, never lose sight of the problem you are solving. The act of design and feedback often leads to new insights into the problem and it’s important to incorporate those and adjust as you go.
Jay Zipursky 