Evolving Human-Centered Design Part 3

A Framework for Practice and Praxis

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

In Part 1 of this series, we discussed Microsoft Mixed Reality Design and UX Research’s approach to human-centered design and the gaps we identified therein, particularly when working with users that participate in teams, groups, and other collective settings.

In Part 2, we explored the ways in which we learned to address those gaps, through the definition of user structures, identifying how individual and collective roles impact user needs, and mapping all of the users’ journeys together in a collective journey as they work to accomplish their goal(s).

In Part 3, we will take the lessons that we learned and place them in a framework to help researchers and designers apply them in their work. Much of this content will be a reflection of the topics discussed in Part 2, but from a process perspective. There are four primary steps in this process that we’ll cover:

1. Application of heuristics to determine relevance to the population

2. Building the user structure

3. Mapping the collective journey

4. Defining the critical path

Step 1: Application of Heuristics to Determine Relevance

The first thing that we want to do with this framework is to avoid wasting anyone’s time [author’s note: just after crossing the 7,000 word mark across the three parts]. To that end, we believe that human-centered professionals should start their process by asking a few key questions about their prospective users to determine whether the framework applies.

Figure 1: Determining the relationships between users, their journeys, and their outcomes is important for understanding how to approach learning about and designing for their needs.

Do the user’s journeys intersect or interact with others? Do we expect them to be individual, independent operators within their domain, or will they be organized into groups in a meaningful way? Will they be collaborating with others? Do they have relationships such as partnerships, authority structures, or some other connection to others?

If we do expect our users’ journeys to involve other people, do these interactions and relationships have an impact on the users’ needs and outcomes, in terms of how they might interact with a product within the domain? Do we expect the way the user will approach the product to be affected by the people around them? If so, how? Will they be collaborating? Will there be resource constraints that introduce competition, or skill synergies required to multiply their potential? Are they working towards collective outcomes that go beyond their individual tasks and goals?

If we get to the point where we believe there is a system of users that we’re interested in rather than just individual users, do the people in the system take on unique roles that can impact how a product must meet their needs? What are these roles, how do they impact the users, and how will they impact design considerations?

If none of these questions resonate within the intended product space, then a traditional, individual human-centered approach is likely fine. We believe that these cases are becoming increasingly rare. However, if any of these questions apply to the user base, then we recommend considering the developing processes below to help provide consistency in how we learn about, and design for, our users.

Step 2: Building the User Structure

After identifying if this process is relevant to the user population, we then move on to building out the users’ structure, or defining how the people are organized within the population.

There are infinite shapes and characterizations this process could take depending on what the population is or how the product is intended to support them, and thus it is untenable to try to list out all the possible structures here.

Instead, we’ve started to create some basic guidelines to pay attention to while mapping out the user structure, as well as a handful of archetypes to lean on as examples when looking at a population.

Figure 2: User structures can take many different shapes, and these are just a few examples.

When going through the structure mapping process, it’s important to make sure that the most important aspects of the system are captured to a reasonable degree (this is after all a model, and “all models are wrong, but some are useful” — George Box; we aim for useful).

If the population has a business or team structure, or some other form of hierarchy, that’s a good starting place. From there, start to define things such as authority structure (represented with verticality in the above figures) or relationships (lines) across the individual and collective users in the system, as well as the basics of their interactions (arrowed line shape).

Unrepresented in the examples above, it’s also important to consider how rigid the structure is. That is, are the roles and relationships within it well-defined and constant? In the case of the earlier firefighter example, while personnel may change regularly, the structure of the organization and its roles remain very stable. In contrast, a startup company may have multiple people performing a variety of roles that change on a week-to-week basis.

Figure 3: The roles in a startup may not be clearly defined or stable.

Next we want to determine what those roles within the structure are. Who performs the tasks that help the collective achieve its goals? How do the various roles contribute to those outcomes? As with the firefighter example from Part 2, it’s also important to consider the roles that the collective users perform, not just the individuals. The role of a video game development team is to ensure that all aspects of the game are properly accounted for and integrated across development, and it does so by supporting and balancing resources across the individual contributors within. In contrast, each of those individual contributors may have a goal to maximize the quality of their particular domain, which could generate resource conflicts that the team as a whole must resolve.

Finally, after the structure is defined and the roles identified, we start to define how actions flow through the structure and how work is accomplished. In the warfighter structure above in Figure 2, instructions are sent down from leadership, and tasks are completed by the groups below them within the hierarchy, with each echelon’s work summing into the output of the next up the stream.

In the classroom, action is primarily a flow of information between the teacher and each individual student, while it cycles through the individuals in the product team.

At this level, these structures are relatively abstracted, and the exercise of putting them together is primarily to organize knowledge of the population’s shape and function, preparing us to take these structures and expand them across the collective journey map to see how the users interact as they perform their roles.

Step 3: Mapping the Collective Journey

Mapping the user structure to a collective journey is much like a traditional user journey, with the added complication of tracing each of the users of interest across the timeline.

We reviewed one of these in Part 2 while breaking down Seattle Fire’s house fire critical path.

Part 2 Figure 8: The full Seattle Fire Department house fire collective journey

The goal for a collective journey map is to illustrate and explore how the users and their tasks work together to achieve their desired outcomes. To do this, we mapped the roles in the structure, to include both individual and collective roles, and then detailed their actions across the different phases of the journey.

This way we can show, at a high level, the actions that occur across the entirety of the journey, see the places that role interact or hand off tasks to one another, and identify any points of interest that may be important to the design process.

Collective Journey Mapping

There are many ways that the collective journey map may manifest, depending on the kinds of questions that are important to the product team. For establishing baseline knowledge and exploring roles and actions, we prefer mapping the big-picture shape of the roles participating in the journey alongside the actions they must complete for success.

The process for creating this style of collective journey map begins with defining the elements that will make up the journey map. These elements include:

• User roles: Identify the roles in the user structure that will contribute towards the collective’s outcomes. Importantly, this includes both individual roles and collective roles.
• Phases: Journey phases are logical clusters of actions that organize the journey.
• User actions: List the actions that users will perform across the journey. You may think of these as tasks, activities, or jobs; regardless of terminology, the key for this map is that we account for all of the things each user does towards achieving their outcomes.

Figure 4: The basic elements of the collective journey map from a prototype mapping tool.

After preparing the elements of the journey, we begin to organize them by defining the journey itself. First, we organize the journey into phases or segments that must be completed on the way to a successful outcome.

Journey Phase
A phase of a collective journey is a logical grouping of actions that can be marked with distinct entry and exit points. They can be thought of as the overall steps that users must complete to accomplish their goals.

After defining the phases, we can list what we call the critical outcomes within each phase. These are the overall goals of each phase, what must be accomplished in order for the users to successfully close out the phase and move onto the next.

Critical Outcomes
The outcomes within a phase that must be achieved for the users to successfully move on to the next phase in their collective journey.

If critical outcomes are the exit criteria for phases in a collective journey, then critical actions are the overall actions that users must perform to achieve their critical outcomes.

Critical Actions
The actions across all users that must be performed to successfully complete a collective journey phase.

Example: Seattle Fire Dispatch and Mobilization

Returning to the Seattle Fire Department example, we can look at these three elements of the collective journey map using the first two phases of the house fire journey: Call / Dispatch and Mobilization.

Figure 5: The first two phases of the Seattle Fire Department’s house fire collective journey, with their critical actions and outcomes.

Each of these phases logically groups a distinct set of actions and outcomes for the fire department that have to be completed to resolve the house fire — without an emergency call of some sort, the department does not know to activate or where to go, and without traveling to the location, they cannot address the fire.

The outcomes of each of these phases, and the actions required to accomplish them, are also straightforward. During the Call / Dispatch phase, the department is entirely focused on ensuring that they mobilize the right assets across the city and communicating this information to the appropriate fire stations so they can prepare.

To achieve these outcomes, the department must 1) get the call (or emergency signal) that there is an emergency needing response, 2) verify the location and information of the incident so that they can effectively 3) evaluate the response needs and organize the department’s assets and 4) communicate this plan to the relevant personnel.

Without these actions, the department would be unable to activate the necessary personnel and assets, and firefighters would be unprepared to respond.

However, if they successfully complete the Call / Dispatch phase, the actions they must take in the Mobilization phase are clear and supported. Here the department is focused on ensuring the mobilized personnel and assets arrive at the correct location. Drivers take the information from Dispatch and travel to the site, firefighters and leaders constantly monitor communications to ensure that they’re acting with the most up-to-date information. If they arrive at the appropriate location with the correct resources, they can begin fighting the fire; if not, they must re-evaluate and make adjustments before leaving the phase.

Confidence Check

In defining our users’ journey phases and critical actions and outcomes, unlike many more descriptive stages of this process, we start to introduce a stronger degree of analysis on the part of the researcher or designer. At this stage, we should have a strong enough understanding of our users’ domain, what they’re doing, why they do it, and how that supports their goals, to confidently synthesize their journey into the aforementioned components. If someone is following this process with their population and realizes they lack the information to define the critical actions and outcomes across their users’ journeys, it may be a signal to seek the missing information.

Figure 6: Can you confidently define these facets of your users’ journey?

Depending on the population, this might be attainable via existing literature. When learning about the Seattle Fire Department, we regularly referenced published materials on their organizational structure and standard operating guidelines, which define much of the micro-level roles and actions across emergencies they may encounter.

However, we strongly encourage anyone using this approach (or any human-centered approach) to regularly check their understanding and any analysis with their users. This will both ensure the accuracy of their representation in any synthesized materials as well as allow for domain experts to provide important clarity and nuance to the developed models. Again, every stage of development is an iterative conversation between the product team and the users, and this is no exception.

User Roles

Once we have the phases and their critical actions and outcomes listed, we can start to organize the user roles and actions that build towards these overarching elements.

Organizing users into logical groupings will help keep the collective journey easier to parse. One way to do this is by leveraging any natural hierarchies in the structure, as we did in the firefighter example above in Part 2 Figure 8. However you organize the users, we find it best to ensure that there is some visual association between any collective roles and the individuals that comprise them. Referencing Figure 7 below, each layer of the organization begins with individual roles from the bottom and is capped with the collective role that those users form. We also included any leadership roles with the collective roles that they lead.

Figure 7: Our Seattle Fire Department house fire collective journey groups individual roles under their collective roles. Leadership roles are placed above the groups they most directly lead.

In many cases, the user structure defined in the previous stage is much more complex than a single column as depicted here and may require creativity to properly represent them in the collective journey format [author’s note: And we would love to see any innovations developed using these methods!]. Recall that this set of roles is only the relevant personnel for a house fire; the Seattle Fire Department’s user structure was much more complex, but we narrowed it to only the roles necessary to understand the house fire response.

With the journey phases defined and critical actions and outcomes for each phase identified, and the roles organized as relevant for the journey of interest, we can finally list out the actions that users will perform in each phase.

User Actions

At this point, the figure should have a matrix defined by phases (column) and roles (row). Now we can write out the main actions that will be performed by each role within each phase. Sometimes a role may have just one action, or they may have several (or none!), so there is no need to ensure that every row of actions looks identical.

Figure 8: A generic collective journey map.

As with defining the critical actions, there is a degree of synthesis to perform in this step in determining which actions are important to list for each role. We would reference the same confidence check above — if the team’s current understanding of the users is not sufficient for completing this step of the journey map, it may be a sign that the team needs to learn more about the population.

Example: Game Development Team Concept Phase

While mapping actions to the collective journey map, it can be useful to represent relative timing across roles. For example, in this map of the concept phase of game development, this team’s actions start in a cascade as various facets of the process occur.

Figure 9: The concept phase of a game development collective journey

First the team ideates on the concept they hope to develop and pitch, and then the early stages of design work begin. It’s only after the base design has been defined that the other roles begin their actions (as an aside, it’s not always on the designer or design team to define this starting concept on their own, often the entire team and any leadership involved will collaborate to define where to start the project).

Once there is a basic concept to build towards, other disciplines begin their work. In this example, Research begins to help the team understand the audience space while Engineering prepares development tools and Art creates the visual language of the game. Test (also called Quality Assurance or QA) begins to create their test pipelines only after they have the tech from engineering, and so it’s important to show that flow of work (more on the flow in detail in the critical path section).

This representation of timing in the collective journey is primarily to help visualize the flow of actions across the collection of roles so we can identify points of collaboration, dependencies, or other interactions. In this example, ideally someone looking at the map could identify the relative order that the different roles must begin their work, but it doesn’t necessarily communicate the amount of time that each gap represents. Yet again, this is an example where the approach is determined by knowledge of the users. In most cases, we’ve found that this sort of representation does not need a high-fidelity time course, but that may change across populations and design team interests.

Ultimately, when the collective journey map is complete, we should have a high-level representation of the following:

• The major phases of the journey from beginning to end
• The overall outcomes the users must accomplish to successfully complete each phase
• The overall actions the users must perform to achieve those outcomes
• The individual and collective roles that take part in the journey, logically organized
• The major actions that each role performs in each phase, loosely organized by timing within the phase

Once the full map has been established, we can begin to look at both how actions flow through the structure as well as, at any given point along the journey, what actions are the most important to support to help the users succeed.

Step 4: Defining the Critical Path

This brings us to the last step in this process, identifying the critical path of actions and outcomes across the collective journey. But before we can define the critical path, we have to define what overall success for the users in the population looks like.

In our game development example, each individual role has their own definition of success. For Design, the goal is often achieving their creative vision and delivering it to the player, while Research is concerned with ensuring the priorities between Design and the user population are aligned. Test (QA) tries to ensure that bugs are identified and eliminated (or at least understood and prioritized).

But for the team as a whole, success is the launch of a game that meets the expectations set in development (there is a whole mess of expectations we could look at, business, artistic, or otherwise, which is outside of our scope for now). This goal is the lens through which we should approach the game development journey.

Figure 10a: The collective journey of the game development team is building towards the shared outcome of the successful launch of their game.

Their critical path follows a circuitous route that passes between the individual roles until they reach a point of integration at the end of a phase where everyone works to deliver a cohesive milestone.

Figure 10b: The critical path of this collective journey cycles between individual work and collective integration in each phase.

Following the arrows in this figure, we see that each phase of the journey begins with the individual roles producing their own work and collaborating with the other roles while the project manager helps coordinate resources and the director handles the overall decision-making. But at the end of each phase, the critical path jumps to the collective role of the dev team where they shift focus away from developing new assets and ideas and work to fit everything together.

Let’s imagine a product team that is working to deliver these game developers a set of tools to maximize their effectiveness in building a game. Using the understanding we’ve built from the journey above, we know it’s critical to support both the individual-collaborative channel of work as well as the collective-integration channel. A common issue in game development occurs when someone tries to introduce new content while the team is focusing on integration for a milestone build, bypassing the collective shift to integration.

We can imagine a case where a designer works to get a new feature into a build at the last minute while the rest of the team is working to cut the pre-production vertical slice (i.e. a build that contains a small representative experience of all the major game facets). They might complete the feature, but without the checks of the integration process, it might also break the build. A critical outcome of pre-production is to create a vertical slice to prove out the core gameplay loop and justify the move to production, and this inclusion of a last-minute feature could put that outcome at risk of failure. In some cases, a failure at this point might also cause the entire project to fail if decision-makers believe it’s not worth the investment of production.

For a team developing tools to support this process, understanding these dynamics is critically important. Perhaps the tool has a feature to lock the build from new additions at the time of integration, or it could keep a robust version record so that rollback to an unaffected build could reverse the error with little development cost. Additionally, creating clear boundaries in the tool for the developers themselves, so they are less likely to make the error in the first place, might be a valuable solution (although one that might require a deft touch and even deeper understanding of the users to land properly).

While the game development critical path frequently highlights the parallel actions of individual roles, the fire department critical path instead focuses on summed efforts within the structure’s collective roles.

Figure 11: This critical path in the house fire collective journey primarily focuses on collective roles, although there are also channels within it driven by individuals (such as the leader on site managing the incident and the dispatcher coordinating information and resources).

This doesn’t mean that each role’s individual jobs aren’t important of course — the actions at the collective level can’t happen without the individuals performing their own. But as we’ve emphasized several times now, along this collective journey, collective outcomes supersede the individual, and so product design must be optimized to support the users at that level, or risk failing to support them altogether.

Defining Your Users’ Critical Path

Several times in this series, we’ve mentioned using the collective journey map to examine the flow of actions through the user structure. When defining the critical path, this flow is where we like to start.

Figure 8: A generic collective journey map.

When we look at Figure 8 again, there is a vague shape to the action that is already apparent. Let’s assume that in the example we’re defining, the “lower org” contains two junior team members, their manager, and the collective role of these three individuals working together, while the “upper org” consists of two senior team members, the team leader, and the collective role representing both the lower and upper org together.

We see that in the first phase, the only individual active from the start is one of the individuals in the upper org, then the lower org manager and eventually a junior member begin to participate in the journey as well. By the second phase, all but the team leader are involved, who only participates for a short action at the end of the phase before leaving the third phase to everyone else.

At this point, we must again rely on our knowledge of the users’ domain and how they work to define how the critical path moves through these actions. The question we ask now is: At every point along the journey, which actions are driving towards the users’ critical outcomes? Or put another way, which actions are the most important to support via our design to ensure that the users as a whole are successful?

To visualize this, we’ll take that flow of actions and highlight the ones that we believe show where the users must succeed, and by extension, where the design must ensure they are supported.

Figure 12: Highlighting the critical path can show the areas where users’ needs can be most supported / impacted by the product’s design.

In this hypothetical, a senior member kicks off the journey alone. While the upper org collective role is active (as the senior member is part of it), success occurs at the individual level. As the phase progresses, the lower org’s manager and one junior member join as well. We can see that, because we have highlighted the individuals and not their respective collective roles, that it’s important to focus on their individual work and not necessarily their culmination during this phase. The arrows we draw can also communicate information about the flow of action. Here, the senior member’s work passes to the lower org manager, who then passes work down to the junior member. We can also see that the manager and junior member continue to work directly together, represented by the bidirectional arrow between them.

However, in the second phase, the critical path jumps to the all-up collective role, signaling that at this point, what matters is the collective output of all roles — any individual may successfully complete their actions, but if it’s not done in a way that achieves their collective goals, the users as a whole may not succeed. We again want to reiterate that in these cases, this does not mean that the unhighlighted actions are unimportant, as collective action cannot occur without individual contributions. It just means that success is achieved collectively, and so that collective action is what the design should support.

At the end of the second phase, we can see the team leader momentarily takes control, perhaps to review the work or approve the third phase, after which the leader steps away and the critical path splits.

The third phase illustrates an interesting situation where a critical path is shared between both the overall collective role, the lower org collective role, and one individual. This might represent a scenario where, as in the second phase, the group’s outcomes must be achieved at the collective level, but it’s important to understand and uniquely support the roles that the lower org and the senior member are playing during this phase.

We highlight this scenario to emphasize that defining the critical path is not necessarily an arbitration of who in an organization is important, but an exploration of how a design or product team can best support its users. The goal for this stage of the framework is creating an awareness of how actions flow through the user structure for the population of interest.

Previous stages of this framework are frequently definitional. That is, the user structure and the roles within are not something that we as researchers or designers impose on the population, but things that exist in the population we must seek to understand and describe. Similarly, the collective journey map is a description of the actions the users perform, albeit with judgement to best summarize those actions in a digestible picture.

Defining the critical path, however, requires inference from the researcher or designer. Ideally, it is founded on a deep understanding of what is important for the users to achieve success (and again ideally, gathered through iterative conversations with those users), but it also requires us to think about how the product we intend to make will fit into their work and identify the areas where we can best help them achieve their goals.

To again reference the fire department journey, we could rightfully define the critical path as simply the handoff of the call from dispatch to the regional battalion. Because there are always at least two stations mobilized, it would be “correct” to say that all action from there occurs at the collective level of the battalion.

Figure 13: The house fire critical path could reasonably focus on the Battalion for the entire journey, but it’s not particularly useful.

But this framing loses a great deal of important information regarding how the battalion achieves its goals across the journey. The three parallel channels of communications, command and control, and establishing and maintaining the fire attack, are all crucial to support along this journey. In constructing our critical path through the house fire journey, we wanted to highlight those channels, as understanding those dynamics could mean the difference between a product that provides truly enhanced capabilities for the users, or one that gets left in a storage locker.

It’s up to the human-centered professionals to first understand their user population well enough to articulate how they need to accomplish their goals, at both macro and micro levels, and then to translate that understanding into a model that can drive the team to design for the users’ needs.

Conclusion

Ultimately, the foundation of human-centered design does not change with the advent of our approach. The core tenets of HCD, building a deep and empathetic understanding of the users and their needs through iterative conversations, must still be satisfied (and in fact, attempting our recommendations without doing so would almost certainly do more harm than good). There is no substitute for, or shortcut around, good research and design practices.

But as user spaces become both more connected and diverse, we believe that these evolutions will be key to meeting users’ needs consistently. As we mentioned early on in this series, the goal of this work is to provide researchers and designers with a set of tools to approach spaces where users’ journeys meaningfully intersect, and as such this should be considered a starting point for learning about them rather than a rubric to complete.

It’s likely that, with the innumerable variation to be encountered across industries, there will be adaptation and expansion necessary from our work [author’s note: And we would love to hear about these!].

Please reach out to the authors of this series with any questions or discussion.

Related works in the field

We want to acknowledge that we’re not the first people to think about how product design should consider beyond the individual user. We conducted a literature review into the topic, and this is something that’s been discussed for decades, in various forms, although we also came away convinced that we are adding novel components to the space.

Systems Thinking

Systems Thinking is a perspective that is gaining a lot of steam lately. Numerous organizations within and outside of Microsoft have already emphasized a desire to integrate this way of thinking into their processes. The book Thinking in Systems by Donella Meadows is a popular resource for this topic.

The primary thrust of Systems Thinking is as an advocacy to understand all of the elements within a given system and how their interactions can influence the output of that system. These changes might be adding personnel, changing process, or removing restrictions.

Human-centered Systems Design

We’ve labeled this next body of work “Human-Centered Systems Design”, although it takes on several names from different authors such as Michelle Mulvey and Thomas Booth. These approaches treat Systems Thinking as a macro, or top-down, lens to understand the context surrounding users, and then use a traditional human-centered approach for understanding human insights at the micro-level.

Figure 14: Booth (2018)’s framework of complementary human-centered and systems thinking tools.

By shifting between HCD to understand the user journey and Systems Thinking to understand the surrounding context, they believe you can gain a better overall picture of the people you’re designing for.

Macroergonomics

An interesting approach from the world of human factors, macroergonomics (Brian Kleiner, 2008) seeks to understand the systems of how work is accomplished by evaluating the subsystems involved, such as personnel, external pressures, technology, and business organization. They aim to understand nonlinear processes and emergent properties within these systems.