The four users you didn't know you had.

Strategy · 5 min read

I designed an app with two user types. A manager and a worker. The manager creates tasks and monitors compliance from a dashboard. The worker completes tasks on their phone. Simple. Clean. Two experiences, two interfaces, two sets of permissions. That was the design.

Then we sat down with the developer. And within the first ten minutes, the developer asked a question that changed the whole scope. "So the person buying the subscription is the same person adding the workers, right?" And the answer was no. Not always. The company owner buys the subscription. But there might be four people at that company who need to add workers and assign tasks. And then there's the app owner themselves, who needs a view across all the companies using the platform.

Two users just became four. And we hadn't designed for half of them.

Roles hide inside roles

This happens more often than you'd think. During design, you're focused on the primary experience. The main user types. The core flows. And that's correct. You should be. But when development starts and the developer has to actually build the authentication system, the permission layers, and the database relationships, that's when the hidden roles emerge.

In our case, the hidden users were the company admin, who needed to invite multiple managers to the platform, and the platform owner, who needed an admin panel showing subscription data, user counts, and activity across all accounts. Neither of those existed in the design. The company admin was assumed to be the same as the manager. The platform owner wasn't accounted for at all because during design, we were focused on the product experience, not the business operations layer.

The developer spotted it because developers think in systems. They think about who creates what, who has access to what, and who can change what. Designers think about what the user sees and does. Both perspectives are essential and this is exactly why the handoff conversation matters so much.

Each user type costs money

Here's the part that affects your budget. Every user type needs its own authentication flow, its own permission set, its own views, and potentially its own interface. The company admin needs a way to invite managers. The platform owner needs a dashboard that no other user type can see. The invitation flow needs email logic, temporary passwords, and onboarding. None of that was in the original scope because none of those users were in the original design.

This is one of the most common reasons development quotes come back higher than expected. It's not that the developer is padding the price. It's that the design showed two user types and the build requires four. That's twice as many authentication flows, twice as many permission checks, and a whole admin panel that didn't exist in the prototype.

Ask the question before the developer does

If you're building a B2B app or any platform where multiple people within an organisation will use it, map out every person who will touch the system. Not just the primary users. Think about who signs up. Who pays. Who invites others. Who manages settings. Who sees the data. Who owns the account if someone leaves the company. Those are all user types. And if you don't design for them, your developer will discover them during the build, and that discovery will cost time and money.

The earlier you identify these roles, the better. During design is ideal. During the developer handoff is fine. During development is expensive. After launch is a nightmare.

Sources
Personas and Scope (Nielsen Norman Group) - How user personas should inform the scope of a product and the roles within it.
Authentication Testing (OWASP) - Security considerations for multi-role authentication systems.

Related blog posts:

Your app is actually three apps →

One app, three users: permission layers →

Why your quote came back double →