One app, four people: design mobile around roles

Take an illustrative field-service company with one mobile app. The technician opens it to find today's jobs. The dispatcher opens it to move a job when a van breaks down. The branch manager opens it to see what is late. The customer opens it to see when someone is arriving. Four people, four jobs, and in most first releases, one home screen trying to serve them all.

It rarely works. The technician scrolls past manager reports to reach the job list. The manager sees a list of tasks that are not theirs. The customer sees a menu with words they have never used. Nobody complains loudly, they just use the app less.

Start with people, not screens

Nielsen Norman Group describes a persona as a fictional but realistic description of a typical or target user, and says it helps teams resist the temptation to design for everyone. That is the point. A persona is a decision tool. When two features compete for the home screen, you ask which persona is holding the phone.

For each role, write four lines on one page:

• What is this person doing when they pick up the phone?
• Where are they: a van, a desk, a loading bay, their sofa?
• What do they need to know in the first few seconds?
• What would make them stop using the app?

Use real people to answer, not guesses. An afternoon riding along with a technician and an hour listening to a dispatcher will correct half of what the team assumed.

Roles decide the structure

Once the roles are clear, three design choices follow.

The first screen. Each role gets a start point built for its job: the technician sees today's route, the dispatcher sees the unassigned and the late, the manager sees exceptions, the customer sees one thing, the arrival window.

The navigation. Four to five items, named in the role's own words. A technician says "jobs", not "work orders". A customer says "my visit", not "service requests".

The permissions. What each role can change should be small and obvious. The technician owns the checklist and the readings. The dispatcher owns the schedule. If everyone can edit everything, someone will.

One codebase, several experiences

None of this means four apps to maintain. It usually means one shared core (login, data, notifications, the offline store from why field apps should work with no signal) with a different front door per role. Staff roles can live in one app, with the customer in a separate, lighter one so that a customer never installs something full of internal tools. That split is a decision worth making early, because it is expensive to reverse after launch.

Limit the number of roles

NN/g's guidance on personalization warns against creating more roles than you can support, and against tagging a user as the wrong type. Start with the roles who hold the phone most often. Add a fifth only when you can name the content it needs.

A good first exercise

Take your current app, or your plan for one, and put the four roles in a row. For each, write the first thing they should see. If two roles want the same first screen, you probably have one role, and that is useful to know. If you want help running it, here is how we approach mobile apps.