product-design

Files (9)

• SKILL.md
• accessibility-design-checklist.md · references/
• design-audit-workflow.md · references/
• form-ux-patterns.md · references/
• micro-interaction-patterns.md · references/
• mvp-scoping-rice.md · references/
• onboarding-ux-patterns.md · references/
• user-story-template.md · references/
• wireframe-checklist.md · references/

SKILL.md (first lines)

# Product Design

> Phase 1: DESIGN | Sprint 5

Guides product scoping, design methodology, and design system foundations for webapp launches.

## Coverage

- MVP scoping (MoSCoW, RICE scoring with calibration examples)
- User story format with acceptance criteria (Given/When/Then)
- Roadmap template (MVP → V1.1 → V2 with explicit out-of-scope)
- Pricing model design (tiers, trials, feature gates, Van Westendorp survey)
- Information architecture and user flow mapping
- Wireframe methodology (low-fi → mid-fi → high-fi pipeline)
- State inventory (empty, loading, populated, error, offline per screen)
- Design system foundation (color tokens, typography scale, spacing system, component inventory)
- Design handoff checklist
- Responsive strategy (breakpoints, mobile-first, touch targets ≥44px)
- WCAG 2.2 AA checklist at design stage (50 items)
- Form UX patterns (multi-step vs single-page, validation timing, error display, autosave)
- Onboarding UX patterns (checklists, tooltip tours, progressive disclosure, activation metrics)
- Micro-interaction patterns (button states, toasts, skeletons, optimistic UI, transitions)

---

## Checklist Items

### MVP Scope Definition

<!-- beginner -->
**Define your MVP scope** — MVP stands for "Minimum Viable Product" — the smallest version of your app that delivers real value to real users. The goal is to launch fast, learn from users, then improve. Start by listing every feature you can think of, then ruthlessly cut using MoSCoW: **Must-have** (launch blockers — the app is broken without these), **Should-have** (add within 2-4 weeks after launch), **Could-have** (nice but not important), **Won't-have** (explicitly out of scope). Your MVP should have 3-5 must-haves maximum. If you have more, you are building too much. Use RICE scoring (Reach x Impact x Confidence / Effort) to break ties between features that seem equally important.
> Time: ~2-3 hours
> Reference: See `references/mvp-scoping-rice.md`

<!-- intermediate -->
**MVP scope (MoSCoW + RICE)** — Must/Should/Could/Won't categorization with RICE scoring for prioritization within tiers. Calibrate RICE using the examples in the reference doc. Target 3-5 must-haves for MVP. Define explicit out-of-scope list. Document scope cut decisions with rationale to prevent revisiting them later. Set up scope change process (any new must-have requires removing one).
> ~2-3 hours | `references/mvp-scoping-rice.md`

<!-- senior -->
**MVP scope** — MoSCoW + RICE scored. Max 3-5 must-haves. Explicit out-of-scope log. Scope change requires trade-off (add one = cut one). RICE calibrated against reference examples.
> `references/mvp-scoping-rice.md`

---

### User Stories & Acceptance Criteria

<!-- beginner -->
**Write user stories for every feature** — User stories describe features from the user's perspective: "As a [role], I want [action] so that [benefit]." This format forces you to think about WHY users need a feature, not just WHAT it does. Each story needs acceptance criteria written in Given/When/Then format: "Given I am logged in, When I click the dashboard, Then I see my recent activity." These criteria are your definition of "done" — if all acceptance criteria pass, the story is complete. Size stories as XS (< 1 hour), S (half day), M (1-2 days), L (3-5 days), or XL (break it down further).
> Time: ~1-2 hours for an epic with 5-8 stories
> Reference: See `references/user-story-template.md`

<!-- intermediate -->
**User stories with acceptance criteria** — "As a [role], I want [action] so that [benefit]" with Given/When/Then acceptance criteria. Size using XS/S/M/L/XL (anything XL needs splitting). Group into epics. Include edge cases in acceptance criteria (empty state, error handling, permissions). Watch for anti-patterns: stories too large, missing benefit clause, tech-only stories without user value.
> ~1-2 hours per epic | `references/user-story-template.md`

<!-- senior -->
**User stories** — Role/Want/Benefit format, Given/When/Then acceptance criteria, XS-XL sizing (split XL), edge cases in AC, grouped by epic. Avoid tech-only stories without user value.
> `references/user-story-template.md`

---

### Product Roadmap

<!-- beginner -->
**Create a product roadmap** — A roadmap is a timeline for what you will build and when. Organize it into three releases: **MVP** (what you launch with — your must-haves), **V1.1** (first update 2-4 weeks after launch — your should-haves and quick wins from user feedback), and **V2** (major update 2-3 months later — could-haves and features informed by real usage data). Critically, also write an "Out of Scope" section listing features you are deliberately NOT building. This prevents scope creep and keeps your team focused. Share the roadmap with stakeholders so everyone agrees on what is and is not included.
> Time: ~1-2 hours
> Reference: See `references/mvp-scoping-rice.md` (roadmap template section)

<!-- intermediate -->
**Product roadmap** — Three-horizon plan: MVP (must-haves, 4-8 weeks), V1.1 (should-haves + feedback-driven, 2-4 weeks post-launch), V2 (data-informed features, 2-3 months post-launch). Explicit out-of-scope section with rationale. Review cadence: weekly during build, bi-weekly post-launch. Update based on user feedback, analytics, and business metrics — not stakeholder opinions alone.
> ~1-2 hours | `references/mvp-scoping-rice.md`

<!-- senior -->
**Roadmap** — MVP / V1.1 / V2 horizons. Explicit out-of-scope. Weekly review during build. Data-informed re-prioritization post-launch.
> `references/mvp-scoping-rice.md`

---

### Pricing Model Design

<!-- beginner -->
**Design your pricing model** — If you are charging money, you need to decide: (1) **Tiers** — Free, Pro, Enterprise is the most common SaaS pattern. Define exactly what each tier gets. (2) **Trials** — 14-day free trials convert better than 7-day but worse than 30-day. Pick 14 to start. (3) **Feature gates** — Which features are behind the paywall? Gate the features that provide the most value to power users, not basic functionality. (4) **Pricing research** — The Van Westendorp survey asks 4 price questions to find the acceptable range. Run it with 20-30 potential users. Start with pricing you feel is "uncomfortably high" — you can always discount but rarely raise prices.
> Time: ~3-4 hours (including research)
> Tip: If you are pre-revenue, skip this until you have at least 10 users asking about pricing.

<!-- intermediate -->
**Pricing model** — Tier structure (Free/Pro/Enterprise or usage-based), trial length (14d standard, consider freemium for PLG), feature gating strategy (gate value, not basics). Van Westendorp survey (4 price questions, n≥20) to find acceptable price range. Consider annual discount (15-20% off monthly), seat-based vs usage-based, overage handling. Document pricing in a decision log with rationale. Plan for grandfathering existing users on price changes.
> ~3-4 hours

<!-- senior -->
**Pricing** — Tier structure, trial/freemium decision, feature gates (value not basics), Van Westendorp (n≥20), annual discount, grandfathering plan. Document rationale for pricing tribunal reviews.

---

### Information Architecture & User Flows

<!-- beginner -->
**Map your information architecture and user flows** — Information architecture (IA) is how you organize content and navigation in your app. Think of it as a tree: top-level pages branch into sub-pages and features. Start by listing every page/screen your app needs, then organize them into a hierarchy that makes sense to users (not developers). User flows are step-by-step paths through your app for key tasks. Map the "happy path" (everything works) and at least one error/edge case path for each critical flow. Draw these on paper, a whiteboard, or in Figma/Excalidraw.
> Time: ~2-3 hours
> Reference: See `references/wireframe-checklist.md` (IA template section)

<!-- intermediate -->
**Information architecture & user flows** — Site map / screen inventory (list every screen with parent-child relationships). Navigation model (primary nav, secondary nav, breadcrumbs, contextual links). User flows for critical paths: signup/onboarding, core task loop, upgrade/payment, settings/account management. Each flow: happy path + error states + edge cases. Validate IA with card sorting (open sort with 5+ users) or tree testing if resources allow.
> ~2-3 hours | `references/wireframe-checklist.md`

<!-- senior -->
**IA & user flows** — Screen inventory with hierarchy, navigation model, critical-path user flows (happy + error), card sort or tree test validation.
> `references/wireframe-checklist.md`

---

### Wireframe Methodology

<!-- beginner -->
**Create wireframes for every screen** — Wireframes are simplified drawings of your screens that focus on layout and content, not colors or polish. Work in three stages: (1) **Low-fi** (paper sketches or whiteboard, ~5 min per screen) — get ideas out fast, explore 2-3 layout options per screen. (2) **Mid-fi** (Figma or Excalidraw, key screens only) — add real content, define the grid, show all interactive elements. (3) **High-fi** (pixel-perfect, design tokens applied) — only after low-fi and mid-fi are validated. Most MVP teams only need mid-fi wireframes. Do not skip to high-fi — you will waste time polishing screens that get redesigned after user feedback.
> Time: Low-fi ~30 min, Mid-fi ~2-4 hours, High-fi ~1-2 days
> Reference: See `references/wireframe-checklist.md`

<!-- intermediate -->

From harmansidhudev/shipwise, MIT.

More from harmansidhudev/shipwise