Two screens beat one permission

How the one-screen version decays

It starts clean. One page, a couple of conditional blocks, a flag deciding whether the filters appear.

Then the administrative side grows. Bulk filters, exports, a review queue, a device mapping. Each addition is another condition on a page that a normal employee also loads.

Eventually the two audiences are fighting over one layout. The employee sees a page designed around controls they cannot use, and the administrator works around a layout designed for a single person's record.

And every new feature means asking which half it belongs to, on a page where the answer is a flag rather than a file.

What separate routes give you

Each screen can be designed for one job. The personal attendance view answers: was I on time, how many hours, what is outstanding. The administrative view answers: who was late, which department, export this range.

Permissions get simpler to reason about, because the boundary is a page rather than a set of conditions inside one.

And documentation becomes possible. The in-product guide can point at a screen, not at a screen-plus-a-role.

• Attendance: your record, and the administration of everyone's.
• Leave requests: yours, and the approval queue.
• Daily recap: your own logging, and the team timesheet grid.
• Policies: reading them, and authoring them.
• Support: raising a ticket, and working the inbox.

The cost, which is real

Two screens is more code than one, and two places to keep a change consistent.

It also means more navigation. The product carries several nav groups, separating personal work from administration, and a new administrator has more to learn than in a single-screen product.

Whether that trade is right depends on how different the two audiences are. For attendance, where one side owns a single record and the other owns a review queue, they are very different.

What this does not replace

Separate routes are an interface decision, not a security control. Access is governed by roles, with permissions grouped into domains such as attendance, leave, timesheets, projects and device sync.

There is also a baseline the product describes as things everyone can do and which cannot be removed: mark your own attendance, request leave, log your own recent time, edit your own profile, see the directory.

Two screens make the boundary legible. Access rules are also enforced in the database, as well as on the screen.

The test for whether a screen should split

Not every module needs two addresses, and splitting everything would produce a product nobody can navigate.

The test we use is about the unit of work. If one audience works with a single record and the other works with a queue of them, those are different jobs and they want different screens.

Your own attendance is one record. Administering attendance is a queue, a set of filters and an export. Split.

A directory is the same object for everyone: a list you search. No split, whatever your role.

Applied consistently, that test also tells you where a new feature belongs, which is the decision a single conditional screen makes hardest.

What it does to the rest of the product

The split shows up in places you would not predict, and mostly for the better.

Navigation becomes honest. Groups separate personal work from administration, so a new person can see the shape of their own job without reading past everyone else's.

Documentation gets simpler. The in-product guide points at a screen and describes it, rather than describing a screen that changes depending on who is reading.

And the permission conversation gets shorter. Granting someone administrative attendance access is one decision about one screen, which is much easier to review a year later than a set of flags scattered through a page.

What it looks like from the employee side

The argument so far has been about maintenance, which is the vendor's problem rather than yours. There is a user-facing half too.

An employee in a single-screen product learns to ignore most of what they see. Controls that do nothing for them, filters they cannot use, counts belonging to somebody else's job.

That has a cost beyond untidiness. A person who has learned to skim a screen misses the thing that was actually theirs.

A personal view containing only their own record is small enough to read properly. Today's state, hours so far, anything outstanding. Four things, none of which belong to anyone else.

Most people only ever meet that half of an HR system. Designing it as its own screen, rather than as the leftovers of an administrative one, is the difference between a tool people use and one they are made to use.