How to Use Comments and Annotations in SnapState

Write useful comments

A useful comment is specific. Instead of 'broken,' write 'Expected the Save button to enable after selecting a role, but it remains disabled.' That tells the recipient what to inspect.

Place the comment near the relevant UI area so the viewer can connect text and state immediately.

• Describe expected behavior and actual behavior.
• Mention the teammate or team responsible for the next step.
• Resolve comments when the issue is addressed.

Use annotations for visual ambiguity

Annotations are useful when multiple elements look similar or the issue is visual. Highlight the row, field, modal, or button that needs attention.

Do not over-annotate. If a snapshot contains too many comments, split the work into separate snapshots or summarize the priority.

Keep discussion attached

When someone asks a question in Slack, move the answer back to the snapshot if it affects the decision. That keeps future readers from reconstructing the thread.

This habit is what makes SnapState more than a capture tool.

Why this workflow is stateful

The common pattern across product, QA, support, design, and engineering is that the visible UI is only one part of the problem. The state behind it can include route, role, account data, filters, feature flags, viewport, recent requests, and comments from the person who found it.

That is why screenshots often create more messages. They preserve the appearance but lose the surrounding conditions that make the state actionable.

How to test this with your team

Pick one recurring workflow where screenshots routinely lead to questions. For one week, ask reporters to capture a SnapState when the state is visible and to add one sentence describing expected behavior.

At the end of the week, review whether the recipient had enough context to act. Look at clarification replies, repeated screenshots, unnecessary meetings, and whether the final decision stayed attached to the captured state.