|
| 1 | +# Git Issues |
| 2 | + |
| 3 | +The main goal of applying this structure is to capture UX work outside the standard delivery stream. As a UX team, this allows us to group, prioritise, and assign appropriate priority to our work. It enables us to feed into the main work stream while also tracking and planning UX activity independently. |
| 4 | + |
| 5 | +One issue we face is that it’s hard to track changes we’ve established to have a beneficial impact. These are often obscured by the “completion” of a project, which tends to leave valuable UX work in a dark corner gathering dust. This approach aims to increase UX maturity within the team and allow us to refocus on UX work items that don’t always get picked up in initial delivery cycles. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## Summary structure |
| 10 | + |
| 11 | +UX activities are broken down using a simple, clear hierarchy with **three levels of issues**: |
| 12 | + |
| 13 | +1. **Top level (Epic / Design Brief)** – the big-picture item that guides the work |
| 14 | + - Overarching goal or project |
| 15 | +2. **Mid level (Task / Research / Iterative Testing)** – breaks the work into manageable activities |
| 16 | +3. **Smaller steps (Actions / Supporting documentation)** – specific, actionable work items |
| 17 | + |
| 18 | +--- |
| 19 | + |
| 20 | +## Issue structure |
| 21 | + |
| 22 | +- “Project brief” or “Problem” → “Activity” → “Actions” |
| 23 | +- Example labels: `epic`, `task`, `sub-task` |
| 24 | + |
| 25 | +--- |
| 26 | + |
| 27 | +### Level 1 |
| 28 | +**Project brief** – business case, design brief, or epic |
| 29 | +- Labels: `["Project", "UX", "Brief"]` |
| 30 | +- What |
| 31 | +- Why |
| 32 | +- Summary goals |
| 33 | +- Business need |
| 34 | +- MVP |
| 35 | +- MVP+ |
| 36 | +- What success looks like |
| 37 | +- Does this tie back to the roadmap? (Y/N) |
| 38 | + |
| 39 | +**Problem** – a level 1 or 2 item; a problem can exist independently of a project brief. |
| 40 | +- A simple “what / why” problem statement that also defines users and scope. |
| 41 | +- Labels: `["UX", "Problem", "Activity"]` |
| 42 | +- Scope |
| 43 | +- Users |
| 44 | +- Evidence |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +### Level 2 |
| 49 | +**Problem** – a level 1 or 2 item |
| 50 | +**Activity** |
| 51 | +- Labels: `["UX", "Activity"]` |
| 52 | + |
| 53 | +--- |
| 54 | + |
| 55 | +### Level 3 |
| 56 | +**Documentation** |
| 57 | +- Component |
| 58 | +- Findings |
| 59 | +- Observation |
| 60 | + |
| 61 | +**UX Action** |
| 62 | +- What needs doing? |
| 63 | +- Type / category |
| 64 | +- Notes (optional) |
| 65 | + |
| 66 | +--- |
| 67 | + |
| 68 | +## Notes and follow-up actions |
| 69 | +- Consider whether there should be an “activity” type that is not a problem statement or hypothesis. |
| 70 | +- Add level 3 “Pain point” and “Step” issue types. |
| 71 | +- Add issue types for documentation, including: generic, component, and findings. |
| 72 | +- Add a “ux-testing-plan” template to help build consistent testing plans. |
| 73 | +- Check whether we should list services as labels and provide them via issues. |
| 74 | +- Investigate best practices for design iteration cycles. |
0 commit comments