Studio culture & creative process / DIJION
A useful brief for asynchronous design reviews
A review template adding tasks, open questions and decision boundaries to screenshots so comments become actionable feedback.
Sharing a screenshot and asking What do you think often produces comments about unrelated questions. One person discusses color, another business rules and another an unfinished screen. For an illustrative filter flow, the brief should explain the task and uncertainty being reviewed. Working asynchronously does not remove the need for shared context.
Build the brief around a decision
Describe the intended user, starting state, expected outcome and decision under review. Distinguish finished elements from placeholders. Make the question more concrete than Are filters easy: can someone identify active filters and understand what clearing them changes? The reviewer should not need to reconstruct the entire project history to contribute.
Share more than the successful screen
Scroll the table horizontally to see all columns.
| Material | Context needed | Useful feedback |
|---|---|---|
| Task flow | Start and finish | Missing or unnecessary steps |
| States | Empty, error and loading | Behavioral consistency |
| Narrow screen | Long text and keyboard | Access to the task |
Separate observations from suggestions
Describe what is unclear in a particular task instead of labeling a button bad. Add a proposed solution after the observation rather than presenting it as the only possible response. Brand preference, usability barriers and implementation questions are different kinds of feedback. Keeping them distinct makes the reasoning behind a design response visible.
Give the review a closing point
Specify a response window and decision owner. After processing comments, identify accepted changes, deferred points and questions needing evidence. Silence is not automatic approval; an essential review that never arrived remains outstanding. Keep comments connected to the revised screen so each round does not repeat an already resolved discussion.
Review the brief before sharing
- Can someone outside the project understand the task and question?
- Are error, empty and narrow-screen examples included?
- Are the decision owner and response window clear?
- Does the outcome note explain why suggestions were not adopted?
This is a working template, not a report of a Dijion review session. A useful brief aims to gather answers to the right question rather than maximize the number of comments.