Evolving Human-Centered Design Part 1
Our approach to Human-Centered Design, and the gaps therein
Special thanks to the following co-contributors to these works: Jennifer McLean Oliver, Ph.D., Sean McGlynn, Ph.D., Gabe Maricich, Matt McCurdy, Ph.D., Urba Mandrekar, April Martin, Ph.D., Alante Fields, Mario Martinez, Ph.D., Scott Petill, Boyu Zhang, Derek Ellis, Ph.D., Andrew Lambert, Ray Salas, Joe Munko, Grace Hwang
Human-centered design (HCD) encompasses a set of approaches that help research and design professionals align their products with the people that will use them. There are numerous approaches across different industries, such as the foundational HCD approach developed by IDEO, as well as more emergent approaches such as the liberatory design approach. These, and many others, have a common focus of systematically putting the human that will use the product at the center of the design process.
These approaches are critical components of many research and design processes in product development, and serve as the fundamental underpinning for entire swaths of the user experience discipline.
In this series, we will discuss the work we’ve conducted in human-centered design over the past four years. Over this time, we discovered ways to adapt our previous HCD approach, particularly when working with users in collective settings, to better serve our target populations. We now believe that these insights are a novel and important expansion to the HCD field at-large and wish to share them so others might benefit from our experiences and, ideally, expand upon them in turn.
In fact, we interviewed research and design colleagues across the industry about these topics, all of whom agreed that they did not have a matching framework and that it would be beneficial to their work. Additionally, we surveyed 23 other researchers within Microsoft on the topic; most respondents believed their tools or methods had limitations with designing for users in group settings.
Importantly, we do not believe that this is a replacement for human-centered design, but an evolution that adds a framework and process to the exploration of important aspects of many user populations.
This piece is Part 1 of 3 connected posts on this topic. In Part 1, we will discuss our previous approach to human-centered design to set the foundation of this conversation. We will also discuss the gaps in the approach that we encountered with our user populations.
In Part 2, we will explore the insights that our team identified to address these gaps, expanding the focus beyond the individual and accounting for the needs of users in groups or collective settings.
Finally, in Part 3, we take the insights from Part 2 and explain a process for systematically integrating them into a human-centered research and design workflow.
Our Previous Human-Centered Design Approach
The approach previously used by Microsoft’s Mixed Reality Design and UX Research team is an iterative process that focused on understanding the user, the problems they are trying to solve, and the ecology in which they may use a given product.
This process begins by defining the context of that ecology, made up of three primary components.
- The Users: What makes the product desirable to the users in a domain and how does it meet their needs?
- The Business: How is the product viable for the business? What is the value proposition that will grow the business or support its goals?
- The Technology: What solutions are feasible given available technology or future technology in an actionable timeline?
Identifying the space where these three pieces of context overlap, a product space that accounts for user needs, meets the business’s goals, and works within the current technological constraints, should provide a strong foundation for human-centered product development.
For the purposes of this series, we’ll mostly be focusing on the User Needs component and how understanding the users’ needs and their desired outcomes is critical to supporting the design process.
Figure 1 shown below visualizes the general flow from learning and ideation to product launch and outcome measurement. This process begins on the conceptual end of the spectrum, aimed at understanding the users’ context and the product space. We also continually check and update our understanding of these users by maximizing the number of conversations and touchpoints we have with them. These conversations are often interviews, but could also happen through field research and observation, survey, or formal testing in cases where there is already a product.
These conversations should also include the product team, whether they are attending (or participating) in research sessions or discussing the results with the research team, taking the iterative insights and feedback from the users to guide product ideation and prototyping, and eventually into launch. The key to this process is that every stage goes back to the user to update our understanding of their needs and how we can best help support their outcomes.
For this series, we’ll go through this model in three main phases to establish a baseline for the insights that lead to the evolution of this model to better account for our user populations: Defining the users’ context, identifying their needs and outcomes, and continually learning and iterating our understanding of the user space.
Define the Context
When defining the user context, we start by asking several simple questions:
- Who are the users?
- What do the users need to do?
- How are they currently doing it (if at all)?
When we ask who the users are, we try to think beyond the basic population category (i.e. video game players, information workers, firefighters). This is important to understand because there are different backgrounds and identities within the population, and characteristics that help define who they are as people. Additionally, we also want to understand if there are important differences between groups within the population that could impact how they would use a product (i.e. subpopulations or segmentations). Finally, are there people in the population that assumptions previously made may overlook, or people that might be underrepresented in past product work or research?
Understanding how these characteristics may impact the ways a person engages with a product space will help everyone in the product team better empathize with them and may help unlock design considerations that may not have been otherwise understood with a surface-level definition of the population.
What the users are trying to do is perhaps a simpler question to initially answer. Are they trying to accomplish work in their profession or hobbies? Are they seeking entertainment through video games, media consumption, or another activity? Are they pursuing creative endeavors? These questions will help shape the ways that the product can assist them (i.e. should it be making them more efficient, or helping them have more fun?). After identifying these high-level goals, we can better understand how to approach the details and complexities therein.
Similarly, how they are currently accomplishing their goals is key to understanding the users and product space. What solutions are they employing? What works and isn’t working with their current tools or activities? What is the opportunity to improve upon their current state? What are the environmental, technical, or other constraints the population must work around? Is the problem space already well-understood, or is the product solving for something new?
Sometimes, the product space may be an entirely new innovation and there is no current solution to understand — in this case, this question may need a bit more creativity to answer, but also makes understanding the users’ needs and the outcomes they hope to achieve all the more important.
Identify Needs and Outcomes
The questions we ask while defining the users’ context should lead to an understanding of the basic reasons that a person would engage with a product, the things they’re trying to accomplish and the fundamentals of their user journey —using “Jobs to be Done” terms, why would they hire this product?
We define the fundamental reasons to engage with a product as user needs.
User Need
A human need that must be met and/or conditions that must be true for the user to accomplish their goals, and the fundamental reason why a person might engage with a product. Needs are solution-agnostic, as the person’s Need exists regardless of product intervention.
Ex: See, Learn, Play, Communicate, Collaborate, Engage
User outcomes then are the end-result of meeting these needs, allowing the person to achieve their goals.
User Outcome
The end-result the user is pursuing and has hired the technology or product to achieve, either at the fundamental or program level. User Outcomes are solution-agnostic, as a person’s Needs may be met through varied approaches.
Ex: Students understand and retain the material presented in a classroom lecture.
A student in a classroom has a basic need to Learn and an outcome of meeting this need is that they can both understand and retain the material from the lecture.
There is also a great deal of nuance involved in the process of transferring information from the teacher and lecture material to the student, ensuring they have the proper tools, information, and strategies to unpack the lesson information into understanding, and then exercises to practice using the material until it is firmly encoded and retained in memory. Finally, the learning outcome may be measured through a test, assignment, or other demonstration of mastery.
That nuance is important to consider when developing a human-centered understanding of this classroom learning process — we cannot build products to better meet the needs of people if we don’t first understand the full context in which their needs must be met and the routes to achieving their outcomes.
Learn and Iterate
Each step of our human-centered process, from defining the users’ context to launching the product, is tested against user feedback to facilitate constant iteration and improvement, and to build a greater working model of the users themselves.
Early on, this learning may be primarily conceptual, fueled by interviews and secondary research into the users’ domain, but we also try to get prototypes in front of users as early as possible. These could be as simple as wireframe mockups or lo-fi models from available materials (we have used spare lumber in the past) or as complex as a 3D printed model with retrofit electronics. The goal is to get the ideas in front of users to begin collecting feedback and answering design questions to drive towards the next prototype and iteration of the cycle.
This creates a cyclical flow of prototype creation and measurement through user feedback to sharpen the design direction, the overall understanding of the users, and how the product space fits into their lives.
Gaps We Identified with HCD
While we believe that a human-centered approach is necessary to create the best experiences from our products, we have encountered several areas where current HCD approaches do not adequately guide research or design professionals in how to account for several important user contexts.
Since our team was formed in 2018, we have used the approach detailed above with the individual user as the human at the center of our work, from which we developed robust (so we hope) sets of user needs and outcomes used to guide our partner teams and programs. However, as the complexities of the organizations that our users participated in became clearer, as well as how roles and tasks were varied throughout these organizations, we realized that our definition of user needs and outcomes as universal across individuals in the population was insufficient for developing solutions that would truly meet their needs.
It’s important to note that as we discuss the below gaps in HCD, these do not necessarily mean that the professionals will arrive at incorrect conclusions when using a typical human-centered approach. Instead, we argue that they are left to discover on their own how best to overcome these gaps without any a priori guidance, which would force the researchers and designers to redesign wheels unnecessarily at best, or open them to systemic errors from inadequate assumptions at worst.
With this project, we aim to allow others to take advantage of our learnings in human-centered design and take a structured approach to interrogating the problems their users face.
The below gaps are likely problems that many research and design professionals have encountered, and perhaps, created ad hoc solutions while working with their target population. Our reason for specifying them is that they do not seem to have a generalizable solution via HCD process, which we intend to provide.
Gap 1: Focus only on the Individual
Bringing back the graphic from Figure 1 we use to illustrate our process, the inclusion of a single user at the heart of the Venn diagram is emblematic of the gap that motivated our exploration of these topics: Human-centered approaches focus only on the individual user.
In domains where a product is designed for use by a single person as a personal device, this has made sense. Personal computers were often meant to be used by a single person. The famous Don Norman teapot likely wouldn’t need to be solved beyond the considerations of the individual.
However, there are numerous domains where people use products in group or collaborative settings. Business, education, video games, public services, and so on all involve the intersections of people. These spaces are seeing an ongoing trend for increased connectivity and collaboration, which Microsoft’s own products are increasingly tailored to solve.
Human-centered approaches acknowledge these collective use cases and encourage understanding them as part of a user’s context. However, each person is seen as an independent user to solve for that may occasionally cross paths with another, and each of those crossings are solved at the individual level. The assumption under this perspective is that collaborative or interconnected domains are networks of individual users, and the individual is where the most important action occurs. This assumption leads into the next gap.
Gap 2: No Guidance for Intersecting Journeys
We often describe the ways people use products with a user journey map, likely a familiar tool for many readers. User journey maps are simply ways to visualize the end-to-end interactions that we expect a user to encounter within a product domain. These maps can be simple or complex, covering a single interaction such as a point-of-sale terminal, or a multi-phased progression through numerous interaction models and user roles.
However, consider the more complex user journey below. This journey details a user’s journey with the Wikipedia mobile interface, where a user begins as a mobile reader, primarily using the platform to consume content. Eventually, this user might begin to contribute as well, moving them into the second loop where they would begin to produce content, share insights, make edits and join discussions.
There are several points along this journey where the user will intersect with other users’ journeys (contributing, producing and sharing, knowledge transfer and discussion), but the map itself only implies these intersections. It’s up to the individual researcher or designer to determine how to handle these instances.
In general, HCD frameworks don’t have a defined process for handling these cases. In our exploration of this topic, we interviewed multiple research and design professionals who said that they would typically decide if those other users were relevant to the design process and map out additional individual journeys when applicable, and we found nobody with a defined system for such scenarios. While this lack of direction does not mean that they would reach incorrect conclusions about the users, it does leave room for errors.
One potential error is the assumption that all users will have the same journeys, or that their needs and outcomes will look the same within the domain.
It’s possible that this is the case for a population of interest, but if there are meaningful differences within the user space, this assumption could lead to significant gaps in the product’s ability to meet users’ needs.
Another potential error is the assumption that users are generally independent, or that their interactions have no bearing on the design of the product — users performing their journeys in silos.
There are many cases, some of which we’ll discuss in Parts 2 and 3, where the intersection of user journeys doesn’t just mean you have two users doing similar tasks in parallel, but that the tasks they do change in important ways when they work together. In the case of the Wikipedia editor above, you could imagine two users editing the same article from conflicting perspectives. Without proper tools or process to mediate the arising issues, the user experience could be degraded significantly. And these intersections need not be adversarial — collaboration, as mentioned above, produces emergent properties in the user space that have to be accounted for to truly understand user needs and outcomes. This leads us to the final gap.
Gap 3: No Concept of Collective Needs and Outcomes
Meeting individual needs is necessary, but may not be sufficient, to facilitate success for the people using a product. In these points of interaction, collective outcomes (such as the resolution of a wiki editing war) may supersede the individual goals of completing an edit. In domains where intersecting journeys are more fundamental, such as in collaborative workplaces or education settings, understanding collective needs and outcomes becomes even more critical.
This is why we are going to advocate that researchers and designers identify where these intersections exist within their populations of interest early in the design process (to include users that operate in groups, although there are other scenarios where individual users take part in intersecting journeys) and account for those collectives throughout the human-centered design process.
Wrap-up
Thus far in Part 1 of this series, we’ve introduced Mixed Reality Design and UX Research’s approach to human-centered design, as well as the three primary gaps that we identified in this approach when working with user populations where user journeys intersect or interact.
- Focus only on the individual user
- No guidance for intersecting user journeys
- No concept of collective needs and outcomes
In Part 2, we will explore the insights that our team identified to address these gaps over the last four years, expanding the focus beyond the individual and accounting for the collective needs of the users.
Finally, in Part 3, we will take the insights from Part 2 and explain a process for systematically integrating them into a human-centered workflow. Importantly, we do not believe that this is a replacement for human-centered design, but an evolution that adds process and a framework to the exploration of important aspects of many user populations.
