When everyone edits at once.

Imagine Leena and Omar editing a shared project brief. Leena changes a heading while Omar moves a section. Each person expects an immediate response and assumes their work will survive. If the interface waits for every network roundtrip, editing feels slow. If it confirms everything instantly without distinguishing local and shared state, it can promise more than the system knows.

Seeing another person’s cursor can help coordination, but it does not tell you whether your last change reached the server. Separate presence, local editing, shared state and persistence in your requirements. Ask what the person needs to know in each state. A designer may tolerate a brief delay in another cursor while being very sensitive to uncertainty about whether a major edit has been preserved.

Move through the three states below. Leena first sees her local edit. The connection then disappears, so the interface must not claim that shared state is current. Reconciliation eventually gives both clients a resolved result. This teaching model does not implement a CRDT or Figma’s conflict rules. Its purpose is to make the product promise explicit before you choose the technical mechanism.

Optimistic interaction makes work feel responsive, but error and recovery states become essential. Write the rules for two edits to different fields and two edits to the same field. Consider undo: does it reverse only your action, or can it unexpectedly remove a collaborator’s later work? A PM need not invent a synchronisation algorithm, but must describe the outcomes people expect and review the edge cases with engineering.

For a prototype review, disconnect one client, edit the same field in two windows, reconnect, and attempt undo. Inspect the visible state and the saved result. Include slow connections and refreshes. Track lost-work reports separately from ordinary latency. A system can feel fast in a demo while leaving users uncertain in the exact situations where trust matters most.

Your fictional editor can show a generic “saved” label, an explicit local-only state, or block every edit. Choose based on what the system can actually preserve and reconcile. Explain the cost of a misleading success message and the cost of unnecessary interruption. The right choice connects the technical guarantee with a clear user expectation.

Create a matrix for connected, slow, offline, reconnecting and conflicted states. For each, specify permitted actions, visible feedback, persistence guarantees and recovery. Add a same-field conflict example and an undo example. Review the matrix with an engineer before designing decorative presence indicators.