Does Usability Tests and Product Experience Maps go Under Discovery or Define Stage?

Question

I'm creating education materials for my company on UX to help better educate the team and secure more funding for UX at the company. But as I was reading how we define stages of UX I came across what seems to be a paradox / conflicting information.

The discovery stage to put it very briefly as I've understood it is to explore the problems whether it be on your own product or problems prospective users may be facing, building empathy. Then this moves to the Define Stage where the team forms alignment on evidence based results from discovery.

I always assumed Usability Testing was part of the Discovery Stage and you can build personas and experience maps based off of these in the define stage. Because if the Define stage is to form alignment, an experience map allows you to take pain points and convert them into goals which hands off to the development stage.

However in my research I see that Usability testing is not often put in the "Discovery Stage" Example here and here .

In the above examples only user interviews are included. Usability tests can include pre and exit interviews which aid in the discovery stage. Usability tests also help discover what problems users are facing. So why are these left out?

I see Usability Tests are Discovery and Product Experience Mapping as defining.

But I don't want to commit to this on paper without reaching out to my fellow UXers and hear their thoughts and get some guidance. I never tried to break down the process so defined before and I am running into material that makes me feel my process of DISCOVERY Interview -> Usability Test -> DEFINE Experience Map -> Personas -> DEVELOP STAGE is wrong.

Thanks for all those that contribute in a positive way to this discussion.

Answer 1

In an ideal world, you would expect to include Usability Testing at any stage that you are trying to design for a user interaction to validate the research and/or assumptions you are making about design decisions.

In the practical world, it is very difficult to schedule projects and UX activities so that they are in sync with product development timelines, and you may discover more things during the project so there is no specific place where Usability Tests should be locked in (and you might find that multiple rounds are scheduled at different stages of the project).

Where you choose to do this and how often you do this (which will determine what you end up doing in the testing process) is generally constrained by project budget, access to users and the process/method you propose for the testing. And then when you get the results back you'll have to also make adjustments if it turns out that your assumptions were not quite on the mark.

As for the product experience map (not sure exactly what format this entails for your project), it is an artefact that can be used to capture and summarize the main journey/experience for the end-users, and can be created at any stage of the project when you have enough research output to synthesize the information into a usable artefact. However, you should also be continuously updating this document as the research and design matures so that this document is an up-to-date reflection (or versions) of the research and product development cycles.

I think the more you think about the project in terms of the information you need and what you do with the information, the more it will help determine/tailor the activities and the artefacts that you need (there are good articles on this elsewhere). So rather than going with a prescribed method or plan, just have something that is loosely based on the closest approach that fits your project and be prepared to tweak or adjust some of the activities along the way will work the best (this involves putting in some time buffers in the project schedule).

Answer 2

If we consider the Double Diamond model, usability testing is not the best choice on Discovery. According to the NN Group, Discovery is not a validation exercise. The Discovery explores more than it validates. The most important thing is to define the problem to be solved and the research process helps us to do this in depth. The Discovery is not synonymous with user research, but it needs user research. Having a UX Researcher on the team is a dream, we will work together to investigate based on the real problem, Discovery is not a one-person job. The real Discovery helps us look at successful outcomes, explore available technologies and much more. All we need to design the best solution.

Once you've mapped out everything about the problem, work on opportunities and ideas to solve it. Conduct exploratory interviews and put all risks on the table. Work to validate the risks and use the best techniques to do so. If usability is one of those risks, usability testing fits.

This entire process can be performed more than once. We can run the first diamond as many times as we see fit before starting the second diamond and back again.

Go ahead!

Answer 3

You shouldn't build personas off of usability studies because usability studies reveal findings about your product, not about your users. The interviews preceding and following a usability study are meant to complement the study itself and to put it into the proper context, and they're not equivalent to in-depth interviews performed as part of user research. Their goals and premises are different.

Personas are supposed to represent specific target audiences of your product's - reflecting their characteristics "in the real world" - their needs, motivations, demographics etc. They shouldn't be rooted in the product usage itself, a persona based on "users who can't figure out the navigation" or "users who couldn't find this button" is not an effective persona to work with.

Furthermore, recruiting participants for your usability studies requires that they match your personas (since you can't just run it on random people), meaning that the personas are a prerequisite for usability studies, not the result.

If you're doing Discovery for an existing product, you need to study the way it behaves "in the real world", using analytics or any ethnographic method. In Usability Studies you are working in a controlled environment, giving your participants predefined tasks. So you will only find things you're already looking for, you're only looking under the proverbial lamppost, you can't really find things outside of your scope - which is not a great fit for the Discovery phase.