Using learning outcomes as a framework for your discovery phase
Design research is, at its core, a learning process. We engage in design research to learn about the people we’re serving through the design of solutions or the development of tools.
At the earliest stage of the design process, we often call this learning the discovery phase. We spend time learning before creating solutions, aiming to equip ourselves with a deep understanding of the problem space. Sometimes we say that we’re conducting research to ensure we’re “building the right thing before we build the thing right.”
We learn about people (often referred to as customers, users, or actors) and the complexities of their contexts. We learn so that we can develop cognitive empathy and ultimately so that we can co-create more effective, valuable, and meaningful solutions.
In a cross-functional design and development context, our discovery not only includes learning about people; it also includes learning about our clients’ organizational needs, the information or content they share, the flexibility/constraints of the technology we’re using, and any other elements that will help us deliver value to the people we’re serving.
How do we get started?
While specific methods and steps should be thoughtfully designed for each project, my design research process—especially for designing complex services and large-scale software systems—generally aims for the learning outcomes listed below.
Note the emphasis on outcomes as opposed to deliverables or outputs: we’re aiming to build understanding and apply that new knowledge in our work.
Yes, we will create artifacts and research deliverables along the way, but the underlying goal is to arrive at a place of shared (and shareable) understanding. For that reason, you might think of the list below as beats in this learning journey rather than deliverables to make.
Ecosystem
Learning Outcome
Be able to identify actors (types of people who will be using our product and service), their human networks within the service ecosystem, major entities in their experience (e.g., institutions or groups that they interact with in relation to the service), and how the organization—our company or client—fits in.
Why?
Before we can understand the details of individual customer journeys or steps in a flow—or even recruit people for research studies—we’ll need to visualize who we’re talking about (as types of people), how they’re connected to our company, and perhaps other people or groups within our service space. We’ll visualize dominant patterns to ensure our team has the same mental model as we move forward through the project. This step is often recursive: We might draft assumptions and then revise those assumptions after we’ve learned through additional research.
People in Context
Learning outcome
Be able to describe how the various actors in the ecosystem (those who will use your product) are similar to and different from each other—specifically in terms of their contexts, goals, special needs, barriers, and interconnections. Identify the actors (users or customers) with the most common and most distinct needs to anchor additional discovery, design, and development.
Why
Before we streamline services and service journeys, we need to have an understanding of the people we’re serving. We paint a picture of people/roles by type to illuminate differences in contextual affordances, barriers, language needs, learning or informational needs, and emotional or other drivers. Understanding what they do, what they need, and how they differ helps us co-design ideal solutions down the road. We reduce risks associated with solution-adoption and accessibility, potentially saving the organization from costly investments that won’t deliver results.
Journeys
Learning outcome
For the people we’ve identified as key customers (or users), be able to describe typical (iconic) current-state journeys and touchpoints. Be able to describe similarities and differences for each main customer type. Be able to identify the pain points and opportunity areas within these journeys and explain why these areas exist.
Why?
Before we develop specific solutions, it’s helpful to paint a picture of what’s happening now to both solve for specific challenges and amplify the good. Journeys show us an actor’s chosen steps toward a goal, touchpoints involved, and the pains and joys they encounter during that process, along with measures of success.
Underlying Service Systems
Learning outcome
Be able to describe service flows and the supporting processes—the “backstage” of a set of journeys. Be able to identify the pain points and opportunity areas within these service flows and explain why these areas exist.
Why?
Mapping services as they exist helps identify data silos, system silos, service gaps, and opportunities.
Business Goals and Technical Constraints
Learning outcome
Be able to articulate business goals, measures of success, and technical system goals or constraints.
Why?
Within a business context, any design principles related to the needs of human actors should be framed within the context of organizational goals and technical constraints. It’s particularly important to identify and articulate measures of success. The team—researchers, designers, product managers, engineers—will need to have an understanding of how flexible the project is. Are they aiming for easy wins and temporary solutions or a full system overhaul?
Outside Models (Landscape Review)
Learning outcome
Be able to describe industry best-practices and other winning models for similar services. Be able to articulate why winning models work well in their own contexts.
Why?
Zooming out of our own service’s ecosystem to look at comparative models helps us identify patterns that can be leveraged in the redesign of new systems and processes. Looking both at the surface patterns (what works well) and the underlying support (why these models work well) can help the team ideate.