UX Planning Infrastructure
Making design capacity visible at roadmap altitude — 5 structured fields in Aha!, a 4-lane workflow into Jira, and a cross-functional T-shirt sizing process that surfaces UX constraints before sprint commitments are locked.
The Problem: UX Work is Structurally Invisible
Product planning tools are configured to model PM and Engineering work precisely. Aha! captures PM intent. Jira tracks engineering execution. UX effort exists in neither system — which makes reactive, last-minute design work structurally inevitable, not a team failure.
Root cause: This is an infrastructure gap, not a people or process problem. Until UX capacity is modeled at the roadmap layer, planning will keep producing the same delays.
- $2M+ revenue at risk: Three enterprise features delayed because design constraints weren't visible until sprint planning — too late to adjust scope.
- 3–4 weeks delay per feature: The consistent cost when UX scope is discovered mid-sprint rather than at roadmap altitude.
- 0% forward visibility: Leadership has no way to answer: "Does this roadmap fit our design team's capacity?"
The Solution: 5 Fields in Aha!, 1 Workflow into Jira
Aha! shows intent. Jira shows reality. UX managers manage the gap.
The fix closes an infrastructure gap by adding five required fields to each Aha! feature. These fields give the planning system the data it needs to surface UX constraints at roadmap altitude — before sprint commitments are locked. Aha! is used for planned demand and ownership; Jira is used for execution and iteration tracking.
| Field Name | How to Fill It |
|---|---|
| UX Design Required (Yes/No) | Select Yes if UX design work is needed |
| UX Design Phase (multi-select) | Choose relevant phases: Concept, Interaction, Iteration, Delivery Support |
| UX Design T-Shirt Size (XS–XL) | Rough effort estimate — see sizing guide below |
| UX Design Start / End | Quarter or sprint range when design should happen |
| UX Designer Owner | Assign designer or set to TBD |
Critical: If UX fields aren't filled, UX work becomes invisible and capacity planning fails. Any feature with "UX Design Required = Yes" is blocked from sprint planning until all five fields are complete.
The Aha! → Jira Workflow: 4 Lanes
Aha! is used for planned UX demand (feature level). Jira is used for actual UX work (task level). The system operates in four lanes, each with a clear owner and handoff point.
- What features are coming
- Target timeframe
- UX Design Required
- UX Design Phase
- UX T-Shirt Size
- UX Start / End
- UX Designer Owner
- Review upcoming UX demand
- Balance load across designers
- Adjust timing or ownership
- Align with PM before work starts
- Feature context
- UX fields (read-only)
- UX workload per IC
- Tickets per iteration
- Spillover & delivery support load
- Designs shipped
- Reviews completed
- Support delivered
- Was UX size accurate?
- Did work start early enough?
- Where did scope creep occur?
- Planned UX demand
- Feature ownership
- Capacity forecasting
- Roadmap-level decisions
- UX tasks
- Iteration commitments
- Work-in-progress
- Actual effort & delivery
Aha! shows intent. Jira shows reality. UX managers manage the gap.
- Turn Aha! into a task tracker
- Show daily status updates in Aha!
- Mix IC task tracking into planning views
Focus on clarity, role boundaries, and planning confidence.
Cross-Functional Collaboration: T-Shirt Workflow
The T-shirt sizing system lives inside a broader cross-functional framework. This is a transparent checklist used by UX, PM, and Engineering to take a product from 0→1 — with quality control and progress tracking at every phase gate.
Design principle: The product development size is a structural tool for a "0 to 1" product launch, inspired by the Lean Startup's Build-Measure-Learn cycle. The goal is to maximize validated learning and minimize wasted effort.
| Size | Description | Typical Duration | Example |
|---|---|---|---|
| XS | A small, contained feature or a simple task that can be built on an existing product/platform. Focus on a single-use assumption. | 1–2 weeks | UI improvement, tooltip, or button behavior |
| S | A new, but very simple product/solution with one core workflow. Low technical complexity and minimal integrations. Focus on the core value proposition. | 2–4 weeks | Adding a filter, a settings module |
| M | A new feature/product with a few core features and workflows. Medium technical complexity. May include simple integrations. Requires a dedicated, small team. | 2–4 months | Mid-size dashboard or feature set |
| L | A significant product/feature at a sub-platform within the company. High technical complexity, multiple integrations, and requires significant infrastructure setup. Requires a cross-functional team. | 3–6 months | New supplier module or analytics tool |
| XL | A completely new, highly complex product ecosystem that requires a large team, a new technology stack, and extensive legal/compliance review. A net-new platform or product line. | 6–18 months | Launching a new AI-based or network product |
Each feature moves through five phases. Phase gates (Approved / Extended / Risk / None) ensure cross-functional visibility before work advances. Each step has a defined owner, effort estimate, and size applicability (XS–XL).
Each phase ends with a gate status and optional notes. Status options: Approved, In Progress, Done, Delay, Blocked, Reviewed. Phase Final Status is set as: Approved · Extended N Days · Risk · None.
Each phase works with a cross-functional span (PM, UX, Eng) and a long-confirm: confirm steps are taken to ensure work is properly handed off. Size-scoped columns (XS–XL) control which steps apply to each project size.
Implementation & Expected Outcomes
- Configure 5 UX fields in Aha! and set up automation rules
- Brief UX Leads on the new workflow — Aha! for planning, Jira for execution
- Run a pilot on 3–5 in-flight features to validate the model
- Present pilot results to PM team with concrete before/after data
- Co-define the T-shirt sizing guide and cross-functional workflows
- Resolve edge cases and build shared understanding before enforcement
- Activate system-level enforcement: features blocked from sprint without complete UX fields
- Launch capacity dashboard for leadership — roadmap vs. UX capacity at a glance
- Establish quarterly forecast review as standard operating cadence
Decision 1 — Approve 8-Week Pilot
Scope: 3–5 features. Low disruption, fully reversible. Produces real data before full commitment.
Decision 2 — Assign Implementation Owner
Proposed: Head of UX as DRI, VP of Product as Executive Sponsor. Both required to unblock cross-functional configuration.
Decision 3 — Commit to Enforcement Date
Target: 5 UX fields mandatory and system-enforced by Week 5. Committing to this date prevents the pilot from stalling at the alignment stage.