Product Design

Instructions

Product Thinking

• Problem Framing: Begin every project with a clear problem statement. Use “How Might We” statements to reframe constraints as opportunities. Apply Jobs-to-Be-Done to articulate what users are hiring the product to do, not just what features they request.
• Double Diamond Process: Follow Discover (diverge on research) → Define (converge on problem) → Develop (diverge on solutions) → Deliver (converge on execution). Never skip Define — jumping from research to solutions produces feature soup.
• Design KPIs: Tie every design decision to a measurable business outcome. Pair qualitative goals (user satisfaction, task confidence) with quantitative metrics (task completion rate, time-on-task, error rate, conversion).
• Desirability / Feasibility / Viability: Evaluate every concept against all three lenses. A desirable feature that cannot be built or sustained is a liability. Document which lens drove each major trade-off.

Information Architecture

• Site Maps: Structure navigation to match user mental models, not org charts. Validate with card sorting (open sort for discovery, closed sort for validation) and tree testing (can users find the thing without UI chrome?).
• Progressive Disclosure: Reveal complexity on demand. Surface the 20% of actions that cover 80% of use cases; nest the rest behind clear affordances.
• Wayfinding: At every point in the product, users must know three things — where they are, where they came from, and where they can go next. Use breadcrumbs, active navigation states, and contextual back links.

User Flow Design

• Happy Path + Exception Paths: Design exception flows (errors, edge cases, permissions failures) with equal rigor to the happy path. If you haven’t designed the error state, you haven’t designed the feature.
• Decision Points: At every fork, document what data drives the branch, what the user sees, and what happens on each path. Use flow diagrams for any branching logic with more than two outcomes.
• State Coverage: Every screen or component in a flow must account for five states — zero state (first use / empty), loading state, populated state, error state, and empty state (data existed but was removed). Skipping any state ships a broken experience.

Design Critique Facilitation

• Session Structure: Open with the problem being solved and the specific feedback needed. Separate aesthetic taste (“I don’t like blue”) from principle-grounded critique (“low contrast fails accessibility”). Time-box discussion per topic.
• Decision Logging: Document every significant design decision with reasoning: “We chose X over Y because [user research finding / technical constraint / business goal].” Store decisions alongside the design file, not in Slack threads.

Best Practices

• Start with a written problem statement before opening any design tool
• Design error and edge cases before polishing the happy path
• Present designs in context — device frames, realistic content, actual data volumes
• Version designs with clear naming (v1.0, v1.1, v2.0-draft) and date stamps
• Make decisions in public — shared Figma comments, recorded critique sessions, written decision logs
• Prototype at the lowest fidelity that answers the current question
• Never present a single option — show the trade-off space with 2-3 alternatives and a recommendation