Software & SaaS
Explaining a real-time synced whiteboard
A feature explainer for synced whiteboards works best when it shows exactly what changes for each person and when. This guide gives a three-decision structure with one worked example that any collaboration product could adapt.
01
Step one: define what syncs
Start by listing precisely which elements update live: cursors, shapes, text edits, comments, zoom position or the whole viewport. Readers lose trust when an explainer says everything syncs and then a hidden setting does not. Separate shared state, such as objects on the canvas, from personal state, such as a private zoom level. Worked example: a retrospective board syncs sticky notes, votes and the timer for everyone, while each participant keeps their own scroll position unless the facilitator pulls the group to one area with a follow-me button.
02
Step two: show the timing and conflicts
Explain what a user sees when two people act at once. Describe the visible delay in plain terms, how simultaneous edits to one note are resolved, and what happens when someone loses connection. A good explainer uses a short before-and-after sequence, not abstract talk of latency. In the retrospective example, two teammates edit the same note: the later change merges as a visible second line, a small marker shows who touched it, and a reconnecting user receives a brief catch-up of missed changes. State any limits honestly, such as maximum participants tested.
03
Step three: set roles and the next action
Finish by describing who controls the board and what a reader should try first. Cover roles like facilitator, editor and viewer, plus locking, history and export, because these decide whether a team can trust the tool in a real meeting. Then give one small first task. In the example, the facilitator invites five people, locks the template frame, runs a ten-minute note round and exports the grouped results as an image. Ending on an action turns the feature description into something a reader can test the same day.