6Ws: Who – The Actors and Users of the System

Chapter 1: Who – The Actors and Users of the System

Why "Who" Matters

Every system exists to serve someone. Whether it's a public-facing product, an internal tool, or an integration service between systems, identifying exactly who the users and stakeholders are is the foundation upon which all other decisions rest.

Too often, software design begins with a vague idea of a solution, jumping straight into features or technologies. But without a crystal-clear understanding of "Who" will interact with the system, we risk creating solutions that are misaligned with user needs, or worse, not needed at all.

This chapter focuses on defining and understanding the individuals, roles, or systems that will interact with your software. This is not just about naming job titles; it is about articulating behaviours, contexts, motivations, and dependencies.

Types of Actors

1. Primary Users

   • These are the main users who interact with the system to achieve specific outcomes.

   • Examples: Customers using an online portal, support staff managing queries, engineers using a build tool.

2. Secondary Users

   • These individuals may not use the system directly but are impacted by it.

   • Examples: Auditors reviewing logs, data analysts reviewing exports, compliance officers.

3. System Integrators / Interfaces

   • Other systems that interact with your application via APIs, events, or data synchronisation.

   • Examples: CRM systems, authentication providers, external reporting tools.

4. Stakeholders

   • People who have a vested interest in the outcome of the project.

   • Examples: Product owners, regulatory bodies, department heads.

Techniques to Define "Who"

Persona Creation Template

Use this structured layout to define each persona relevant to your system:

Persona Name: (Give them a human name)
Role: (Their title or relationship to the system)
Goals: (What they are trying to accomplish using the system)
Pain Points: (Frustrations or barriers they currently face)
Typical Tasks: (Common actions this persona performs)
Device & Environment: (Where and how they typically access the system)
Quote: (A short statement that summarises their perspective)

---

Persona Example

Name: Sarah Langley
Role: Project Manager
Goals:

• Track team hours against budget

• Approve timesheets quickly

• Generate weekly reports for clients

Pain Points:

• Hates slow-loading dashboards

• Frustrated by lack of filtering on approval screens

• Doesn’t trust current export accuracy

Typical Tasks:

• Reviews and approves 20+ timesheets each Monday

• Edits task codes before billing

• Shares timesheet summaries with finance

Device & Environment:

• Uses a laptop during the day and her tablet at home

• Often approves timesheets while commuting

Quote: “I just need to approve timesheets quickly, and know that the data is correct.”

---

• Persona Creation

  • Build fictional representations of your users with names, goals, pain points, and usage patterns.

• User Mapping

  • List out every touchpoint a user has with the system across various workflows.

• Stakeholder Interviews

  • Ask: Who cares if this works? Who suffers if it doesn’t? Who signs off?

• System Diagrams

  • Use context diagrams to show external systems and users interacting with your product.

Why It Matters in the Planning Process

• Drives Relevance

  • Features become easier to prioritise when you understand who they serve and what they need.

• Guides Design Decisions

  • User needs can determine whether your interface should be accessible on mobile, optimised for screen readers, or multi-lingual.

• Supports Security Planning

  • Understanding who needs access, and who shouldn’t, informs identity, authentication, and role design.

• Enables Better Testing

  • Different actors require different test scenarios. A clear "Who" section improves acceptance criteria and user acceptance testing.

• Reduces Rework

  • Building with the wrong audience in mind leads to costly rewrites. Getting the "Who" right helps avoid this.

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 are users too.

• Forgetting integrations

  • Systems don’t use themselves. Someone built the API client or scheduled the data import.

Bringing It to Life: An Example

Let’s say we’re designing a timesheet application for a consulting firm.

• Primary Users: Consultants logging time.

• Secondary Users: Project managers reviewing logs.

• Integrators: A payroll system that consumes timesheet data.

• Stakeholders: HR and Finance departments.

When we know this, it becomes clear why:

• Mobile usability matters (consultants on the move)

• Accuracy and locking mechanisms are required (payroll)

• Reports and approval flows must be flexible (project managers)

Summary

The "Who" defines the why for the rest of your design. It is where clarity begins. By deeply understanding your actors, you set the foundation for functionality, security, interface, and even hosting strategy decisions. Every great system starts with the people it serves.