Navigating Design Jira Process

Navigating the Product and Design Jira Process

This skill grounds Jira moves in the design team's current practice for plugging into

engineering's Jira workflow. The goal: keep design decisions visible alongside the

engineering work — without maintaining a parallel design tracker. Designs are attached

directly to the engineering tickets they belong to, and everything substantive (30/60/90

critique iterations, copy, annotations) lives in Figma.

> A note on status names below. Jira status labels appear here in the same casing Jira

> uses them — IN DESIGN, IN PROGRESS, DONE, DESIGN NEEDED, Ready for Dev. Copy them

> verbatim when transitioning tickets.

The structural rule

Designs are attached directly to tickets. The Figma file lives in the engineering Epic's

"Design" field (or, for one-off engineering stories, in the story's "Design" field). There is

no parallel design project, no parallel design Kanban, and no per-stage design tasks.

That's the design-team-Jira insight in one sentence. Everything else is choreography around

this rule.

Epic-driven flow

Initial setup

• A PM creates at least one Epic to accompany every Product Initiative document they're

working on.

• PM assigns the Epic to the designated designer.

In Design

• Designer (or PM) moves the Epic to IN DESIGN.
• Designer runs the 30/60/90 critique cadence in Figma — no separate Jira tasks per stage.

Stage iterations, attached materials (stakeholder presentations, research), and

cross-iteration feedback all live in the Figma file alongside the work.

Design Done

• In Figma, group final designs on a single page with named Sections for each story-level

surface.

• Designer links the Figma file in the Epic's "Design" field.
• Designer marks Figma sections as "Ready for Dev".
• EM moves the Epic to Ready for Dev to signal engineering can pick the work up. (Some

teams have automation that handles this; treat it as the EM's responsibility for now.)

Engineering technical breakdown

• When engineering creates stories during technical breakdown, designer + PM + the engineer

doing the breakdown together review the stories.

• For each story, ensure the correct Figma section is linked and that the section's content

is only about that story. One-to-one mapping.

In Progress (and dev support)

• PM or EM moves the Epic to IN PROGRESS when development starts.
• PM/EM creates a dev-support task titled [project name] - dev support, assigns it to the

project's designer, and links it as "relates to" all engineering stories needing design

support. (This convention persists for now even as other separate-design-task work has

retired.)

• The task lets the designer know when their project enters development and represents the

misc support needed throughout.

• When the last engineering task is done, the dev-support task is also marked DONE.

One-off engineering stories

Some stories aren't tied to an epic — common on the UI Foundation team. The flow is shorter:

• An engineering story is created outside an epic; PM or EM realizes design support is needed.

(Or: a designer working on a component improvement for UIF creates the story themselves.)

• PM or EM moves the story to DESIGN NEEDED and assigns it to the feature team's designer.
• Designer does the design work in Figma. No separate design task is created.
• When the design is complete, the designer:
• Links the Figma file to the story's "Design" field.
• Unassigns themselves from the story.
• Adds a comment in the ticket noting the design is ready to be picked up.

The three closing steps — link, unassign, comment — are explicit. Skipping any of them

leaves the story stuck in someone's queue or visible-but-not-discoverable.

Composing with other skills

• preparing-design-handoff. The transitions at the end of In Design (Figma linked, sections

marked Ready for Dev, EM moves Epic) are the pre-handoff side of the handoff process. The

handoff skill is the gate / checklist; this skill is the canonical lifecycle.

• evolving-design-system-components. Component Library work generates Jira issues on

the Component Library board. Those follow the same rule (designs attached to tickets), but

feature-team-owned recipes generate stories in the feature team's project rather than the

Component Library project. Surface the difference explicitly to the designer.

Common mistakes to catch

• Forgetting to mark Figma sections "Ready for Dev." Engineering can't find what's final.

This is part of Design Done, not optional.

• Sections not aligned to stories. When engineering creates stories, each story should

map to a Figma section whose content is _only_ that story. Mismatch creates ambiguity at

review time.

• One-off engineering story left unfinished at the design end. All three closing steps

must happen — link Figma to the story's "Design" field, unassign self, comment that the

design is ready. Missing any one of them leaves the ticket in an ambiguous state.

• PM creating the dev-support task too late or not at all. When dev support isn't

visible on the Epic, dev support requests come at the designer without warning. Surface

this gap when reviewing a project's Jira state.

Output format

When asked to set up or move work through the Jira process:

• Project shape — is this an epic-driven project or a one-off engineering story?
• Current state — what Jira entities exist (Epic, story, dev-support task) and their

current statuses.

• Moves to make — the specific status transitions and Figma links to apply, named by

responsibility (designer, PM, EM).

• Figma links — what to attach where (Epic "Design" field, story "Design" field).
• Watch-outs — the common mistakes above that apply to this specific project.