How to Avoid “Best Guess” Product Design

It’s always exciting to listen to an entrepreneur with a big idea, or to a well established company that wants to deliver more innovation to their customers. At Rocket, we are lucky to find ourselves in this position a lot, and it never gets old. Ideas and innovation are a huge part of moving our society forward and finding ways to solve problems with technology.

Unfortunately there is a flip side to a great idea, and that is the ability to turn it into a product that customers actually want to use. And that’s no easy feat. What is easy, unfortunately, is running full steam ahead to design and build a product that “feels” right or that you believe will meet customer demands before you actually ask any customers if that’s true. So many teams make assumptions about what their customers want and need, and then go and build products against those assumptions.

This often leads to what we refer to as “best guess design”. Best guess design happens when a team builds their “best guess” of what will work without really knowing, often by synthesizing their thoughts together into what they predict will work best. Best guess designs feel like they support a product vision, but aren’t exactly rooted in any real customer feedback. Many times, teams working on a new product have talked about it for months and months but simply haven’t had time to really do deep research on it, or they don’t have the budget to hire an outside agency to help them. So they end up waiting for an opening in their schedules, grabbing designers that have time who then make their best guess on how to support the product vision, and that’s what the design ends up being. This is how a surprising amount of design is done!

Unfortunately, many teams later discover that their best guess designs weren’t actually good enough. Maybe there was a critical part of the experience they missed. Maybe there was a whole customer audience they didn’t consider. Maybe there was a competitor they hadn’t known about. Or, most likely, they couldn’t gain adoption by end customers and they aren’t sure why.

So, how can companies avoid investing a tremendous amount of money in best guess designs and ending up with a product that doesn’t work?

The answer is to validate your vision along the way with usability testing.

We are big believers in conducting usability tests early in every project that we take on, and using testing and other methods throughout a project to continuously validate product decisions. Usability testing is often one of those things that is talked about widely, but rarely practiced as much as some product and design organizations would like you to believe.

We believe usability testing, sometimes through a design sprint, is the ideal way to kick off any new product initiative because it helps teams better validate their product vision and get valuable customer feedback before committing engineering resources to fully build it out. And we believe it’s crucial to continue to test with users as you build out the product. This will help you gain confidence that you are building the right thing instead of the cool/flashy/most exciting thing. And you find out the hard truth if the assumptions you made about your product were right from the start (congrats!) or destined to fail (shit!) and need to be adapted.

While this is easy to say, we recognize that creating a culture of ongoing testing is not easy. But we’ve seen it done successfully and we’ve learned a lot in the process.

Here are some practical ways to create a culture of validation through usability testing that you can put to use in your product and design organizations:

Don’t think about testing as a one time thing

People tend to treat usability testing and research in general as this giant, heavy thing that requires a lot of time and investment. In larger companies, big UX teams often formalize testing and perpetuate the notion that there are only special people who can conduct it. In some cases they require product teams to write a proposal to get the UX team’s time to do testing. It’s a lot. And it doesn’t always have to be that way.

So don’t think of testing as a special, rare event. Testing is not should be commonplace in your organization, a regular habit. It should be part of your product and design team’s toolbox that they habitually use all the time to test assumptions and validate visions.

Think about your sprints as testing sprints

One way to start thinking about usability testing in a lightweight way is to ask your agile team (perhaps during sprint review) “what are the assumptions that we’re making here that we could test next week?” If there is a good candidate then you can plan out a test and execute it in a day or two in that next week’s sprint. It likely doesn’t feel like “oh we can just do some testing next week,” but that’s the way it should feel.

Have designers do the testing

When we take our teams into a new company and have our designers conduct usability tests, clients are often shocked. But for many situations this makes sense. Outside of the product owner, designers, more than anyone, need to know the results of usability tests. Having a design team that is as close as possible to direct user feedback will lead to more informed, user friendly and impactful products that customers love. And it will make your team much more efficient and agile.

Test, and then move on

After you finish usability tests, have a debrief meeting with a bulleted list of outcomes. And then move on. We don’t recommend spending hours writing a report or rewatching videos of the tests. It’s important to move on because you’ve learned what you wanted to learn. Writing up a huge report is a time suck and halts progress coming out of the tests. And oftentimes, the need for a large report means the people that should have been in the room for the tests weren’t in the room. Of course we recognize there are times where teams need to write up the results to share with senior stakeholders, but the key is to do it right away and keep it as light as possible.

Usability testing will allow your team to do a better job of validating assumptions along the way and answering the big questions about your product vision that sometimes go unanswered until it’s too late. Creating a culture that tests early and tests often will show in the final products that are met with excitement from your end users, and will make your team smarter, more efficient and more connected to your end customers.