Using Jira for Design Projects
I like using Jira.
Maybe that’s a controversial statement, but I value the order it brings to the chaos of making, curating, and maintaining a design system—or just life in general. It’s a forcing function that turns a hazy pile of ideas into actionable tasks. It gives structure to creative mess and nudges us to think ahead.
That said, not everyone shares my sentiment. At Blizzard, I’ve used four different project management tools in a short time—Airtable, Notion, Asana, and Jira. Every team has its own flavor. What worked beautifully for one group barely made sense to another. But by the end of my tenure, there was a growing consensus among design leads: the need to converge on a unified way to track and communicate work across the org.
Why Bother With Jira?
Yes, managing Jira takes effort. It requires admin time. It might slow down that fast-and-loose iteration loop. But order is not natural to the universe—entropy is. If we want to scale design systems work and collaborate effectively across a growing org, we need a system. Jira isn’t perfect, but it’s powerful when used well.
In this post, I’ll walk through how our design systems team used Jira to manage our work—so it’s not just for tracking features, but also for building shared understanding and accountability across design and engineering.
Why a Unified Tracking Convention Matters
Design systems aren’t just internal tools—they’re living products that touch every corner of the org. A clear, shared way of tracking work benefits everyone:
Fosters tighter design-engineering collaboration. When Jira becomes a common language between disciplines, handoffs and dependencies become smoother.
Provides visibility. Designers across the org can see what’s on the roadmap and where they might contribute.
Helps the system team stay ahead. Seeing other teams’ initiatives early allows us to prepare relevant components or improvements before requests land last-minute.
Designing With vs. Designing For the Design System
We distinguished between two modes of working:
Designing with the design system: Teams using existing components to build product UI. We didn’t impose workflows here—flexibility was key.
Designing for the design system: Teams proposing new components or modifying existing ones. This is where process matters. Changes here ripple across the org, and we needed visibility, review, and shared ownership.
This distinction helped clarify which workflows required structured Jira usage and which didn’t.
#1 - Creating a Backlog of Component Ideas
All great design systems work starts with a messy backlog of ideas: feature proposals, component gaps, minor polish tasks, bugs, and cross-functional requests.
To avoid losing these in Slack threads or random whiteboard stickies, we logged each idea in Jira as a story. And crucially, we encouraged thoughtful titles and descriptions. “Fix spacing” doesn’t help anyone three weeks later. We included:
A problem statement or user story
Context (screenshots, links, who requested it)
Impact level (blocking? nice-to-have?)
#2 - Turning Features into Epics
Once a component idea had enough clarity and support, we upgraded it to an epic. This helped track all the steps involved in delivery, which often span multiple sprints and team members.
We standardized the lifecycle into clear phases, each tracked as a top-level story:
[
Propose]: Research, scope, and present the idea[
Design]: Work in Figma, get design critique[
Code]: Dev work—tokens, mixins, logic[
Doc]: Write usage guidance and rationale[
Publish]: Merge, release, and communicate
Why separate stories? Each phase has its own definition of done, owner, and timeline. Trying to shove it all into one story is a recipe for confusion and missed steps.
#3 - Using Subtask Templates for Contributor Clarity
Since we welcomed contributions from designers outside the core system team, we built subtask templates for consistency.
For instance, a [Propose] story might include:
Pre-proposal research (existing patterns, competitive analysis)
Writing the proposal
Presenting to design/dev communities
Collecting feedback and iterating
To reduce overhead, we used add-ons like Automatic Subtasks or Subtask Manager. These let us apply reusable subtask sets to stories—no more copy-pasting from old tickets.
#4 - Beyond Features: Tracking Operational Work
Design systems aren’t just about components. We created “evergreen epics” for ongoing buckets of work:
Foundation: Tokens, grids, icon updates
Team Support: Onboarding, education, feedback loops
Housekeeping: Linting, cleanup, legacy audit
Doc Site: Adding non-component pages like principles or changelogs
Ops & Process: Improving our Jira hygiene, communication rituals, contribution models
This allowed us to capture the full scope of design systems work—not just the shiny new stuff.
#5 - Building Subtask Culture Takes Time
Team habits around subtasks don’t develop overnight. We learned a few helpful patterns:
Auto-assign subtasks to the story owner whenever possible.
Let team members create their own subtasks—it builds ownership.
Trim the fat. If a subtask doesn’t apply, delete it.
Don’t overload contributors with irrelevant or premature subtasks.
Assign review subtasks only when ready—no one wants “Blocked: Waiting for someone to notice this subtask.”
#6 - Custom Quick Filters for Ceremonies
Quick filters made standups and planning sessions far less painful. We used:
assignee = currentUser() (i.e. “My Issues”)
labels = design-only for filtering out engineering tasks
Sprint-specific filters for themes (e.g. labels = foundations)
This helped us keep conversations focused, especially when screensharing the backlog in meetings.
#7 - Ceremonies: Grooming and Planning in Jira
Sprint Grooming
Usually done by each discipline to add more details and discuss through priorities of tasks.
Polish titles and descriptions
Follow up with ticket creators
Generate subtasks
Adjust sprint/assignee where needed
Sprint Planning
Usually done by the discipline leads and pms to discuss goals for the sprint.
Review unfinished stories
Align on sprint goals
Sequence and assign work using filters by team member
Ensure everyone has realistic bandwidth
Async Standup with Slack Threads
To reduce meeting fatigue, we ran daily standups async in Slack:
A bot posts a prompt every morning
Each team member replies with their focus for the day
Fridays include a brief summary and Jira links
This async flow respected time zones, reduced Zoom overload, and still gave visibility.
Lead by Example
It’s a lot of admin work, yes—but leadership starts with modeling the behavior you want to see. That means maintaining Jira hygiene, grooming stories, and treating task organization as a shared craft.
Over time, teams who use Jira well tend to converge around shared language, timelines, and outcomes. It’s not just about tool proficiency—it’s about investing in the system’s long arc.
And those are exactly the kinds of teams I want to be a part of.