The role of need validation research

Much of the time UX spends designing enhancements for products is devoted to the creation of mockups of user interfaces and user workflows. However, before a designer can attempt to solve a given user need it’s important to verify that the underlying need exists at all in the mind of our target user.

This is the realm of UX need validation research, and it is a much higher order level of user research than traditional usability testing. In need validation research, we aren’t asking the user about a specific solution, we are primarily trying to ascertain if the underlying problem is real or imaginary.

It may seem odd that we could have imaginary user needs, but the reality is that it’s much easier to come up with features that are related to a problem and assume they will help a user’s true goal, than it is to study users and derive their underlying needs through targeted research.

The danger of not doing any need validation in your design process is it increases the chance of totally missing the mark in terms of the motivations behind requests for specific features. You need to check if your internal model of what a user is trying to accomplish aligns with their own intuitions.

One such process for verifying user needs is called a need validation storyboard, and it is a useful test for confirming user needs in a quick and fun moderated usability session.

What is a need validation storyboard?

Need validation storyboards are a tool for testing if a user recognizes the need presented to them in a simple storyboard. The basic premise is to focus on showing a user a problem and an incredibly vague solution to that problem to see if they respond positively to the underlying need.

Your goal is to hear the user relate the similarity of the problem to their own concerns. If you observe any indication of indifference, confusion, or rejection of the premise of the need and its solution, there is a good chance your concept of how to solve this need differs from the user’s own intuitions.

How to create a need validation storyboard

Creating storyboards for need validation can seem daunting, but it’s actually a surprisingly simple thing to create. My favorite way is to use the good ole fashioned sharpie and post-it note. This may seem arbitrary, but one of the keys to good need validation storyboards is absolute simplicity. By using these crude tools, they force you to not focus on detail as much, and really require you to think about clarity in your storyboard panels to get the need across visually.

You are also going to need to write out your story for your 3 panels, as well as a lead to get the conversation started. These should be as brief as possible, but capture the need you are trying to confirm with the user.

Need: Track company wide compliance training completion

The need is kept secret from the user during testing. You don’t want to explicitly ask what need you are looking to verify because you don’t want to bias the user’s opinion. The ultimate success of this exercise comes down to the user articulating this need in their own words without you needing to give it to them.

Lead: How do you make sure everyone is completing their training? (without sending angry emails)

This is a question the moderator (usually you) will ask to the user to warm them up as they reveal the storyboard. It can serve as both an icebreaker for the topic, as well as an anchor point for the storyboard’s content to connect with the user directly.

Situation: “Jane has been asked about the current status of the annual mandatory employee training by her boss. She seems to recall a few remaining incomplete employee assignments, but isn’t certain.”

Solution: “Jane checks the compliance report and sees that a dozen or so folks have still not completed their training. She clicks a button to automatically send a reminder to them.”

Resolution: “Jane is glad she didn’t have to write a personal email reminding them they have training. Because it’s a reminder from the product nobody will think they are being targeted personally.”

These sections are the actual text describing each panel of your storyboard. You’ll want to read these verbatim to your user during your test so that they can simply follow along with your visuals. I highly recommend writing these first so as to not overthink what visuals you want to present to the user before you really get your simple user story cut down to a few sentences.

After your story is written, you can now illustrate each panel of your storyboard. If you make a mistake, just crumple up the post-it and try again. Think about what the key elements you want to present to your user are before drawing, and then just try it out! This can take as little as a minute per panel, or as long as you need to get it looking right to you.

Once all your panels are completed, I like to scan them into the computer making them black and white, and adding a little shading to help make them attractive to the user. Ultimately the goal is to simply print these out on paper as a physical or digital storyboard that you can easily present to the user during the test.

Now you have simple, ready to test storyboard to ask customers about a specific need they have. These storyboards can be a very useful tool for talking to users because they appear very simple and fun immediately to users. There is very little of the anxiety or fear that comes with being asked to criticize very high fidelity mockups or prototypes because the content itself is clearly not final in any way.