Who this is for: Product teams preparing accurate software update communication.
What to prepare
- Approved old and new role-capability definitions.
- Relevant object, workspace and account boundaries.
- Verified administrator actions and timing.
Build a role-impact matrix
Use a row for each affected role and a column for each consequential capability. Viewing, editing, inviting and approving are different permissions; do not combine them under “access.” Include the object scope, because editing one assigned item is not the same as editing the workspace.
Add required action and owner columns. A member may experience a change while only an administrator can configure it. The video should not direct the member to controls they cannot use.
- Role and the exact capability.
- Previous permission and new permission.
- Scope: own items, assigned items or a specified workspace.
- Required action and authorized owner.
- Effective status and verified exceptions.
Worked example: a bounded reviewer change
In this fictional review tool, Reviewers previously viewed assigned submissions and left comments. The illustrative update lets them mark their own comments resolved. It does not let them approve submissions or resolve other reviewers' comments.
The matrix should therefore show viewing assigned submissions as unchanged, adding comments as unchanged, resolving own comments as newly allowed, and approving submissions as still unavailable. A generic green “more access” badge would conceal the important boundaries.
- Reviewer: resolve own comment, newly permitted, no administrator setup in this illustrative record.
- Reviewer: resolve another person's comment, unavailable.
- Approver: approve a submission, unchanged under the supplied record.
- Unassigned member: access the submission, not established by this update.
Script one role at a time
Open with “For reviewers working on assigned submissions.” Show one illustrative comment authored by that reviewer, then the verified resolve control and resulting state. Keep authorship visible so the viewer understands why this comment qualifies.
If administrators must enable a setting, create a distinct administrative step or companion explanation. Do not splice an administrator's screen into a member demonstration without labeling the role switch. That can make the product appear to grant a capability it does not.
Review for implied access beyond the matrix
Check each scene for controls outside the intended scope. A screenshot from an administrator account may expose actions unavailable to the audience. Crop only if the remaining view is still accurate and understandable; otherwise capture the correct role.
Ask the product owner to read the script against the matrix. The review question is not whether the story feels simple, but whether an affected user can identify what changed, what did not and who must act.
Review checklist
- The affected role is named before the demonstration.
- View, edit and approval capabilities remain separate.
- Object and workspace scope are visible where relevant.
- The captured account has the intended role.
- Required configuration is assigned to an authorized owner.