Structured Problem Solving and Decomposition Questions

Overview / Title

• Record ID, Title (e.g., "ADR-2026-04: Onboarding Flow — Optional Social Sign-up"), Date, Authors, Stakeholders

Context / Problem

• Short user & business context, metrics we care about, constraints (time, technical, legal)

Decision

• Clear, actionable choice with scope, e.g.:
  • Decision: "We will implement progressive disclosure for social sign-up as optional on step 2 of onboarding."
  • Rationale: key research findings, trade-offs, expected impact on conversion and complexity

Assumptions (explicit)

• Example language: "Assume 20% of new users prefer social sign-up based on usability tests" / "Assume engineering can support OAuth by Q3"
• Mark each assumption with confidence level (High / Medium / Low) and source (research, analytics, stakeholder claim)

Alternatives Considered

• Short list of options rejected and why (metrics, effort, risk)

Consequences & Implementation Notes

• Impact on existing flows, design system tokens, accessibility, analytics events to add, tracking plan

Validation Plan / Success Criteria

• Metrics, A/B plan, qualitative tests, timelines

Review & Post-mortem Use

• How to use later: schedule review at launch + 6–12 weeks; collect metrics vs assumptions; mark each assumption as validated/invalidated with evidence; record lessons and next steps
• Example post-mortem line: "Assumption 3 invalidated — social sign-ups were 8% vs assumed 20% → action: iterate CTA copy and retest."

How I’d use it as a Product Designer: keep ADR linked in tickets, reference during design reviews, and lead the post-launch review to update the ADR and inform roadmap decisions.

Approach — goals and cadence
I treat the design-system roadmap as a living product with three simultaneous pillars: stability (bug fixes), extension (new components/patterns), and adoption (documentation, onboarding, migrations). I plan quarterly objectives aligned to product OKRs, with monthly checkpoints and a weekly triage for urgent fixes.

Prioritization & trade-offs
I score requests by impact (user/developer value, accessibility, revenue/efficiency) × confidence × effort. Trade-offs:

• High-impact, low-effort fixes get fast lanes.
• Large new components are split into MVP + iterations to reduce risk.
• Adoption work (docs, migrations) is prioritized when component usage < target or onboarding friction is high.

Who I consult

• Engineering (owners, front-end, infra) for feasibility and effort
• Product Managers for business alignment and OKRs
• Developer advocates / SDK owners for integration pain
• QA & Accessibility for risk assessment
• Design Ops and component consumers (other designers/devs) for needs and adoption blockers
• Support/CS for recurring issues signals

Process & governance

• Roadmap board with lanes: Hotfix, Backlog, Planned, In Progress, Adoption
• SLAs for critical bugs; sprints for component work; “office hours” and migration clinics for adoption help
• Ship small, measure, iterate; include migration guides and codemods when possible

Metrics indicating health

• Component adoption % (pages / apps using the system)
• New component time-to-production (velocity)
• Bug backlog and average time-to-fix
• Developer satisfaction (surveys/CSAT) and design-system NPS
• Accessibility compliance score and visual-consistency coverage
• Number of one-off UI implementations (debt indicator)

Example: if adoption % stalls but backlog is low, I shift capacity toward docs, migration tooling, and developer outreach rather than new components.

Situation summary (one line)
After a release I discovered a design decision caused negative UX for a specific user segment (power users using keyboard shortcuts): unexpected modal focus stole keyboard input, breaking workflows.

Who to notify internally (first 24 hours)

• Immediate: PM, Eng lead on release, QA lead, Design Manager, Customer Support lead.
• Within 4 hours: Incident channel in Slack + shared doc with impact, repro steps, screenshots/gifs, affected user percentage and key metrics.
• If external-facing: Legal and Communications for messaging review.

How to surface externally

• If high-impact or revenue/SLAs affected: public status page incident and targeted in-app notification to impacted users.
• If low-impact: proactive outreach via Customer Success to affected customers + knowledge-base article explaining temporary workaround and ETA for fix.

Immediate remediation (hours)

• Ship quick rollback or feature-flag fix that restores expected focus behavior.
• Temporary mitigation: add banner in-app for affected users with workaround (Esc to close modal; toggle setting), and equip Support with step-by-step scripts.
• Validate fix with quick A/B test and a small beta cohort before broad rollout.

Long-term prevention (weeks → quarters)

• Add keyboard/assistive-tech scenarios to design acceptance criteria and QA test plans.
• Create a UX checklist for releases (accessibility, edge workflows, degraded states).
• Add automated E2E tests simulating keyboard-only flows and include in CI.
• Run post-mortem with root-cause, action items, owners, and deadlines; publish summary to org.
• Incorporate findings into design system patterns (modal focus behavior standardized) and hold a design-eng workshop to align on patterns.

Metrics & follow-up

• Track support tickets, task completion rate for affected flows, and NPS for the cohort. Close loop when metrics return to baseline and communicate resolution to stakeholders and impacted users.

Problem space vs Solution space — definition (Product Designer view)
The problem space is the set of user needs, constraints, motivations, business objectives, and the environment that define why a product or feature is needed. It’s where you do user research, synthesis (personas, jobs-to-be-done, journey maps), and define success metrics. The solution space is the set of possible designs, interactions, and implementations that address the clarified problem—wireframes, flows, components, and engineering approaches. Good design moves from deep problem understanding to targeted solutions; skipping steps risks mismatch.

Example — cost of jumping to solutions too soon
On a recent project our team assumed users wanted a “one-click checkout” and immediately designed a compact UI and backend shortcut. We later learned through interviews that users’ main pain was confusing shipping options and trust around returns—not checkout friction. The prematurely built shortcut increased conversion for a small segment but amplified support tickets and returns because the underlying trust issues remained unresolved. If we had stayed in the problem space longer, we would have designed clearer shipping choices, return policies, and microcopy that solved the real problem.

Problem statement (1–2 sentences)

• Owner: Product Designer (with PM sign-off)
• When: Before backlog grooming, once user research or analytics points to a clear issue
• How used: Frames the sprint goal; shared at planning kickoff to align scope and acceptance criteria. Example: “New users drop off at account creation due to confusing password requirements — reduce drop-off by 20%.” Use to prioritize stories and define success metrics.

Journey map snippet (key steps + pain points)

• Owner: Product Designer (collaborative with UX researcher)
• When: After a quick research synthesis or analytics review, 1–2 days before planning
• How used: Visualizes where the problem occurs so engineers and PMs can estimate impact and dependencies. Include screenshots, timeline, and severity annotations to target stories.

Hypothesis card (If/Then/Because + metric)

• Owner: Product Designer or PM (co-owned)
• When: Created during pre-planning ideation or immediately before sprint planning
• How used: Drives experiments and defines acceptance tests. Example: “If we simplify password requirements, then account completion will increase by 20% because users won’t be blocked.” Use to choose MVP scope and define what to measure in the sprint.