In the past, I’ve written about the importance of models for explaining the UX process. I explained that I approached UX Research with the Service Design Model in mind, to illustrate how research happens at different points of a product’s lifecycle and that at each point there are different methods for answering questions. This is all fine and good, but I’ve realized that explaining what “discovery”, “exploration”, and “listening” mean in the context of UXR can be challenging when you’re not talking to non-research professionals. Most people will get what “testing” means. The idea of putting an actual artifact in front of someone and figuring out if it works as expected, is pretty straight froward. Plus, most of us can associate the concept of asking and answering questions to testing. But there’s more to research than testing. How do you explain that to someone who has never done research?
I started a new job at Fidelity Investments the beginning of June. From a UX Designer/Researcher, who did everything from design facilitation, wire framing, visual design, and CSS, I switched into a Sr. UX Researcher, a specialist. So I’ve been thinking about this question a lot more. And when my husband randomly asked me “so what exactly is your job now?”, I felt the pressure to answer.
Luckily, I had a light-bulb moment. My husband is a developer, so I needed a model that closely tied my work to his. Fidelity approaches research in a 3 phase framework: Right Problem, Right Solution, and Done Right. Essentially ,the “discovery” stage is “right problem,” “exploration” is “right solution” and “testing” and “listening” are “done right.” I realized this was the perfect way to approach my husband’s question. I explained that researchers answer 3 different kinds of questions by observing users through different methods: “what do users want or need that we can solve for?”, “how exactly do we solve or build for what they need?” and “is this thing we built working like it should?”
Now the Fidelity framework goes in more detail about what approaches to use and utilizes more detailed research questions, but this surface description suffice to show the value of my work. In fact, that is the very same reason why Fidelity uses the framework to democratize research. It takes away abstract research concepts and better aligns them with the design and development process. Designers and developers are focused on solving problems, and so are researchers, but we often run into the problem that we speak different languages. By talking about problems and solutions explicitly, the Right Problem, Right Solution, and Done Right framework, better aligns designer, researcher, and developer communication.
Does this mean I will stop thinking about my work in terms of the Service Design model? No, not exactly. I still think the Service Design model has its place. Some people are comfortable with terms like discovery and exploration, and distinguishing between testing and listening has its value. However, this example does showcase how having more than one way of explaining research is useful.