Methods Driving My Philosophy
I will start this section on a very high-level and then go more and more detailed until user research artifacts are surfaced. First, let's see how I sometimes approach user research in a product setting, in cross-functional teams. My approach varies in its specifics based on industries, businesses, and sometimes even individual products sold by that business, so this diagram just illustrate one approach out of many:
The above diagram shows how the user research team interacts with the product team (usually the product managers), conducts the research with perhaps feedback for the product managers, which can cause them to redefine the product or and lead to more research, or pass on that research to designers so create designs around that research. When it comes to the research approach I lead in my team, I generally break it down into four buckets, shown in the image below:
The above diagram is a high-level overview of how I define my user research processes.
Strategic research and
concept research are also often classified as
generative research and
concept testing. I explain my definition of these kinds of research later in the page. These types of research
can take a while and are usually not part of a user research sprint because of how long they would take. Same goes for activities like coming up with a user research strategy or a playbook. They just require too much runway to fit into a classic agile sprint. Card sorts, surveys and tree tests, unless you have a predefined pool of participants or multiple people working in parallel to do analysis, are too large to fit into an Agile sprint as well. Diary studies are impossible to fit in an Agile sprint as well. However, evaluative and maintenance research (usability tests and interviews that most UX designers are familiar with) can be done as part of an Agile sprint because they often do not take as long. To go deeper and see my
methods in an Agile sprint, click here.
