Expanding Beyond the Single-User Persona

For years, design teams have relied on user personas to understand the people behind the interface. These personas helped us define motivations, needs, frustrations, and the everyday realities people face. However, the environment we design for has fundamentally changed.

Most people do not work in isolation. Their decisions are shaped by teams, shared tools, organizational pressures, and increasingly, automated systems.

When persona work focuses only on the individual, we risk designing for a situation that rarely exists in real life.

It is time to broaden our lens and include the groups people work within, the organizations that shape their behavior, and the agents or agent systems that now participate in their workflows.

Just as important, we need to understand these relationships if we want to design responsibly and effectively.

Single-user persona ≠ reality

In enterprise environments, work today is deeply intertwined.

A person’s experience is often shaped just as much by the people around them as by their own preferences or behaviors.

A nurse makes decisions based on a physician’s orders, but also on staffing limits, safety protocols, and what the shift supervisor expects during high-pressure moments. A support agent at a tech company balances customer needs with internal ticket routing rules and the service level agreements their team is measured against. A delivery driver navigates customer expectations while also dealing with dispatchers, route optimization tools, and weather alerts from automated systems.

When we build personas around an isolated individual, we miss the broader dynamics that influence decisions, communication, and outcomes.

Consider how work actually gets done.

Someone might rely on coworkers for approvals, information, or quality checks. They may coordinate across shifts or departments. They may adapt their own behavior based on team norms or shared expectations. These dynamics change the experience significantly, yet they are rarely captured in traditional personas.

Designing for just one person means designing for a simplified (and often misleading) world.

When we center the real ecosystem around the work, our understanding becomes richer and far more accurate.

Treating the group as a persona

Most work involves collaboration. Some collaborations are formal, like a clinician and a care coordinator working together around a patient’s plan. Others are informal, like a coworker who helps someone troubleshoot a tricky workflow.

In both cases, decisions and behaviors are shaped by the people around them.

A team develops unofficial rules, patterns of communication, shared values, and shared pain points. These qualities shape how work flows through the system just as much as the traits of any one person.

When we treat the group as a persona, we begin to capture how real collaboration happens. A team may be cautious, fast-moving, reactive, or chronically overloaded. It may rely on a few experts or organize work in a way that distributes responsibility unevenly.

These traits influence how a product is adopted, how a workflow is interpreted, and how roles shift over time.

Modeling a group in this way helps us understand the environment a product must live in. It becomes possible to design not only for individuals but for the shared experience of a team that is trying to accomplish work together.

This is not a replacement for individual personas, but a complementary layer that reflects how work is truly coordinated.

Treating the organization as a persona

Organizations behave like actors.

They have goals, pressures, values, fears, processes, and incentives that shape what people can realistically do.

These characteristics shape how people inside the organization behave.

They also shape what is possible within any product experience.

An organizational persona helps teams understand the larger system that a product will live inside. This might include the policies that determine what users can or cannot do, the cultural norms that influence adoption, or the metrics that matter most to leadership.

By modeling the organization, designers and researchers can anticipate resistance, build solutions that fit regulatory or safety boundaries, and design for how change actually spreads in the real world.

Ignoring the organization often produces solutions that test well, demo beautifully, and quietly fail in implementation.

People cannot use a product that does not align with the system around them.

Treating agent or agent systems as personas

Agents, whether simple or advanced, also play a role in modern workflows.

These agents can schedule tasks, flag anomalies, route requests, curate and summarize content across data sets, or provide recommendations.

They influence decisions, even if they are not conscious actors.

An agent persona helps a team understand what the agent is trying to achieve, how it behaves under uncertainty, what patterns it follows, and how it interacts with both individuals and groups. Defining an agent persona makes it easier to design consistent behaviors across the product, to avoid surprises for users, and to set clear expectations about what the agent will and will not do.

This persona format is not limited to AI.

Any automated workflow or rule-based system benefits from being modeled as an actor with goals, constraints, and predictable behavior.

Designing for all relationships

The real power of expanding persona work appears when we map the relationships between individuals, groups, organizations, and agents.

These relationships determine how information flows, how decisions are made, and where friction appears.

A user is influenced by their team. Their team is influenced by the organization. Both the user and the organization interact with agents. The agents respond to signals from all of them. These interactions shape the actual experience far more than any individual persona on its own.

Designing for these relationships helps teams create more resilient, predictable, and human-centered experiences.

Hospital orchestration as a real-world example

In a hospital, a patient’s journey is shaped by many people who depend on one another.

A charge nurse assigns patients to rooms and oversees the flow of care across a shift. A transport coordinator schedules staff who move patients to imaging or surgery. A bedside nurse depends on timely transport so that medication schedules and care plans stay intact.

Their collaboration is constant and often under pressure.

If transport falls behind by ten minutes, that delay ripples outward. A bedside nurse may now struggle to complete documentation, the charge nurse may need to rebalance workload, and the patient may feel the system is disorganized.

This is a clear example of human collaboration, where multiple roles affect one another’s outcomes.

At the organizational level, the hospital’s operations and staffing policies influence how this work unfolds.

In one hospital scenario, the organization may prioritize throughput, meaning the goal is to keep beds turning over efficiently.

In another hospital, the focus may be on minimizing patient wait times in the emergency department.

These priorities shape staffing levels, scheduling rules, escalation protocols, and even which departments receive more resources. When these organizational pressures shift, the behaviors of everyone in the hospital shift with them. This is organizational collaboration, where the organization itself has goals and constraints that directly shape the environment in which people work.

Agents also play a role in orchestration.

A bed management agent may track which rooms are clean or occupied. A transport dispatch agent may automatically assign tasks based on proximity or load balancing. A monitoring agent may alert when a patient needs urgent attention.

These agents are not simply passive tools. They influence the pace and timing of human work. If the transport agent assigns tasks out of order, nurses may experience unpredictable delays. If the monitoring agent generates too many false positives, clinicians may lose trust in it.

This is agent collaboration, where software or automated logic acts as another participant in the workflow.

Together, these layers shape the overall experience. The nurse’s work does not make sense without the transport staff. Their work does not make sense without the organizational policies that govern staffing and throughput. And none of their work makes sense without understanding the automated systems that drive assignments, alerts, or scheduling.

Designing only for the individual misses the interdependence that defines hospital life.

Putting it into practice

Design, research, and product teams can adopt this expanded approach immediately.

The first step is to stop thinking about users as individuals operating alone. Start by mapping the groups they interact with, both formal and informal. Then model the behaviors of the organization around them.

Finally, identify the automated systems, rules, or agents that shape timing, prioritization, or decisions.

Once these personas are defined, bring them into your research plans, your design reviews, and your strategy documents. Treat them as core artifacts, not side notes. When exploring new features, evaluate how each persona type is affected and how the relationships between them shift. In cross-functional meetings, use these personas to create shared understanding across product, engineering, operations, and leadership.

Most importantly, begin building experience maps that show the interactions between humans, groups, organizations, and agents.

This is where real insight emerges.

Teams that adopt this practice will create products that match real-world complexity and support users in environments that actually exist.