Product Design Review

Purpose: Align product and design on direction, validate proposals against user research, and document rationale

How to run this meeting

Present user research before designs — always. When designers show mockups first, feedback collapses into aesthetic preferences ("I like this color," "this button feels big"). When research comes first, the room is oriented around user problems, and design feedback becomes sharper and more useful ("does this solve what the user described?"). This sequencing is the single highest-leverage change you can make to how design reviews run.

Separate two distinct questions and answer them in order: "Is this the right problem to solve?" and "Is this the right solution to that problem?" Conflating them is the most common failure mode in design reviews. You can have a beautifully executed solution to the wrong problem, or a rough prototype of exactly the right idea. Establish which question you're answering before feedback begins. If the problem definition is still in dispute, resolve that before evaluating any designs.

Document design rationale, not just design decisions. "We went with option B" is not useful institutional memory. "We went with option B because option A required too many steps for first-time users, and our research showed that the onboarding drop-off is concentrated in the first session" is. Good rationale documentation prevents designs from being relitigated every time someone new joins the team or revisits the feature.

Before the meeting

• Designer shares mockups or prototypes at least 24 hours in advance
• User research findings (if any) are summarized and linked — not just a Figma file, but the insight
• PM has written a clear problem statement: who is affected, what they're trying to do, and what's preventing them
• Reviewers have looked at the pre-read before the meeting so discussion time isn't spent on orientation
• If this is a second review, a summary of previous feedback and how it was addressed is included

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60 minutes (add 30 min for complex features)

---

Product Goals

What are we trying to achieve, and for whom? This section is the anchor for all design feedback. If a proposed design doesn't serve these goals, that's the feedback — not personal taste.

Feature: Notification Preferences

User problem: Power users on large teams feel overwhelmed by Stoa notifications. They're either turning off all notifications (and missing important updates) or staying in noisy-notification mode and ignoring everything. Neither behavior serves them or their team.

Target user: Team leads and senior ICs on teams of 10+ who are in 5+ meetings per week on Stoa.

Success criteria:

• Reduction in "too many notifications" CS tickets (current: 34/month)
• No increase in missed-action-item rate among users who adjust settings
• Feature adoption: 40% of eligible users configure at least one preference within 30 days of launch

---

Design Proposals

Summary of what's being reviewed. Link to Figma or prototype. Describe what's new or changed since the last review.

Option A: Per-channel controls Users can independently toggle email, Slack, and in-app notifications for each notification type (meeting reminders, action item assignments, mentions, summaries). Settings live in a dedicated Notifications tab in user preferences.

[Link to Figma: figma.com/file/abc123 — screens 1–14]

Option B: Frequency presets with overrides Three preset modes (Focused, Balanced, All) with the ability to override individual notification types. Designed to minimize the cognitive load of configuring 12+ individual toggles.

[Link to Figma: figma.com/file/abc123 — screens 15–22]

---

User Research Insights

What did we learn from users that is directly relevant to this design decision? Be specific — cite session counts, quotes, and behavioral data.

Usability study — 6 participants, March 4-6

• 5 of 6 participants were confused by "notification type" terminology — they think in terms of events ("when a meeting ends") not types ("summary notification")
• 4 of 6 participants wanted to silence notifications after hours — a time-based control is not included in either current option
• Quote (participant 4, senior PM at a logistics company): "I don't want to think about 12 toggles. I want to say 'I only care about things assigned directly to me' and be done with it."
• Behavioral data from in-app analytics: 78% of users who open notification settings close without making changes — suggesting the current settings page is already too complex

Implication for design: The research suggests Option B (presets) better matches user mental models, but the preset labels and the addition of a quiet-hours control may be necessary for it to succeed.

---

Feedback

Structured feedback on the proposals. Distinguish between problem-level feedback (wrong question) and solution-level feedback (wrong answer).

From PM (@marcus):

• Option B aligns better with the research insight about cognitive load
• The "Focused / Balanced / All" labels don't reflect how users described their preferences — they used phrases like "only things assigned to me" or "anything about my meetings"
• Missing: quiet hours. Research surfaced this clearly; we should include it in v1 scope, not defer to v2

From Engineering (@darius):

• Option A has a simpler backend model — each toggle maps to a stored boolean
• Option B presets require a mapping layer that needs to be maintained as new notification types are added — not a blocker, but adds complexity
• Time-based (quiet hours) control has timezone implications — needs product spec before design can finalize

From Design (@yuki):

• Proposing a hybrid: Option B as the primary surface (preset modes) with an "advanced" expansion for per-type overrides — this satisfies power users without overwhelming the default experience
• Will explore revised preset labels based on PM feedback before next review

---

Decisions

What was resolved? What was deferred? What rationale should future designers and PMs be able to read?

• Decided: Move forward with Option B as the primary pattern (preset modes), not Option A. Rationale: User research shows Option A's 12-toggle model fails usability — 78% of users abandon current settings without changes, and participants consistently preferred preset-based controls.
• Decided: Include quiet hours in v1 scope. The research signal was strong enough that deferring it would likely undermine adoption.
• Decided: @yuki will explore revised preset labels and a hybrid "advanced" mode before next review. PM and engineering will provide written feedback async.
• Deferred: Exact timezone handling for quiet hours — @darius and @marcus to align offline and bring a proposal to next review.

---

Action Items

Follow-up

The designer shares updated Figma files and a revision summary (what changed and why) before the next review. Design rationale decisions are documented in the feature's product spec so they're available to anyone who works on the feature in the future. If the next review resolves the open items, the feature moves to engineering handoff.