Who this is for: Product teams writing a precise visual brief for a software update.
What to prepare
- Approved old and new capability for the role.
- Correct-role screenshots and object scope.
- Required configuration and effective availability.
Copyable creative brief
An authored planning example. Replace illustrative details with your approved product facts and assets.
Create a 30-second planning sequence for a fictional review tool where Reviewers can now resolve their own comments on assigned submissions. Open by naming the role and assigned-submission scope. Show one illustrative comment authored by that reviewer. Label the previous capability accurately, then cut to the new version and show the verified Resolve action on that same comment. Hold on the resulting resolved state. Keep the author's identity visible so “own comments” is understandable. Do not show approval controls from an administrator account or imply permission to resolve other people's comments. State any required activation step and who can perform it, using only approved facts. End with the narrow capability summary and a clear unchanged boundary. Use text labels as well as visual emphasis so the permission difference is not conveyed by color alone.
Make it your own
- Role and scope
- Specify whose capability changes and on which objects.
- Capability difference
- Name one old-to-new action difference.
- Activation owner
- Supply the authorized role if setup is required.
Capture the correct role
Use an account with the intended permissions. Cropping an administrator screenshot can conceal other differences that matter to the task. Keep a record of the role used for every source capture.
Adapt when access is being removed
State the affected action and the verified alternative or escalation route without celebratory framing. Do not imply that a user can restore access themselves unless the policy allows it. The action owner becomes the central closing information.
Repair scope drift
If the draft says “Reviewers can resolve comments,” restore “their own” where that condition applies. Check the final example for authorship and assignment. A broad headline should not contradict the narrowly correct demonstration.
Review checklist
- Role and object scope appear before the action.
- The example uses the correct account permissions.
- Ownership conditions stay attached to the capability.
- The next action belongs to an authorized role.