Deltek
Two kinds of “guest” hiding under one label — and how I gave the platform a way to tell them apart.
In Kona, Deltek’s project-collaboration platform, people work inside a shared space of files and threaded conversations. Two kinds of outsider can be let in — and the interface called them both, simply, “guest,” while the platform quietly granted them opposite access.
One flat label, two kinds of access.
The existing screen presented “guest” as a single thing. Underneath, the platform granted two very different scopes — and nothing let the person running the space see the difference, or choose it.
Same label. Opposite blast radius.
In the space, outside the org. Trusted to work across it — so he can self-serve every file and conversation. Access → the entire space.
In neither the space nor the org. Looped into one thread for proposal insight, and should see only what’s relevant to it. Access → one conversation.
The interface called them both, simply, “guest.”
The reframe wasn’t luck — it was a path.
The one thing to settle before opening the wireframing tool: what actually differs between the two? Both need scoped access — provided the platform makes the scope explicit and controllable. The space guest gets the whole space and self-serves; the conversation guest gets one conversation, keeping irrelevant, sometimes sensitive, detail out of reach.
The constraints are the design.
Revocable
Whatever you grant, you can take back — at any time.
Many at once
A user can belong to multiple spaces and conversations. One guest ≠ one place.
Obvious
It’s clear which kind of user someone is. If a viewer has to think, the design failed.
Make access scope the thing you set.
Instead of a “Guests” list hiding a distinction, access becomes an explicit, editable property — set at invitation, changeable forever after. I took it through the flow at three points: invite, edit, and the roster.
Two rigid types
“Space guest” and “Conversation guest” — two fixed roles, with the real distinction (what each could actually see) buried underneath the same word.
One designation, a scope you set
Everyone is a Guest; access becomes a setting you choose and change — Full Access · This Topic Only · Documents Only.
Set it up front. Change it forever. Audit it on one screen.
Adding someone — scope at invitation
Name, email, and a User Access level chosen the moment the account is created — never left to chance, no silent defaults.
Changing someone later — revocable
Access is a dial, not a trap. The same control that grants scope takes it back; the model never locks a person at their first level.
Seeing everyone at once — audit & revoke
Each row carries its own access control, and color carries the scope so it reads before you do — the place an admin audits and revokes.
Every row carries its own scope chip and access control — the audit surface the third principle describes, shown in one place.
Scope, readable at a glance.
Color carries the meaning before the words do: a Topic Guest in orange, a plain Guest in green — on a person row and as a standalone tag.
Each was a deliberate call — with the test that would change my mind.
Added “Documents Only” for an outside reviewer who needs the files but not the conversation. I’d revisit: confirm it earns its complexity with real admin usage — or collapse back to two.
Everyone is a Guest; scope is the property. Fewer concepts on screen. I’d revisit: test whether admins lose a useful shorthand — a subtle scope descriptor on the chip may still earn its place.
Forces an explicit access decision up front — no silent defaults, no one quietly over-scoped. I’d revisit: I optimized the single-invite path; a sensible default and bulk-invite editing need their own pass.
The strongest move wasn’t a wireframe. It was getting clarity before I started.
The unknowns weren’t a reason to stall — they were something to surface. I wrote down the platform and data-model assumptions I was designing under, handed them back to the team as part of the work — correctable, not hidden — and confirmed the requirements in writing before committing a single screen.
When two hidden categories fight under one label, the fix isn’t a better label — it’s promoting the underlying variable into something you can set and change.
A coherent access model where every piece traces to a principle set before I started: one designation with scope as a setting, three tiers (Full · This Topic · Documents), a roster to audit and revoke, and color-coded labels you read at a glance.
A craft-and-reasoning case study — the named people in the mockups are illustrative sample data, and there are no measured metrics to quote.