Evolving Human-Centered Design Part 2

Insights to Improve Human-Centered Design

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.

• Part 1: Our Approach to Human-Centered Design, and the Gaps Therein
• Part 3: A Framework for Practice and Praxis

Those gaps in our own human-centered process were highlighted as we learned about public sector organizations, such as warfighters and emergency responders, and how they operate within their respective domains. We had to shift our approach to learning about them as well as how we generated and communicated findings with our partners; traditional single-user design thinking simply did not align with their reality.

These populations operate in structured hierarchical organizations, where every individual has a defined role, and every part of the organization must operate in concert. Those factors together highlighted several key insights that have since changed our human-centered design process.

It’s interesting to think back on it, as the changes were made in stride over lunch discussions and study post-mortems, conversations where we slowly chipped away at the ideas and constructs that helped describe what was important to prioritize. Eventually, we realized that we needed to codify these ideas, and then abstract them in the hopes that they would benefit other researchers and designers in other domains (we later confirmed this by interviewing and surveying industry peers). In this post, we’ll go over the most important of these insights:

1. User structures connect people in their domain

2. Role-based needs reflect users’ differing contexts

3. Collective users are distinct from their constituent users

4. The critical path highlights what users need the most

Insight 1: User Structures Connect People in their Domain

When users’ journeys interact, they often form consistent structures that are critical for understanding the users’ context, particularly if these interactions are relevant to the intended product domain. We’ve termed these User structures.

User Structure
A formal representation of the intersections and interactions of user journeys in a defined structure that includes the groups, hierarchies, roles, and relationships that inform how users are connected within their population.

The first thing you might think when you see this is that it’s just an org chart, as that’s where this idea started — everything an individual in the military or emergency services does is influenced by their place in their organization, and so understanding that organization is crucial.

But in addition to the general structure of whatever organization the user may be in (and organization here could be formal or informal — a social group or a matchmade team in a competitive video game may also fit this description), it’s also important to understand the various roles and relationships that exist within the structure. We need to understand how users fit in with other users, what they do within the system, and how their relationships to others influence the system as a whole.

We also believe that this model extends beyond business organizations. User structures can take on many different shapes, and they are relevant across many contexts. Here are a few examples that we’ve been evaluating:

Figure 1: Hierarchy, this is the structure that most typically fits in with a business. Users are nested in a hierarchy of authority and teams, and their interactions tend to flow up and down through these layers of hierarchy.

Figure 2: Egalitarian, a flat structure, such as in a product cross-functional team (e.g. designer, engineer, researcher, tester, program manager) where a set of individual contributors collaborate together to combine their expertise. There may or may not be a guiding authority over the team.

Figure 3: One-to-many, a classroom in the education space is an example of a one-to-many structure, with a single point of authority delivering information to many independent students — here the primary interaction is a series of two-way exchanges centered on the teacher.

Figure 4: Baton race, where a device is handed off through a series of users, starting with the IT administrator who sets up the device, then the teacher and parent who ultimately distributes the device to the student.

It’s easy to imagine defining structures for entertainment domains, such as the crews, performers, and audiences of a live concert, matchmade teams in an online video game, or the distribution of media to families with varying audio-video equipment in their homes (or perhaps with different accessibility needs). While we have been working to develop some archetypal structures as starting points for evaluating user populations, it’s likely that each population will have unique elements that require research and investigation.

The key point of this insight is that it’s critical to understand both the big picture structure that surrounds and connects users, but also the nuanced details of how actions flow within the structure.

Insight 2: Role-based Needs Reflect Users’ Differing Contexts

One way that nuance manifests is through distinctions across roles within a given user structure.

Defining user needs in a target population is a major step in human-centered design, and ideally the needs we define will be generalizable across the population — they’re intended as a high-level tool for user advocacy regardless of what we’re designing.

But these needs don’t always manifest in the same ways for all users in a population, and it can lead to errors to assume that they do. Often, a user’s role will impact what is important for them and what solutions or tools will help them achieve their desired outcomes.

Role
The specific function that an individual or group of individuals performs within an organization, group, or population. Roles may have clearly defined, rigid boundaries, or they may be fluid with irregularities and overlaps. Understanding and defining the roles within a user population is key to understanding how users will achieve their outcomes.

As with user structures, roles can also be formal (such as those discussed in the example below) or informal, such as emergent tendencies within a social group or family or the behaviors of players in multiplayer games.

Example: Fire Services House Fire Response

As an example, we’ll look at several firefighter roles. Firefighters operate in high stakes environments, and they always need to be apprised of the current situation to keep themselves and others safe. A key need for this population is the need to see. Depending on the role, the way that “see” manifests can vary quite a bit and in important ways. We’ll look at three primary roles that operate in a typical house fire response: the incident commander, the driver, and the firefighter.

Incident Commander

Stock photo of a firefighter incident commander

The incident commander’s job is to manage the on-site personnel and to make decisions at the site of emergency. This role is typically performed by the officer (leader) of the first-arriving vehicle, and can shift over the course of the response as more personnel arrive.

Incident commanders need to see the scene locally (i.e. by looking at it), but they also have a need to see the bigger picture of the incident site: how personnel are moving through or around the burning structure, where resources are located and their status, and so on. Currently, they accomplish this by building a mental image of the scene through radio communications, ad hoc visual aids such as a whiteboard, and, depending on the budget of the department, they may have digital tools such as satellite images or visuals from drone footage.

Driver / Engineer

A Seattle Fire Department Engine

The driver (also known as the engineer, or apparatus operator) has a much more specific role to play: driving and operating the pump truck, or in some cases a ladder truck, and management of water supplies. Their need to see is much more task-focused: they need clear vision for driving, and they need to see real-time information about local water supplies to maintain resources for the fire attack.

Firefighter

Stock photo of a firefighter

Finally, the firefighter (also called the operator) performs the fire attack to extinguish the fire, completes search and rescue operations, and generally performs all of the in-the-site action. As such, they need to see local details to maintain their own safety, avoid hazards such as degraded structures and volatile materials, locate victims, and even see up-close fine details for the provision of medical care when necessary.

While each of these roles has overlap in their need for clear local vision, they each also have specific functions to perform that, if designed towards without accounting for the distinctions, could leave some or all of the roles lacking critical support necessary to achieve their outcomes.

Figure 5: Firefighters’ need to See varies significantly depending on the individual’s role.

These distinctions present a significant design challenge, as it can be difficult to account for such wide variance in a product’s feature set. Trying to make a single product for all roles could result in a compromised product that meets nobody’s needs. The opposite approach of creating individual products for every scenario may overburden the product team, budget, or users, oversaturate the domain, or introduce significant fragmentation across a product line.

Ideally, common points across roles can serve as a foundation for a product, and then additional features, versions, or options can be prioritized to meet the most important needs between roles. Though this is just one possibility, and depending on the population, there could be many more unique endpoints.

Insight 3: Collective Users Are Distinct from their Constituents

While role-based needs taught us that variance between users impacts how design meets their needs, collective users teach us about how these distributed needs come together.

Collective User
When users operate in concert towards a shared goal, they may be a collective user. A collective user has its own needs that must be met and outcomes that must be achieved that are unique from those of the individuals that comprise the collective, though individual needs and outcomes are typically aligned with these goals.

Defining a group of individuals as a collective user can highlight how user needs and outcomes can differ between individuals and the groups in which they participate. Of course, it’s likely that the individual needs and outcomes will be aligned with the collective, as individuals sum into a collective. In some cases, there may be conflicting priorities between individual users, such as when a player in a cooperative video game prefers to play an offensive role but their team would benefit from defensive help.

Other times the individual may be aligned with the collective need, but the needs of the group supersede those of the individual (a phrase you will see several times in this series). This might happen when distributing resources under constraints (budget, time, materials, etc.).

In general, we can’t assume that looking at either the individual or the collective alone will inform us how to design for both, and approaching a user population through this lens often highlights cases where solving for one is insufficient to meet the users’ needs overall.

Example: Search and Rescue Team

As an example, let’s assume that we’re interested in a team of three people in a search and rescue team. We have identified that they have two primary needs: see and communicate.

The design team has created a prototype providing them with capabilities that fully deliver on these needs, but it also requires a great deal of resources to accomplish. It’s costly, but the design meets their needs. In the graphic below, assume that each cylinder is a “unit” of capability, such that more cylinders increase the user’s ability to meet the measured need.

Figure 6a: A prototype with no constraints could maximize the users’ needs across each individual in the team.

When we bring this prototype to the users and test the design, we might learn that it’s too costly, as each person can only carry enough equipment to provide two “units” of capability (perhaps we should have learned about their constraints first). When applying this constraint, the prototype can no longer meet the users’ needs because it would overburden them.

Taking this feedback, the team then updates the design to provide everyone with one unit of “see” capability and one unit of “communicate” capability. While less impressive than the previous prototype, this model provides for both needs while satisfying the “two units per person” constraint. If this is all the team needs to succeed, this might be a case where meeting the needs of each individual also solves for the collective, and the product could move forward.

Figure 6b: A prototype with the constraint that each person can only carry two “units” of capability makes for a more limited product, but could still meet their needs.

However, let’s say we take this prototype back to the user for feedback and learn that one unit of capability is not enough to meet their needs — everyone can see and communicate, but nobody can see or communicate well enough to accomplish their goals.

Figure 6c: A prototype with the same constraint of two “units” of capability per person, but now the users’ needs are such that this is not sufficient.

In this case, providing everyone with the same capabilities would fail the team’s requirements (and in fact, this is a scenario we’ve encountered regularly in our research across several user populations).

In these cases, we would often find that the users solved this issue by specializing individuals into roles that would distribute capabilities across the team to ensure that the needs of the collective were met, even if the individuals gave up some of their own capabilities (and in this example, perhaps something we should have learned up front yet again).

In our hypothetical example, we’ll say that in this last round of feedback we learned that the search and rescue teams are organized into two different roles, a “spotter” role that searches for the missing person(s) and a “communications” role that relays information between the team and their parent organization. Using this information, the team builds a new modular system that can be distributed across roles.

Figure 6d: A prototype with the same constraint of two “units” of capability per person, and the capability is split into two roles, a spotter role where two users take on the burden of extra see capability, and a communication-focused role.

The two spotter roles take on enough see capability to adequately search for their missing person together, and just enough communications capability to reach the user filling the communications role. The communications role forgoes visual search equipment and instead carries the equipment to receive information from the spotters and relay it back to their organization.

In this particular example, the collective outcomes superseded the individuals’ needs, and the best way to design the product was to compromise features for individuals so they could work together within their constraints. This is again a point we want to emphasize: It is critical to understand the users’ situation at both the individual and the collective levels to identify how best to support them through the product’s design.

A Note on Collective vs. Majority

We want to take a moment to call out a distinction between collective users vs. a majority of users.

The point of this construct is not to create a dichotomy between a majority of users and a minority of users, such as saying “this feature is important for 80% of users, so we should focus on that instead of the 20% of users that don’t need it”. This is a road fraught with error, as the 20% users are still an important part of the population

Instead, the point we intend to make is that we must include the perspectives of both individual users and the collectives that those individuals form.

In fact, it is critical to this approach that the team ensures all voices in their users’ population are represented as best they can be, as key actions and dynamics within the population may happen at any level, by any member. Ignoring minority, underserved, or underrepresented users in favor of a majority would be a failure of this approach and a disservice to the user population.

To emphasize, the goal of this approach is to identify where in the user structures we can provide the most impact for all users, at both the collective and individual levels. To serve all users we can’t leave any of them out of our work.

Insight 4: The Critical Path Highlights What Users Need the Most

The final insight we want to discuss is all about finding that route to optimize towards the users’ most important outcomes, which we call the critical path.

Critical Path
The actions through a user journey that must be accomplished to achieve the user(s)’s ultimate outcomes. These actions may take place at the individual or collective level, and the level at which they occur may change across the journey.

The critical path is the series of actions that must occur throughout the user structure to achieve the users’ desired outcomes. One of the things that we try to keep in mind when thinking about the critical path is that it’s focused on where the users achieve their ultimate goals, and so it requires some defining on the part of the researcher or designer (ideally a definition identified through conversations with the users).

In the following example, we will work through identifying the critical path within a complex hierarchical user structure, the Seattle Fire Department’s journey when responding to a house fire incident. This example will cover the user structure of the Seattle Fire Department, the collective journey they perform when they respond to a house fire, and the flows of action through the actors across the journey. While dense, this will demonstrate the need to understand complex systems of user behaviors at both the individual and collective levels, lest a product end up supporting a firefighter without putting out the fire.

Example: Seattle Fire Department House Fire Response

Before getting into the critical path, we want to quickly show the full user structure we’ve defined for the Seattle Fire Department. This structure has multiple organizations nested across different functions, many of which have deeper layers than we’ve illustrated here.

The User Structure

Figure 7a: Seattle Fire Department User Structure

However, when looking at the house fire collective journey, we actually only need a subset of this structure.

Figure 7b: Seattle Fire Department User Structure, highlighting the personnel involved in a house fire response.

For a house fire, the fire department primarily activates two channels of its structure: First, the Operations organization houses the firefighters, specialists, and their leadership chain. Second, the Fire Alarm Center manages resource distribution and communication (often through Dispatch, a role within the organization).

One complication to note within this structure is that from the Deputy Chief level of Operations and down, the organization is split into 24-hour shifts. This is represented by the split arrows when noted. So, during a 24-hour period, there will be:

• 1 deputy chief
• 6 battalion chiefs (5 geographic regions of Seattle, 1 Medic Battalion)
• 5–7 fire stations per battalion

For the purposes of this example, we will be examining one shift on a single house fire call, which would involve the following personnel:

• 1 deputy chief
• 1 battalion chief
• 2 fire stations (1–2 Officers, 1–2 Drivers, 2–4 Firefighters)
• The Fire Alarm Center (1 Dispatcher)

Figure 7c: The parts of the Seattle Fire Department User Structure directly involved with a house fire incident

After identifying the relevant users, both individual and collective levels, we can then map their roles and tasks across the collective journey.

The Collective Journey

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

This figure looks a little dense, but we will break it up into several chunks to make it more manageable.

On the left we have our summary of the user structure, along with descriptions of how the overall critical actions and outcomes occur within it. This is useful for keeping a high-level eye on how the journey map applies to the users’ original context, which is flattened to accommodate the journey timeline.

In the case of Seattle Fire’s house fire journey, we see that the critical actions run in parallel between the information and resource management of the Fire Alarm Center and the senior-most member of the operations organization on the scene. Similarly, the critical outcomes most often occur at the highest collective level involved in the incident response, as the collective actions of those on site must pool together to resolve the fire and preserve life.

Looking across the top, we can see the main phases of this collective journey, from the initial emergency call and activation of resources by the Fire Alarm Center to the closing of the incident and review process. For each phase, we’ve listed out the actions that must occur to successfully complete the phase, as well as the outcomes that those actions will produce.

The rest of the figure details all of the users involved in the journey, from the firefighters on the ground to the deputy chief managing the on-duty shift across the city. Importantly, the collective users are also listed at each layer of the organization. When we say “Station” in this context, this is considered a unique collective user that is comprised of the firefighters and drivers within the station, as well as the officer leading them.

The Critical Path

Figure 9: The Critical Path of actions through the house fire collective journey

In this view, we can see how the critical actions flow through the various individual and collective users in the department, based on our discussions with leaders within the department.

First, the Fire Alarm Center receives an emergency call, and a dispatcher uses the call details to activate resources across the department. The dispatcher passes this information along to the active operations shift, and depending on the region of the city, the nearest 2–3 fire stations within the battalion will respond. In this phase, the individual role of “dispatcher” plays a key part in contacting the right people and disseminating the right information, while in the operations org what matters most is that the correct stations activate and begin responding as quickly as possible — this is reflected in the critical path touching on each collective user in the org as they must all filter down the resource activation together, ultimately arriving at the correct stations mobilizing.

In the mobilization phase, the department is entirely focused on ensuring that the right personnel and equipment arrive safely at the site of the incident. Another layer of communications is added here as the leadership of the stations (the station officer) communicates with Dispatch to ensure that everyone is acting in accordance with the most up-to-date information. While they are managing information, the mobilized vehicles focus on driving and navigating to the site.

This focus on communicating on-the-ground information and updating through the Fire Alarm Center to redistribute resources continues throughout the arrival and action phase, but here the critical actions in the operations personnel begin to shift into two tracks.

Figure 9b: The Arrival / Action phase of the house fire critical path

First, the driver and firefighters of the first-arriving station immediately begin to prepare to attack the fire, while the officer surveys the scene to update the Fire Alarm Center and establishes a command-and-control base of operations. The officer will manage the site from this point until the second vehicle arrives, at which point the officer from the second vehicle will take command while the first-arriving officer moves into the structure to manage the fire attack with their crew. This process of escalating authority then repeats when the battalion chief arrives and the second-arriving officer moves to an incident control role.

Finally, after the incident is resolved, dispatch will release personnel back to availability for new incidents, and the crews will return to their stations to review and document a report.

You’ll notice that there are both individual and collective critical paths occurring in parallel even within the operations personnel, with command and control following an escalating handoff as new personnel arrive, and all personnel within the battalion conducting the fire attack work to eliminate the fire and rescue any victims. Really, once the second vehicle arrives, the primary action will occur at the collective level of the Battalion, which subsumes all of the leaders and operators below, but this is a case where the command and control roles are so distinct and important to proper execution of the journey that we made the choice to highlight it separately.

If a product were designed without explicitly acknowledging these dual tracks, the users’ needs, both individual and collective, may get lost in the chaos of such a complex system.

Wrap-up

In Part 2, we discussed the insights we learned to address the gaps that we identified in our human-centered approach. By defining the users’ structure and understanding the roles, both individual and collective, they perform within it, we can ensure that we represent the complexities of these users’ intersecting journeys in our work. Then by mapping this structure to a collective user journey, we can explore how they work together to achieve their outcomes, helping us identify the places our product work can provide the most impact.

In Part 3, we will take these lessons and place them in a framework to help researchers and designers apply them in their work.

Part 1: Our Approach to Human-Centered Design, and the Gaps Therein