Every system exists to serve someone. Whether it is a customer-facing product, an internal tool, or an integration between other systems, identifying exactly who the users and stakeholders are is the foundation that every other decision sits on.
Software design too often starts with a vague solution, jumping straight to features or technologies. Without a clear view of Who will use the system, you risk building something misaligned with real needs or, worse, something nobody needs at all.
This post is about defining the individuals, roles, and systems that will interact with your software. Not just job titles. Behaviours, contexts, motivations, dependencies.
Types of actors
- Primary users. The people who interact with the system to achieve specific outcomes. Customers on a portal, support staff managing queues, engineers running a build tool.
- Secondary users. People who do not use the system directly but are affected by it. Auditors reviewing logs, analysts reviewing exports, compliance officers.
- System integrators. Other systems that consume or feed yours. CRMs, auth providers, reporting tools, third-party APIs.
- Stakeholders. People with a vested interest in the outcome. Product owners, regulators, department heads, the person signing the invoice.
Techniques for defining Who
Persona template
A simple layout we use on every discovery:
- Name: give them a human name
- Role: title or relationship to the system
- Goals: what they want to accomplish
- Pain points: frustrations or barriers today
- Typical tasks: the actions they repeat
- Device and environment: where and how they access it
- Quote: one line that captures their perspective
Persona example
Name: Sarah Langley. Role: Project Manager.
Goals: track team hours against budget, approve timesheets quickly, generate weekly client reports.
Pain points: slow dashboards, missing filters on the approval screen, exports she does not trust.
Typical tasks: reviews 20+ timesheets each Monday, edits task codes before billing, shares summaries with finance.
Device and environment: laptop during the day, tablet at home, often approving on her commute.
Quote: "I just need to approve timesheets quickly and know the data is correct."
Other techniques
- User mapping: list every touchpoint a user has across your workflows.
- Stakeholder interviews: ask who cares if this works, who suffers if it does not, who signs off.
- Context diagrams: draw the external systems and users that interact with your product.
Why it matters
- Relevance. Features are easier to prioritise when you know who they serve.
- Design. User needs drive decisions on mobile support, accessibility, internationalisation.
- Security. Knowing who needs access, and who should not, informs identity and role design.
- Testing. Different actors need different test scenarios. A clear Who improves acceptance criteria.
- Rework. Building for the wrong audience leads to expensive rewrites.
How context shapes behaviour
A persona on paper is static. The same user behaves very differently depending on where, when, and under what pressure they touch the system.
Consider Sarah again. On Monday mornings she reviews twenty timesheets in a calm office on a large monitor. On a Friday afternoon she is approving one last submission from a train, on a phone, on patchy 4G, while her manager chases her for a different deliverable. Same user, radically different tolerances for load time, click depth, and error recovery.
Good Who work captures this spectrum. A useful question to ask against every persona: "what does the worst five minutes of their week look like, and where does our product appear in it?" Design for that moment, not the marketing-video moment, and the rest takes care of itself.
Actors you usually forget
Every discovery surfaces the obvious users. The work is in finding the ones that are not obvious.
- Future you. The person who will be on call when the system misbehaves at 3am. They are a user of the logs, the dashboards, and the runbooks.
- The auditor. They read your system only through its exports. If the exports are ugly, you will hear about it in a room you did not want to be in.
- The integrator's integrator. Your API is consumed by a client, whose own product is consumed by another tier. Decisions like pagination and error shape ripple three layers down.
- The person who leaves. Whoever inherits a config, a script, or a cron job is a silent user. Their ability to pick it up is a usability question.
- The regulator. They do not log in, but they absolutely dictate features. Data retention windows, consent capture, right-to-erasure flows are all Who-driven requirements.
None of these actors show up if you only ask "who is the customer". They all show up if you ask "who is affected if this system is wrong, late, or offline".
Turning the Who into a living artefact
A persona document that gathers dust by sprint two has failed. A Who artefact earns its keep when it is referenced in the review of every new ticket.
- Reference personas by name in user stories. "Sarah needs..." beats "the user needs..." every time.
- Pin the actor list in the top of the product-spec document, not at the back.
- Revisit the Who at the start of every quarter. New integrations, new regulations, and new internal teams change the cast.
- When a support ticket lands, tag it to a persona. Patterns emerge quickly and the Who stops being a guess.
We have seen teams run this well with nothing more than a shared document. We have also seen teams buy expensive persona-management tools and still get it wrong, because the tool was not the problem. The discipline was.
Common pitfalls
- Assuming "everyone" is the user. When everyone is the user, no one is. Be specific.
- Skipping internal users. Admin tools, dashboards, and developer interfaces have users too.
- Forgetting integrations. Systems do not use themselves. Someone wrote the API client or scheduled the import.
- Copy-pasting last project's personas. Shortcuts here are the most expensive shortcuts in software.
- Treating "the stakeholder" as a single person. Product owners, budget holders, and decision-makers are often different humans with different priorities. Map them separately.
A worked example
Designing a timesheet app for a consulting firm:
- Primary users: consultants logging time.
- Secondary users: project managers reviewing logs.
- Integrators: a payroll system consuming approved timesheets.
- Stakeholders: HR and Finance.
From that list alone it is obvious why mobile usability matters (consultants on the move), why accuracy and locking matter (payroll), and why flexible approval flows matter (managers). Every subsequent design choice has a reason behind it.
A short anti-pattern
We once inherited a project labelled "internal dashboard for the sales team". Four months and two engineers deep, it was elegant, well-tested, and entirely unused. The reason was simple. No one had asked which part of the sales team. It turned out "the sales team" spanned six very different roles: SDRs, account executives, customer success, renewals, partnerships, and leadership. The dashboard had been designed for a hypothetical mid-funnel AE who did not exist as a daily user. SDRs needed a list. Leadership needed a summary. Renewals needed a filtered alert feed. Customer success used a different tool altogether and had never been consulted.
A single afternoon of persona work would have produced three smaller interfaces, each useful to its audience. Instead, the team produced one expensive tool useful to nobody. That is the cost of a missing Who.
Summary
The Who defines the why for the rest of your design. It is where clarity begins. Deeply understand your actors and you have the foundation for functionality, security, interface, and hosting decisions.
