Designing Collaborative Features: Presence, Comments, and Permissions
On a document-editing tool we built for a client, our first version of presence — the little avatars showing who else is viewing a document — updated with a noticeable lag, sometimes several seconds behind actual activity. Users would start editing a section someone else had just left, assume they had it to themselves, and end up in conflicting edits. Presence that isn't near-instant is worse than no presence at all, because it creates false confidence.
Comments needed a clear resolved-versus-open state that was visually unmissable, not just a status field buried in a dropdown. We redesigned the comment thread to visually grey out and collapse resolved threads by default, keeping only open threads visually prominent in the margin. Before that change, resolved comments cluttered the same visual space as open ones, and reviewers frequently re-raised issues that had already been addressed because they didn't register a comment as closed.
Permissions design is where we've seen the most client pushback, because the instinct is always to expose every possible permission combination in the UI. We pushed toward role-based presets — viewer, commenter, editor, admin — with a single 'custom' escape hatch for the rare case that needs granular control, rather than a matrix of 15 checkboxes shown to every user by default. Most users never touched custom permissions once presets covered their actual use cases.
We also had to design for permission changes happening mid-session, which is easy to overlook in mockups where every user has stable access for the length of a design review. If someone's access gets downgraded from editor to viewer while they have unsaved changes open, the interface needs to communicate that clearly and preserve their draft rather than silently discarding it — we added an explicit banner and a local draft save specifically to handle that edge case after it caused a real support incident.
