Design Review

Purpose: Evaluate a design against user needs and product goals before development begins

How to run this meeting

Always present the problem before the solution. Before the designer shares any screens, spend 5 minutes re-establishing the problem being solved, the target user, and the constraints the design must work within. This prevents feedback that misses the point and ensures everyone is evaluating the design against the right criteria — not just personal preference.

Structure feedback explicitly into three buckets: what's working, what's unclear, and what should change. Ask reviewers to label their comments before sharing them. This discipline prevents the meeting from collapsing into a list of complaints, helps the designer prioritize, and surfaces genuine strengths that should be preserved. Avoid "I would have done it differently" feedback unless paired with a clear rationale tied to user needs.

Separate aesthetic feedback from functional feedback. Aesthetic opinions ("I don't love that shade of blue") belong in a design critique but rarely block a feature from shipping. Functional concerns ("users won't understand that this button submits the form") must be resolved before development. Be explicit about which bucket each comment falls into. End the meeting with a clear status: approved, approved with changes, or needs another round.

Before the meeting

• Designer shares mockups or prototype in Figma at least 24 hours before the meeting
• Include a brief (written or verbal) explaining the problem, users, and constraints
• Reviewers pre-read the brief and review the designs before the meeting — no cold reads
• PM confirms which user scenarios must be covered
• Identify any accessibility or platform requirements that must be met

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 45–60 minutes

---

Context

Restate the problem, the target user, and any hard constraints before showing any designs. This is not optional — even if everyone "already knows" the context.

Problem: Workspace admins struggle to understand the current permission state of their organization. They have no single view showing which users have which roles across all projects.

Target user: Workspace admins at mid-market companies (50–500 seat workspaces), typically an IT lead or operations manager.

Constraints:

• Must work within the existing Settings navigation structure
• Must be accessible at WCAG AA
• Must not require backend changes beyond what's already scoped in the permissions API milestone

→ Figma file | Feature brief

---

Design Walkthrough

Summarize the flows and screens being reviewed. The designer walks through this live; this section captures the scope so reviewers know what's in and out of scope for this review.

Screens in scope:

1. Permissions overview page — master table of all users and their roles
2. Role filter panel — allows filtering by role, project, and last-active date
3. Bulk action bar — appears when multiple users are selected; allows bulk role change
4. Confirmation modal — shown before bulk changes are applied

Out of scope for this review: Individual user profile page, audit log view (separate initiative)

---

User Scenarios

Walk through the design against specific user scenarios. Does the design handle each one? Note gaps.

---

Feedback

Capture all feedback with the reviewer's name and bucket (What's working / What's unclear / What to change). Separate aesthetic from functional.

What's working

• The master table layout gives a quick sense of the full permission landscape — exactly what admins said they wanted in research (@sara)
• Using role badges with color coding makes it easy to scan a large list (@daniel)

What's unclear

• It's not obvious that the filter panel is collapsible — reviewers assumed it was always visible (@sara)
• The "Apply to all matching" option in the bulk bar is ambiguous — does it apply to the filtered set or all users? (@marcus)

What to change (functional)

• The confirmation modal needs to show a count and summary of affected users before the admin confirms — "You are about to change roles for 47 users" (@daniel)
• Empty state is missing for the case where filters return no results — must be added before dev handoff (@sara)

What to change (aesthetic)

• The table row hover state is hard to see in low-contrast environments — consider a slightly more prominent highlight (@design-team)

---

Decisions

Record any decisions made in the meeting so there's no ambiguity about what was agreed.

• Confirmed: Bulk action undo will not be in V1; confirmation modal is the safeguard
• Confirmed: Mobile support is out of scope for this release
• Decision: Empty states must be designed before dev handoff — @design to add by 2024-12-09
• Decision: Confirmation modal copy must include affected user count — @design to update

---

Follow-ups

Tasks that must happen before the design is ready for development handoff.

---

Action Items

Follow-up

The designer updates Figma with all required changes and posts a summary comment tagging reviewers. If changes are minor (aesthetic only), the design is considered approved once the designer confirms updates are made. If changes are functional, a second design review should be scheduled before dev handoff. The PM owns the decision on whether another review cycle is needed.