0

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.

0

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).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.