A review of dialog / modal should explain the transition to “Reviewed”, rather than treating the label as self-explanatory. A screenshot shows a component at one moment. It does not explain its states, accessibility requirements or limits. Document behaviour beside appearance. Link a component to its tokens and record a rationale when the pattern changes.
Review the next move
Kinetic Kit explores design-system documentation that connects tokens, components and the decisions behind their use.
Example: Dialog / modal
The illustrative record contains keyboard flow. Its state is reviewed. Ask what evidence supports that state, which detail is still uncertain and whether the next person could understand it without reading a separate message thread.
Questions for a working review
- Compare the proposed next step with the original objective. For dialog / modal, use “Keyboard flow” as the starting context.
- Review the assumption that would change the outcome. For dialog / modal, use “Keyboard flow” as the starting context.
- Leave a dated explanation for the next person. For dialog / modal, use “Keyboard flow” as the starting context.
A small exercise
Take one recent design system management example from your own process. Write its context without using a status label, then add the label separately. If the two contradict each other, investigate the source before updating the record. Compare the result with “Button / primary” in the demonstration to see which distinctions your process needs.
These are planning notes. The specimen is illustrative, and the preview does not process live work.
More resources →