Deltek: one label was hiding two kinds of access

Most access-control problems don't look like problems. They look like a screen that's working fine. This one did too — until you sat with it.

The product is Kona, Deltek's project-collaboration platform. People work inside a shared space of files, attachments, and threaded conversations. Most people in a space are members, but two kinds of outsider can be let in, and that distinction is the whole story: a space guest is in the space but outside the organization; a conversation guest is in neither, invited into a single thread.

A People panel — Assignees at the top, a separate Guests list at the bottom. It looks fine. But "guest" is one flat label, while the system actually grants two completely different levels of access. Shaun, a space guest, can see every file and every conversation. Mark should only ever see the one thread he was invited into. Nothing in the UI tells you which is which — and that's how sensitive proposal detail ends up in front of someone who was meant to answer one question.

In an access-control problem that's literally true, so I wrote the principles down before I drew anything. Access must be revocable — whatever you grant, you can take back. A user can belong to many spaces and conversations at once, so the model can't assume one guest equals one place. And it must be obvious which kind of user someone is — if a viewer has to think, the design failed.

The pivotal decision: rather than making the type of person the primary concept, I collapsed "space guest" and "conversation guest" into a single designation — Guest — and made what they can access the thing you set and change. Scope stops being two rigid categories and becomes a property: explicit, editable, set by the administrator when the account is created, changeable forever after.

Adding someone: the admin enters a name, an email, and a User Access level — Full Access, This Topic Only, or Documents Only — chosen at invitation, never defaulted silently. Documents Only is the tightest, for an outside reviewer who needs the files but not the conversation around them.

Editing someone later: the same three-way control honors the revocable principle — you can dial a person up to Full Access or back down, at any time. Access is a dial, not a trap.

The roster is a table of user, email, user type, and access — each row carrying its own control, with color carrying the scope. It's the one screen where an admin audits and revokes. And the label itself: a Topic Guest tag in orange versus a plain Guest tag in green — color-coding a guest's scope right next to their name is the cheapest way to keep everyone's expectations aligned.

It was getting clarity before I started. The brief was thin on the things I'd normally know: platform constraints, technical limits, the real data model behind spaces and conversations. The unknowns weren't a reason to stall — they were something to surface. So I wrote my assumptions down, handed them back to the team as part of the work, and confirmed the requirements in writing before committing. The named people in the mockups are illustrative sample data; there are no measured metrics to quote.

The lesson I carry: when two hidden categories fight under one label, the fix usually isn't a better label — it's promoting the underlying variable into something a person can set and change.

See the full case study → https://design-case-studies.vercel.app/deltek