Reduce the Risk of Getting It Wrong

I recently came home and was smacked in the face by the smell of death in my kitchen. After days of impersonating a bloodhound, I determined it was coming from under the fridge. Cue me googling “Stainless steel fridge delivered tomorrow.” I quickly checked the dimensions of the cheapest one to ensure it could fit through the doorway (something I failed to do earlier this year when my new appliances couldn’t make it past the garage), and I hit BUY.

The next day it arrived in all its scentless glory. And they could even get it inside the kitchen! Success! I reveled in my expedited and skillful problem-solving. Then I tried to open the door. There wasn’t enough clearance for the very thick door to open before it jammed up against the wall.

In my rush to solve the smelly situation, I didn’t take the time to properly research all the dimensions of the appliance. My only concern was getting it quickly and making sure it could get inside the house. I didn’t consider that it might not be able to OPEN. You know, one of its basic primary functions. My lack of proper research and understanding of potential failure points has become a daily nuisance for my entire family. 

This is similar to what many businesses do when it comes to designing digital solutions. They power forward, focused on one or two things that seem the most important, without doing the proper research or validation to ensure they’re effectively solving the problems that matter most to users. 

I think about design research in terms of what I’m trying to learn. It’s not a one-and-done thing but rather a consistent effort across the project. Each type of research has its own function in reducing risk at different points of development. Here are some things to consider when determining what kind of research is best for the problem you’re trying to solve. 

What problem are you solving? 

This is where research begins — diving deep into the problem space. The most important aspect of this research is to keep it open and unbiased. Many projects approach this step as a way to validate an already-formed solution or hypothesis. But this can drastically limit the potential of your ideas. Focusing on solving problems (instead of building features) allows you to keep your solution options open. 

So if you’re designing an e-commerce site, for instance, rather than asking online shoppers what credit cards they typically use to purchase online, you should dig into the actual need — they just want to pay for things. There are many ways to solve this that don’t involve credit cards. Maybe the right solution is PayPal or cryptocurrency. By focusing the question on something so specific (and predetermined), you cut your product off from potential innovation. 

Who are you solving it for? 

Most projects allow some time to get to know your users, but sometimes that information isn’t focused on the most important and impactful information. Too often, I see summaries of users (via personas and the like) that include irrelevant details like where they live, what sites they like, and their age. This kind of “demographic stuff” is usually not critical to the design of your product — unless there’s something very targeted about what you’re building. This approach can create personas differentiated by irrelevant information or assumed stereotypes (like older = less technically savvy).

Focus on things like: What are their needs and pain points? How do they use the system? What are they trying to accomplish? What’s missing? Then think about how the different answers to these questions affect how someone uses your system. This is how personas should be created — where are the needs between users significantly different from one another? 

For instance, dividing personas by whether someone is technically savvy or not is far less helpful than segmenting them by how long they’ve been using the system (novice vs. expert). This lets you better tailor solutions in a way that addresses the real delta between user needs, as opposed to superficial ones. 

Is it the right solution?

Iterative usability testing throughout the design process (as opposed to after things are built) can be a huge way to reduce risk. As you’re designing a product, it’s important to continually ask yourself, “Is this the right solution?” It will quickly tell you if you’re on the right track before you invest development time and money into building it, making it much less expensive to shift gears if needed. 

For example, if you’re designing an inventory management system for thousands of items, you should validate that your information architecture, taxonomy, and tagging systems are optimized for users before you build the whole thing. Finding out you got that wrong and having to fix it after the fact is much more costly than slowing down a bit as you design to give yourself time to test your ideas and solutions.

More research = less risk

Doing research is expensive and time-consuming. It’s also hard. But it’s the single best way to reduce risk when designing a new product. 

Missing even a small detail — like forgetting to measure the thickness of a door — can have a huge impact on the user experience and overall success of a product. If you don’t take the time and effort to invest in really understanding the problem space, user needs, and constraints of possible solutions, you may end up having to buy yet another new fridge. Or be left to deal with the consequences of having a non-functioning left door.

Natalie Kurz (she/her) is Head of Product Design at Postlight. Get in touch at natalie.kurz@postlight.com.