When we talk about how to design something for a given user experience we are usually discussing the trade offs between a feature request, and the best solutions we can bring to address it. This solution however comes with varying degrees of uncertainty behind how much we actually understand the user’s needs. As discussed in my previous need validation blog post, this can be a lot more deceptive than it originally sounds to get right.

Being honest about uncertainty.

Certainty Chart

All snark aside, helping reduce user uncertainty surrounding design choices is a big part of what makes UX design important in modern product design. Often we end up making incorrect assumptions about user needs because we are not correctly identifying what level of user uncertainty we are dealing with. Before saddling up to the whiteboard and mocking up the solution, start by assessing your own certainty that you fully understand the problem:

  • What is the scope of this problem?
  • Who does it effect?
  • Is it a small tweak to an existing user experience or a whole new workflow or set of features?
  • How do we know the user is asking for what they really need?
  • What is the risk of not addressing this problem?
  • What is the risk if we get the solution wrong?

Time constraints

In a perfect world, UX would always have all the time it needed for every sort of comprehensive discovery and design iteration needed to correctly address the user issue. However, the often hard reality of project timeline and scope of work can make a leaner UX process preferable to many teams. Similarly, discovering the perfect way to implement a user feature AFTER the development team has already shipped a poor one is worse for the user. So it’s worth taking the time to properly assess what your timeline is and what approach to UX is most appropriate given the limitations:

  • What is the timeline for fixing this problem?
  • Where does this problem fit in the product roadmap?
  • Are we reacting quickly to an urgent problem?
  • Are we responding to trends in the market?
  • Would we ship a partial fix or phased solution to this problem?

Choosing the right tools

Some UX tools and processes are naturally a better fit for higher levels of uncertainty in product design than others. For example processes that involve collaborating to collect user requirements, interviewing customers about the issue in question or other sorts of UX discovery processes are much more important when dealing with very uncertain user problems. Similarly, some techniques tend to be much more time intensive or require larger commitments to complete. It’s important to be sensitive to both the time constraints for your efforts as well as what level of user uncertainty you are tackling.

To help you decide what UX techniques strike the best balance between your problem’s user uncertainty and time constraints, I’ve made a handy chart that demonstrates some examples of how I think about these trade offs in UX. Let me highlight for you some of my favorite UX techniques and summarize how they fit into this chart: Certainty Chart

Certainty Chart

Design Workshops

  • Certainty : Low - Moderate
  • Time : Low - Moderate

Design Workshops are excellent for quickly scouting out ambiguous design needs by bringing coworkers, stakeholders and experts into an environment where ideas can be produced, and more importantly refined and focused through an interactive activity. Clearly some workshops can be more work to coordinate or difficult to find time in others schedules, but generally these are a fairly lightweight way to facilitate a focused discussion around the problem in question and is especially useful if the problem is in uncertain user territory.

Certainty Chart

Need Validation

  • Certainty : Low
  • Time : Low - Moderate

Need validation can be done a number of ways, including by producing need validation storyboards for testing with users. However this can really be as light weight as calling some customers to discuss the problem and seeing if they all agree about the nature of the problem or not.

Certainty Chart

Market Research

  • Certainty : Very Low
  • Time : Moderate - High

Market Research can be time consuming due to the nature of getting access to research materials, doing the analysis of what competitors or other companies do to solve this problem, and ultimately presenting the findings back to the team for review. I think watching the market can be a good way to evaluate some UX solutions, however it can also not be useful if the problem domain is highly unique, or competition keeps their solutions confidential or difficult to compare.

Certainty Chart

User Story Mapping

  • Certainty : Low - Moderate
  • Time : Low

User story mapping requires usually some level of workflow awareness, either conducted through prior user research or at the very least an existing feature workflow. It can be be a great way to define the various details and contexts around the actions users take before and after your solution. Ultimately this continuity of how your problem fits into the user workflow is a big part of what will make your solution feel natural and intuitive to the user or not.

Certainty Chart

Personas

  • Certainty : Moderate
  • Time : Moderate

I highly recommend taking the time to at least establish some modicum of user modeling such as s a persona. Or at the very least some sort of traits and motivations list you can refer to when designing product functionality. Proper persona modeling can be an involved effort, but for purposes of simplicity I think what you are really looking to produce is an objective standard of ‘who’ you are fixing this problem for. If you find yourself without this frame of reference it is very easy to lose sight of the users need and instead focus on what seems most natural to you or your team to do.

Certainty Chart

Design Radiators

  • Certainty : Moderate
  • Time : Moderate - High

Sometimes you have ideas that need to marinate in the open for a while before they can properly get sorted out as a solution. Design radiators such as open whiteboards, mood boards, personas or other sorts of public (within your private office) design artifacts that passively share the state of the design with the larger organization.

Certainty Chart

Design Review

  • Certainty : Moderate - High
  • Time : Low

Design review is simply taking time to review the current state of your design thinking with the larger team. It is perhaps the single easiest and lightest weight way to get input and discuss the challenges in working through a design together. The only downside to a design review is that I’d recommend that it come after a discovery process so that you aren’t starting from nothing. The review itself can be very short and simple, with an opportunity to refine the design and iterate on it, but you should start with some sense of what the solution generally needs to be first.

Certainty Chart

Prototypes

  • Certainty : Moderate - High
  • Time : Low - High

When people hear about prototyping in UX they often are imagining very complicated technical code based prototypes. While that is indeed a thing that many teams do, and it definitely has its place, what I mean here is more of a clickable prototype or paper prototype. These should be proxies for evaluating user interaction with the application you would end up building to make sure all the earlier decisions made about solving this user problem actually work out in action. Clearly, the more you know about your user’s problem before getting to this step the more likely you are to succeed here.

Certainty Chart

Mockups

  • Certainty : Moderate - High
  • Time : Moderate - High

Mockups are sort of the bread & butter of many UX processes. It’s surprising to many people to hear that there are actually UX processes that don’t even need mockups to succeed. However, sometimes it’s a good idea to visualize to a high fidelity how something will actually look and feel. The cost of making high quality mockups has gone down as tools such has sketch, Adobe XD and others have made maintaining designs easier, but it is still often a non-trivial commitment to develop mockups for larger projects and should only be done after the basic user needs questions have been answered fully.

Certainty Chart

Usage Metrics

  • Certainty : High
  • Time : Low

Seeing what your users actually do in your application can be a very fast way to quickly answer narrow UX questions. Of course this is predicated on having embedded metrics of some sort in your application, and history of usage that can help answer your question. The main downside to this approach is just that you already have to have something relevant to your problem in production with usage that you can meaningfully measure. There are many problems that can fall into that category but sometimes you will not have adequate data to learn anything from.

Certainty Chart

Usability Testing

  • Certainty : High
  • Time : Moderate - High

When it comes to testing your implementation of the solution, usability testing is the most common sort of pre-release validation for the changes involved. Its main risk is that you are very likely reviewing with a product that is nearing completion, and so changes at this stage can be quite costly. If you haven’t done other techniques to mitigate user uncertainty before usability testing you may be in for a painful surprise.

Certainty Chart

Style Guides

  • Certainty : High
  • Time : High

A style guide’s main advantage is that it codifies the UX/UI patterns of your application for consistent usage. It makes it easier for users to learn how to use a part of your product once, and then simply leverage that knowledge in other contexts that use the same component. Clearly the craft of creating a style guide can be a consderable effort, and requires a high degree of user certainty before it really makes sense to do from UX perspective. However, if you can it is a great investment into your products future consistency to document and codify any new UX/UI elements within a style guide.

Where to go from here

Not all UX designers use every one of these techniques for all their projects, nor should they depending on how certain they are about the users needs, or how limited their time is to make the change. I hope this gives you a tool to use when you are considering what level of user uncertainty you are designing around.