---
name: ux-ui-rich-product-task-breakdown
description: Produces hierarchical epics, tasks, and subtasks with UX, UI clarity, ease of use, and rich product features as the primary lens. Assume multi-tenant SaaS: product default form templates plus organisation-built custom forms for gaps. Plans must cover admin setup (templates + custom builder), runtime rendering, and edge states—not only one hard-coded happy path. Use when the user asks for a plan, roadmap, backlog, sprint work, screen or flow design, NGO or SaaS ERP modules, or any task list where usability and interface quality should lead engineering.
---

# UX-first task and subtask breakdown

When the user asks for a plan, roadmap, backlog, or tasks, **default to this structure** unless they specify another format (for example a pure technical RFC only).

## Output format (always use)

Organise work as:

1. **Epic** — user-facing outcome (one sentence, value to the person using the system).
2. **Task** — shippable slice that a user can notice or validate (prefer vertical slices over “only API”).
3. **Subtask** — concrete step, often 1–4 hours of focus; each subtask has a **UX or UI acceptance** line where relevant.

Use checkboxes for trackability:

```markdown
## Epic: [Short name]
**Outcome:** [Who benefits + what becomes easier]

### Task: [Verb + object]
**UX goal:** [Clarity / speed / confidence / accessibility]
- [ ] Subtask: …
  - **UI/UX acceptance:** …
```

Optional add-ons per task (when useful):

- **Primary user:** (for example finance officer, programme manager, field staff).
- **Empty / error / loading states:** explicit subtasks.
- **Accessibility:** keyboard path, focus order, contrast, labels (not “WCAG” alone—name the check).

## Principles (apply while generating tasks)

### UX and ease of use

- **Progressive disclosure:** simple default path; advanced options behind clear entry points (menus, “More”, accordions, secondary screens)—subtasks for each layer.
- **Forgiving flows:** undo where safe, confirm only for destructive actions, autosave drafts where appropriate.
- **Obvious next step:** every screen answers “what do I do now?”—subtask for copy, primary button, and breadcrumb or back.
- **Consistency:** same patterns for lists, filters, forms, and tables across modules—subtask “align with existing [layout] pattern”.
- **Stable deep links:** URLs, shared links, and client-held record keys use **`uuid`** (or the product’s non-integer public identifier), not numeric **`id`**, so bookmarks are non-enumerable and align with API contracts—subtasks should call out router params and fetch paths that use `uuid`.
- **Performance feels:** skeletons, optimistic UI where safe, chunked lists—subtasks not only “query optimisation” but **perceived** speed.

### UI richness (without clutter)

- **Density controls:** optional compact or comfortable view for power users.
- **Contextual help:** inline hints, tooltips for jargon (grant, budget line, donor), link to short help—dedicated subtasks.
- **Feedback:** success or error toasts, inline validation, progress for long actions—each flow gets subtasks.
- **Discoverability:** empty states with **one primary CTA** and short explanation; feature discovery for “rich” capabilities (shortcuts, bulk actions, exports).

### Rich features (broken into safe slices)

- Split “big” features into: **MVP usable** → **power user** → **polish**. Each phase is its own task with subtasks.
- For each rich capability, include subtasks for: **permissions**, **audit or log**, **mobile or narrow viewport**, **export** if data-heavy.

### Dynamic forms, approvals, and stages (planning lens)

When a feature involves **data entry**, **sign-off**, or **status progression**, assume **tenant-specific configuration** unless the user explicitly asks for a single fixed workflow.

- **Forms:** split work into (1) **definition** experience for admins (fields, sections, required/help, conditional rules), (2) **runtime** form that renders from that definition, (3) **validation parity** (same rules server-side), (4) **change management** (editing a form version while drafts exist).  
  - **Defaults vs custom:** UX for **browsing product templates** (“Start from: donor interim report”), **duplicate and edit**, and **create blank** for power admins; empty state should not assume JSON skills—use a **form builder** or guided field-add flow.  
  - **Discovery:** make it obvious which forms are **system-maintained** (read-only or “upgrade available”) vs **organisation-owned** (fully editable).
- **Approvals:** include tasks for **chain builder** (steps, roles/groups, parallel paths, thresholds), **inbox / “my approvals”** clarity (what grant, amount, budget line), **delegation or substitute** if in scope, and **disabled primary action** copy that names the missing step or role.
- **Stages:** include tasks for **pipeline configuration** (labels vs stable codes), **timeline or stepper UI** that updates from instance state, **reject / recall** paths, and **empty** state when no workflow is configured (“Ask an admin to enable…”).
- **UI/UX acceptance examples:** user always sees **current stage** and **who can act next** (by role name, not an opaque code); changing configuration does not trap in-flight items without a visible resolution path.

## Task generation checklist (run mentally before delivering the list)

- [ ] Every epic ties to a **real user** and **job-to-be-done**.
- [ ] No task is “implement whole module”—tasks are **reviewable** in a PR or demo.
- [ ] Subtasks include **UI states** (loading, empty, error, success), not only happy path.
- [ ] At least one subtask per major flow for **accessibility** (focus, labels, semantics).
- [ ] Navigation and **information architecture** appear as explicit tasks (menus, naming, grouping).
- [ ] If tables or dashboards: subtasks for **sort, filter, save view**, and **column relevance** for role.
- [ ] If forms, approvals, or stages: subtasks for **admin configuration**, **runtime render**, **in-flight / version change** behaviour, and **audit visibility** (who approved when).  
- [ ] If data capture: subtasks for **default template library**, **tenant custom form creation** (no raw JSON required for normal users), and **where submitted data appears** (grant file, export, reviewer view).

## Example skeleton (replace with project-specific content)

```markdown
## Epic: Pay approved supplier without leaving the grant context
**Outcome:** Finance user pays quickly with confidence the spend hits the correct grant and budget line.

### Task: Payment request detail screen tells the full story at a glance
**UX goal:** Reduce tab-hopping and doubt before pay.
- [ ] Subtask: Header shows grant code, donor name (secondary), budget line, and amount in one summary strip.
  - **UI/UX acceptance:** User does not scroll to answer “which grant is this?” on desktop; on mobile, summary collapses into tappable summary row.
- [ ] Subtask: Primary action “Record payment” visible only when role + status allow; disabled state explains why in one line.
  - **UI/UX acceptance:** Tooltip or inline text names missing prerequisite (for example “Awaiting finance approval”).
- [ ] Subtask: Loading skeleton for header + line items; error state with retry.
  - **UI/UX acceptance:** No layout jump when data loads; retry does not duplicate submission.

### Task: Rich but simple “mark as paid” flow
**UX goal:** Few fields, smart defaults, clear receipt of proof.
- [ ] Subtask: Single-page modal (or stepper max 2 steps) with date, method, attachment; defaults from last same-vendor payment where safe.
  - **UI/UX acceptance:** Keyboard complete entire flow; ESC closes without loss if draft saved.
- [ ] …
```

## When to use this skill

- Backlogs, sprint plans, “what should we build first”, redesigns, new modules, or **any** instruction to list tasks where **usability and interface quality** are first-class goals alongside technical delivery.

## What not to do

- Do not emit only backend subtasks for a user-visible feature without **UI/UX acceptance** lines.
- Do not merge unrelated epics into one giant task—**split for clarity and incremental release**.
