Andrews DeanEvery role opens your app with a different question in mind. Does your home screen answer theirs, or just show them everyone's?
Three people, three lives
In the leave tool I built, three very different people log in.
An employee wants to book time off and check their balance. That's basically the whole job.
A manager wants to know who's off next week, whether the team is about to be dangerously thin on the same three days, and how to log leave for someone who's out sick and not typing anything themselves.
An admin doesn't care about any one person's Tuesday. They care about the whole org. Policy, entitlements, who's over their limit, where coverage is thin.
Role-by-hiding is a quiet insult
The lazy build hands all three the same page and just hides the parts you can't touch. It technically works. It also makes a manager scroll past a wall of dead controls that quietly say this wasn't built for you.
Picture a house where every guest is shown into the same room, with tape over the furniture they're not allowed to use. Nobody feels at home. That's role-by-hiding.
So each role got a genuinely different front door. A different answer to one question: what does this person open the app to find out?
The employee opens to their balance. The manager opens to team coverage and who needs attention. The admin opens to the health of the whole system.
The admin's screen carries a different kind of weight than the other two: policy and entitlement math across every employment type in the business, plus the monthly reporting that finance and HR both depend on. Burying that under a page tuned for someone else's job would have been its own quiet failure, just a slower one to notice.
Empathy, made concrete
Let me say it as plainly as I can: role design isn't a permissions table. It's empathy, made concrete, one landing page at a time.
So think about your own product for a second. Every role is asking something different the moment they log in. Whose question does your home screen actually answer?