I'm not obsessed with personas. I swear.

And yet, here I am again: thinking, writing, and problem-solving about them. I've written before about the complexity of crafting personas that reflect reality without becoming caricatures, and about how accessibility must be part of that equation. So maybe it's no surprise that I'm once again wrestling with the strengths and limits of personas, thanks to a recent experience and an unexpected spark of inspiration.

A Familiar Problem

We recently created a new set of user personas at my company. The timing was right, the business value was clear, and the use cases were already taking shape. We didn't need to reinvent the process from scratch. We had past experience, existing research, and internal alignment. In strict methodological terms, these were proto-personas: we built them from previous data and internal insights, not net-new generative research. But they are solid personas, and they meet the needs we originally scoped them for.

However, almost immediately, the same old problem returned. We started hearing familiar questions: "Do we have a persona for this user?" "What about that one?" "Our users are different, so shouldn't we have another?" I understood the impulse. I've written before that personas are complicated. Real humans rarely fit neatly into fictional archetypes. But the pressure to create additional personas grew quickly. We already had more than enough, and adding more risked turning a clean system into an unusable mess.

At the same time, ignoring these emerging use cases doesn't feel right either. When our process includes a healthy prompt like "What persona is this feature for?", how do we support features that don't align with any existing persona in a clear and specific way?

That's when a passing idea in an NN/g article stopped me in my tracks.

It pointed out that a surgical tool's success depends not just on the surgeon, but on nurses, technicians, and support staff as well.

That thought captured exactly what I had been struggling to articulate.

Beyond the Primary User

When we design a tool, it is easy to focus on the primary user: the surgeon, the analyst, the client-facing specialist. But that tool does not exist in a vacuum. Someone from compliance may need to review its outputs. A member of the finance team might interact with part of the workflow to issue invoices. The identity and access management team might need to configure permissions.

None of these individuals are the core user, but all of them are involved. Each brings a different set of goals, responsibilities, and interaction patterns. Their role within the system is real, even if it is not front and center. Sometimes, you can squeeze these users into a broader persona, but doing so flattens nuance and removes important distinctions. Their needs, motivations, and access are not interchangeable.

Trying to give each of these individuals their own dedicated persona would result in a set that is not just overly large but deeply impractical. Creating and maintaining that many fictional identities is not scalable, and using them to inform product decisions would become harder, not easier.

Still, dismissing these secondary and tertiary users outright leaves gaps. Those gaps are often where critical edge cases, operational inefficiencies, or overlooked risks reside.

Enter: Ecosystem Thinking

The concept of user ecosystems is not new, but it resonated differently with me this time. The NN/g article, drawing on the work of anthropologists Mike Youngblood and Ben Chesluk, suggested that we stop treating users as isolated actors. Instead, we should view them as people embedded in broader systems. These ecosystems include tools, policies, relationships, and other human beings.

This made sense to me. At my company, we already use terms like product ecosystem and business ecosystem. Extending that logic to user ecosystems felt not only appropriate but overdue. Rather than focusing only on a central user, this approach invites us to consider the broader network. These include the people who indirectly influence, depend on, or interact with a tool's output.

This does not mean we need to discard personas. They still serve a purpose, especially when tied to real research and aligned with business goals. But we might benefit from thinking of personas less as containers for every edge case and more as anchors for exploring broader systems.

My personas are already, in many ways, archetypes in disguise. (I'll admit it's easier to get adoption for "personas" than "archetypes," and I consider that a mostly harmless white lie.) But ecosystem thinking gives me a new language to try out.

In practice, this might look like diagramming the relationships and dependencies around a given persona. It might involve explicitly mapping the roles that support, constrain, or react to that persona's workflow. It might involve creating lightweight role profiles for people who operate at the margins of a system but still play important parts.

Toward Something New

I do not have a complete solution yet. I am not jumping to replace our current approach, and I am not throwing away the persona catalog we already use. But I'm seeing the gaps more clearly now. And I am starting to believe that filling those gaps requires us to expand our thinking, not just about personas, but about the systems in which those personas operate.

This might mean layering role-mapping onto existing personas. It might mean clustering related roles into ecosystems and using those to define shared constraints or tensions. It might mean designing tools that support ecosystem-level accountability, not just persona-level feature alignment.

I don't know yet. But I'm excited to explore it.

And if you are starting to feel overwhelmed by the sheer number of personas in your system, or if you keep hearing, "but what about this user?", it might be time to step back. Instead of adding another persona, consider whether you are missing the bigger ecosystem.