Guest access
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 outsiders had been let in — Shaun, given the run of a whole space, and Mark, looped into a single thread — and the product treated them as the same kind of thing. This is how I untangled that.
Sees the whole space
Sees one thread
First, how the product works.
People work inside a space — a shared project workspace of files, attachments, and threaded conversations (the product also calls these topics).
Most people in a space are members. But two kinds of outsider can be let in — and that distinction is where everything that follows begins. Hold onto these three roles; they’re the whole story.
One flat label, two kinds of access.
The existing screen presents “guest” as a single thing. Underneath, the platform grants two very different scopes — and nothing lets the person running the space see the difference, or choose.
The screen I was handed · Kona · People panel (original)
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 without a stream of “can you send me…” requests.
In neither the space nor the org. Looped into one conversation for proposal insight — and should see only what’s relevant to that thread. Nothing more.
The interface calls them both, simply, “guest.”
The reframe wasn’t luck — it was a path.
The same method I’d run on any ambiguous brief: frame the one question that matters, reframe around the answer, write the principles I’m designing against, take the decision through every touchpoint, and confirm my assumptions rather than bury them. The rest of this deck walks it, step by step.
What actually differs between the two?
Everything downstream depended on the answer — so I settled it before opening the wireframing tool. Framed the right way, having both roles stops being confusing and becomes obviously useful: one spares the trusted collaborator constant requests, the other keeps sensitive detail out of the wrong hands.
The whole space — all files, attachments and conversations. Self-serves what they need for their work.
One conversation— and only what’s relevant to it. Keeps irrelevant, sometimes sensitive, detail out of reach.
The constraints are the design.
In an access-control problem the constraints are the design, so I wrote down the principles I was designing against before I drew anything.
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.
Promote the hidden variable: make access scope the thing you set.
Rather than making the typeof 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 at the moment the account is created, changeable forever after. I took it through the flow at three points: invite, edit, and the roster.
Set it up front. Change it forever. Audit it on one screen.
I took the decision through every touchpoint — invite, edit, roster, label — and rebuilt each in Deltek’s MUI standard. Below, each screen is shown twice: the original Kona wireframe (Then) beside the Material rebuild (Now).
Decide the scope up front.
Name, email, and a User Access level — chosen the moment the account is created, never left to chance, no silent defaults. Documents Only is the tightest of the three, for an outside reviewer who needs the files but not the conversation around them.
Access is a dial, not a trap.
The same three-way control that grants scope also takes it back — you can dial someone from This Topic Only up to Full Access, or back down, at any time. The model never locks a person at their first level.
Who can see what — on one screen.
A table of user, email, user type, and access — each row carrying its own access control, and for topic-scoped guests, which topics they can reach. Color carries the scope so it reads before you do. This is the at-a-glance answer to who can see what — and where an administrator audits and revokes.
Scope, readable at a glance.
A Topic Guest in orange, a plain Guest in green — tried at a few densities (with an avatar, name-only, and compact), mirroring the original wireframe. Color-coding a guest’s scope right next to their name is the cheapest possible way to keep the whole team’s expectations aligned.
What I chose — and what I’d revisit.
Each was a deliberate call, not an oversight — and each comes with the test that would change my mind.
A third access level
The callAdded Documents Only beyond full-space and single-topic — for an outside reviewer who needs the files but not the conversation around them.
What I’d revisitConfirm the third level earns its complexity with real admin usage before it ships — otherwise collapse back to two.
One label, not two role names
The callEveryone is a Guest; scope is the property you set. Fewer concepts on screen, and the distinction stays explicit.
What I’d revisitTest whether admins lose a useful shorthand — a subtle scope descriptor on the chip may still earn its place.
Scope set at invitation
The callForces an explicit access decision up front — no silent defaults, no one quietly over-scoped.
What I’d revisitI 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 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. I’d rather make my assumptions visible and correctable than quietly bake them in and hope.
A coherent access model — where every piece traces to a principle I set before I started.
“Guest,” with scope as a setting
Full · This Topic · Documents
Audit & revoke who sees what
Color-coded, read at a glance
When two hidden categories fight under one label, the fix isn’t a better label — it’s promoting the underlying variable into something a person can set and change.
A craft-and-reasoning case study — the named people in the mockups are illustrative sample data, and there are no measured metrics to quote.