Review teammate invitations and role choices

A task kit for design, usability and accessibility review. Read and adapt it without an account.

Use an approved staging site and synthetic data. A human or an agent can use this brief; an AI attempt supplies evidence to inspect and hypotheses to investigate. It does not stand in for research with people.

A task brief to adapt

Replace the starting URL, synthetic values and permitted actions with your own approved boundaries. Keep the outcome; leave the click sequence open.

Starting state: Signed in as a staging workspace administrator on the dashboard. The supplied disposable teammate is not listed. The workspace has documented roles and permission descriptions.

Goal: Invite the supplied disposable teammate with access to edit projects, without access to billing or team administration.

Observable success: The teammate appears once as Pending with the role that permits project editing and excludes billing and team administration. The administrator can identify the recipient and access before confirming.

Conditions: Run on desktop and at 390px mobile width, then keyboard-only and 200% zoom. Use fresh invitation fixtures per run. A person checks the role chooser and status with their screen reader. Record the role policy version.

Permitted actions: Use only the staging workspace and an explicitly approved disposable recipient/domain. Send one disposable invitation only when sending is authorized; otherwise stop before submission and mark the result unchecked. Do not invite real colleagues, elevate to administrator, cancel or revoke invitations.

7 checks to make

1. Find the invitation from the dashboard. Give the goal without naming the team screen. Record unclear labels and wrong turns, then check that the route can also be reached by keyboard.
2. Understand what each role allows. Compare visible role descriptions with the documented policy. Check whether project editing, billing and team administration are explained before a choice is committed.
3. Operate the role chooser. Check focus, keyboard selection, accessible names and whether the current role is conveyed in text. Do not infer screen-reader support from a screenshot.
4. Check the recipient before sending. Inspect the confirmation context. A narrow screen should show the full address and chosen access without relying on a truncated tooltip.
5. Correct an invalid address. Use a malformed synthetic address. Check the error names the correction, is associated with the field and preserves the chosen role.
6. Recognize pending versus accepted. After an authorized send, inspect and reload the team list. Check it names Pending, the recipient and role; a transient Sent message does not prove acceptance.
7. Handle an existing invitation. Use a separate seeded Pending case. Check the interface explains the existing record instead of suggesting an unexplained second send.

Worked illustrative evidence

Fictional example. These records were written to explain the review. They are not captured screens, customer results or a run of Variantly.

For a real review, retain the starting state, build, condition, action and outcome beside each screen. Include the accessible names, focus trace and rule output where available; mark missing evidence as unchecked. A person's screen-reader check is separate evidence.

A product change to consider

Proposed change: Describe permissions beside each role and repeat the full recipient and selected role near the send action. Keep Pending and Accepted visibly distinct.

The administrator's decision is about access, so the UI should answer that decision at the point of choice. A stable pending row helps distinguish a sent invitation from a teammate who has joined. Descriptions must follow the actual permission policy.

A person decides

The role owner verifies the permission descriptions. A reviewer decides the hidden confirmation detail with evidence open; keep the comprehension hypothesis Not sure yet until people attempt the access choice. Any role-model change needs its own security and product review.

What to recheck

Repeat with a fresh authorized disposable recipient and the same role policy. Confirm keyboard operation, full mobile confirmation and one Pending row with the intended role after reload. Acceptance and actual permissions require a separate authorized teammate session.

A recheck records whether the condition was seen again, not seen, not checked or couldn't tell. A person decides whether the issue is resolved.

What this task leaves open

A visible role and pending row do not prove email delivery, acceptance or server-side authorization. This kit does not authorize those checks or real invitations. Use the existing invitation walkthrough for a complete example of a review record.

Keep task-review findings separate from accessibility report rows. These kits make no claim of human fidelity, conversion uplift or conformance certification.

Go deeper

• Read the existing invitation walkthrough
• Describe the intended access in a task
• Name, Role, Value

Choose another task kit or ask for review of a task on your product. The request starts a conversation about coverage; it does not start an automated run.