How to judge your design and research efforts

Within the sport of road cycling, Mark Cavendish is widely acknowledged to be one of the greatest, if not the greatest sprinter of all time. 30 Tour de France stage wins like the one above don’t happen by accident after all.

Like all great sprinters, Cavendish is a master of judging his efforts. He’s a master of hiding like a ghost in the peloton until the sprint at the end of a stage; of conserving his energy on mountainous days and of doing the bare minimum when it’s apparent that a race isn’t going to finish in a sprint. Rather than aiming for maximum effort each time he races, Cavendish will instead aim for the minimum effort required to guarantee a win.

Judging their efforts is certainly key for cyclists like Cavendish. It’s also a skill that product designers must master. Find out how to judge your design and research efforts so that you’re also putting in the right level of effort required to win.

What’s required to win?

I’m sure that you’ve seen something like the venn diagram below before. For any piece of work, design or otherwise there’s a balancing act between cost (or resources required), speed and quality. You want something fast, then it’s either going to be of a low quality, or it’s going to cost you. You want something cheap, then it’s either going to be slow, or low quality. You want something that is fast, low cost and of a high quality. Good luck with that!

Work is always a case of balancing cost, quality and speed

A designer’s natural inclination will always be to aim for high quality; to crank the design and research dial to the max and to provide their users with the best possible experience. The thing is, it’s not about delivering the best possible user experience, it’s about delivering the right quality of user experience given the constraints, and what’s required to be successful. Let me explain with an example.

I’ve been using Zoom the now seemingly ubiquitous video conferencing tool a lot recently. It’s fair to say that I have a bit of a love, hate relationship with Zoom. I love the fact that there’s a free version (limited to 40 min calls), and that the video and audio are generally of a great quality. I hate the fact that when my internet connection is poor, I can only switch to audio only when using the web version of Zoom (you can only switch off your own video on the desktop version). I hate the fact that until recently the key ‘End Meeting’ action was a hard to find text link (it’s now finally a button). I hate the fact that when you’re screen sharing with Zoom you suddenly lose access to key features like chat, and that Zoom have generally disregarded all the good design patterns established by popular video conferencing tools, such as Skype and Webex.

The design of Zoom isn’t the greatest, but it’s good enough

From a product designer’s perspective there is a lot that could be improved about the design of Zoom, and yet it’s a hugely successful product. This is not just down to the freemium business model but also because the performance and reliability of Zoom is so damn good. Sure, the design could be improved, but it’s good enough. As Mark Cavendish might say, it’s the minimum effort required for the win.

Design is always about trade-offs, but before you can trade speed against cost and quality you must first understand the problem being tackled and explore the scope of the work required. Let’s look at how you might do this.

Framing the problem

I’ve written before about the importance of understanding and framing the problem being tackled (see why every design should start with a problem). As part of framing the problem, you should look to answer key questions such as:

  • What is the problem?
  • Who is affected?
  • When and where does it happen?
  • Why does solving the problem matter?
  • What is the minimum required to solve the problem?
  • What level of user experience is required to solve the problem?
  • How will the success of a solution be determined?

Don’t expect to be given all the answers to these question on a plate. It’s part of designer’s job to find this stuff out. This is likely to be through a combination of talking with stakeholders, domain experts and of course user research.

Scoping the work

It’s not enough to just frame the problem, you must also scope the work required. For example, what are the time frames? What technical constraints exist? What are the resources available? Look to answer the following key questions:

  • What are the time scales? How fast does something need to be delivered?
  • What resources (money, people, tools etc…) are available?
  • What are the constraints? (time, people, technology etc.)
  • Who are the key stakeholders?
  • Are there dependencies on other work?
  • Is there any prior work/knowledge that can be built on?

Redgate (where I currently work) have created an awesome product design interlude / brief canvas to help when framing a problem and scoping the work to tackle it. A PDF version of the canvas is also available.

The product design interlude / brief canvas by Redgate

How to judge your design and research efforts

Having framed the problem and scoped the work you can start thinking about how much design and research effort should be thrown at it. A great way to kick off this conversation is by answering 2 key questions:

  1. How much do you already know about the problem?
  2. What level of user experience is required to solve the problem?

The first question will help inform how much research effort should be thrown at the problem. Put simply, a well understood problem will require less research effort than one with lots of unknowns and assumptions. The second question will help inform how much design effort should be thrown at the problem. If only a great user experience will do, then a high level of design effort will be required. If on the other hand, like Zoom, a rich and creamy UX isn’t necessary to be successful, then don’t expend too much design effort delivering one.

The below matrix is useful for mapping problems against the level of design and research effort that is likely to be required. A PDF version of the matrix is also available.

It can be useful to think about how much is known about a problem and how critical UX is to solving it

Conclusion

As the great Leonardo Da Vinci once said, “Art is never finished, only abandoned”. The same is true of product design work. There are always improvements that can be made to a design, more research questions that can be answered, and an infinite number of iterations that can be completed.

Just like Mark Cavendish you must become a master of judging your design and research efforts. You can’t win them all, but by aiming for the right level of effort required to be successful, you stand a much greater chance.

Resources

See also

Image credits

Former techy turned UX Jedi. Checkout out my blog (UX for the Masses) for more about me.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store