“Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.”
– Clayton Christensen
Planning UX Research is like planning most things; regardless of the purpose, scale, deliverable or discipline, most projects share the same fundamental components: QUESTIONS inform a team’s ACTIVITIES which in turn, produce ARTIFACTS that either inform or define the solution. Achieving a successful outcome is a result of defining clear, relevant objectives and having the right mix of resources, value and expertise. This common ground sparked the idea for the Questions, Activities & Artifacts (QAA) UX Research Roadmapping framework that I developed for Torstar. (publishers of The Star and many other Canadian newspapers and digital properties).
The opportunity: Teach a Team to Fish…
In my role as the UX Research lead on Torstar’s Digital team, I helped to build the UX research practice, which included infusing a user-centred and data-driven approach into decision making. In some ways, I started out as a UX research “team of one” and we soon realized it simply wasn’t possible – or even practical – for me to do all of the team’s user-centred research myself.
In order to accomplish this, we needed to empower the Product Managers and Designers with the knowledge and skills to build a “customer-centric culture and capability”. For me, this involved planning and executing UX Research projects, harvesting insights, introducing various UX frameworks, initiating several knowledge sharing programs as well as defining operational requirements.
As the saying goes: “Give a [team] a fish and you feed them for a day; teach a [team] to fish and you feed them for a lifetime.”
Above: An excerpt from my UXR Ops Status report described survey responses from Product Managers and Designers. The findings indicated that knowledge sharing efforts over the previous six months were successful at building certain “evaluative” UX Research skills – but there’s always room for improvement.
The Challenge: Why did we need UX Research Roadmapping?
After surveying the team and facilitating a number of knowledge sharing sessions, it was clear that the Designers and Product Managers had gained some valuable qualitative research skills, but it was time to address other challenges we were facing. Even though the team had become more comfortable planning and executing research activities they were familiar with, finding the time to learn new methods and tools was still a significant barrier to doing research.
Even worse, we often faced very tight product release timelines, so sometimes it was difficult – or impossible – to incorporate significant research findings into the design in time for scheduled development sprints. Over time, this can lead to frustration that drains a conscientious team’s morale – especially when we have the data to support the UX improvements.
Another concern I had was that most of the team’s UX research effort was occurring during the Design phase (typically in the form of unmoderated usability tests to evaluate concepts and prototypes before going to sprint). While these “evaluative research” efforts were valuable for quickly informing usability issues, they were often limited in scope and depth. An evaluative approach was no substitute for “generative research” activities which would allow the team to more deeply understand our reader’s needs, journeys and pain points before embarking on costly design and development activities.
Addressing all of these challenges required a solution that would improve the quality and relevance of research activities at each phase of the process. It also needed to be aligned with our product design process, offer exposure to a variety of relevant research methods and provide the team with the ability to identify and plan their own activities. This is where UX Research Roadmapping came in…
Above: The “4Ds of Product design with Human-centred Perspective” captures a typical product design process (4Ds; Define, Design, Deploy, Drive) and layers on a human-centred perspective (Inform, Validate, Optimize).
The Process: Creating Activities and Artifacts for Knowledge Sharing
Providing the Product Managers and Designers with exposure to a bunch of UX research lingo and methods was necessary before we could do roadmapping – but it had the potential to overwhelm them! It was important to introduce this dense amount of content in an efficient and digestible way – enter visual thinking!
I used Miro to create the following diagrams which mapped some high-level, human-centred questions and research methods to the “four phases of the product design process”. Then I introduced these concepts and visuals to the team in a collaborative workshop. I also included these visuals an accompanying catalogue which served as a detailed reference for all of the listed research methods (which we referred to as “The Methods Menu”).
Above: The UX Research “Methods Menu” overview diagram captures the four phases of Product Design process mapped to the various UX Research methods that can be conducted at each phase. this allowed the team and leadership to visualize where most of the team’s UX research efforts were occurring. This was intended to be an exhaustive list of methods, but was relevant to the Torstar digital product team (who produce a variety of editorial and transactional digital products).
Questions, Activities & Artifacts: Using common ground to create a UXR Roadmapping Framework
I had observed that when people work together on a project (regardless of the purpose, discipline, scale, role or phase), there are common elements which are necessary to achieve a successful solution: people typically had QUESTIONS, which determined ACTIVITIES which would produce ARTIFACTS which inform and define the solution. This common ground sparked the idea for the Questions Activities & Artifacts (QAA) framework.
I designed the QAA Framework with the goal of creating a consistent and straightforward way for the team to identify and prioritize their research activities. This approach allowed us to start with the big questions Product Managers and Designers were asking – which ensured any activities were relevant to their needs – while giving me a valuable bird’s eye view of the entire team’s research requirements. This ensured we could put the necessary UX Research skills, knowledge and infrastructure in place. As a result, we became better equipped to integrate relevant, human-centred research activities into product roadmaps and release schedules.
QUESTIONS
Let’s recap: Most projects typically begin with a period of discovery, where team members have QUESTIONS they need answering. These questions inform the subsequent ACTIVITIES and also reveal who is necessary to answer the question(s) and/or is needed to create the resulting ARTIFACTS.
There are always questions – so many questions! – and they vary depend on who’s asking and what their objectives are. Depending on the project’s complexity and how high stakes the answers are, deciding which questions to answer (ie defining scope and aligning on goals) can often be one of the biggest challenges a team faces when planning research and design activities.
To introduce the QAA Framework, it made sense to start with high level questions (but the granularity of questions can be adjusted to reflect the team’s specific needs and planning requirements):
- What phase are we at?
- What decisions need to get made?
- Do we need to… Explore? Validate? Inform? Assess? Prioritize? Compare? Optimize?
- What activities and artifacts already exist which might help us answer our questions?
- Who do we need to talk to to get the answers we need (eg, stakeholders, customers and/or subject matter experts)?
ACTIVITIES
Along the way, each team member has activities they need to perform to move the project forward. Like most projects, the scope of activities is impacted by constraints; typically time and cost. Many of these activities are dependent upon (or enriched by) a previous activity.
In the context of UX Research, activities might be as straightforward as reviewing an analytics report or chatting with a stakeholder. Or they might involve planning a diary study, facilitating a discovery session, recruiting participants, crafting a survey or interviewing customers.
ARTIFACTS
Artifacts vary depending on their purpose, the producer’s vocation and the phase of the project. For example, a strategy deck or customer survey might inform the early stages of a product design project. Later, a sketch from a whiteboarding session might evolve into a user flow and prototype. In the context of UX research activities, a script for a usability test or a video clip from a customer interview can be considered artifacts.
Above: I introduced the team to the Questions Activities & Artifacts Roadmapping framework in a knowledge-sharing workshop. Once everyone had a handle on the framework, each theme-based product team was equipped to use the framework in a way that suited their needs (eg in a white boarding session, as a Miro template, etc). Once identified, the activities could also be layered on to the Product Manager’s Product roadmaps in Roadmunk.
Above: This example of the Questions Activities & Artifacts (QAA) framework was used to introduce the framework in a workshop. Here, the QAA framework outlines a redesign project, but it can also be “zoomed out” and and layered on to a product roadmap – or even be used “zoomed in” to help identify requirements for specific research study.
What did the QAA Research Roadmapping framework accomplish?
1. Made UX research activities visible, relevant and timely.
The QAA Roadmapping framework allowed us to identify and prioritize research so that activities could be layered onto Product Roadmaps and incorporated into release timelines. This ensured research findings were timely and actionable. This visibility was especially valuable at an organization with low “design research maturity“, where some UX Research activities were overlooked until it was too late to incorporate insights into the design.
2. Surfaced UXR infrastructure and resource requirements.
The QAA Roadmapping Framework allowed me to get a bird’s eye view of UXR Activities, long before design and development were to occur. This allowed me to identify and prioritize UXR infrastructure and resources (such as creating a Participant Panel, compensation budgets, requesting more seats for UserTesting.com, etc). It also helped us identify when a more specialized research skill set, tool or consultation was required.
3. Silo busting and opportunities for cross-pollination
This comprehensive perspective creates the potential for UX Researchers to identify shared research goals and avoid duplication of effort across teams. For example, perhaps one Product “pod’s”research insights could be relevant to another Product Team’s decision making. Or maybe there’s an opportunity for the Product team to collaborate on a survey with the marketing team, etc.
