
Jira for Designers Without the Pain: Issue Types, Backlogs, and Figma
How to use Jira as a designer without wasting time: issue types, statuses, backlogs, the Figma integration per its help page, and when another tool fits.
What is Jira, and why does it matter to design?
Jira organizes work into work items, boards, and backlogs. Atlassian announced in November 2024 that it would stop calling them issues: in menus and help they are work items, and the kind (story, bug, and so on) is the work type. This article uses issue because many teams still do, and it means the same thing. In many product teams, it is where development follows what it has to build. If design is not in that system, screens reach development through other channels: a link in a chat, a screenshot in an email, a file nobody knows is the latest.
So the designer’s goal is not to master Jira, but to make sure what is designed has an issue, a status, and a link to the right file.
Why does this matter for a junior designer?
Because the Jira board is often the first place a junior sees how the product team works. Understanding work types, statuses, and the backlog lets you propose a design flow that does not create noise. Knowing what not to send to Jira is also part of the job.
Many conflicts between design and development come from poorly defined statuses. If “done” means different things to each person, the ticket keeps bouncing back.
Which issue types should you use?
Atlassian explains that a work item can represent a story, a bug, a task, or another kind of work, and that space admins can create new types. Hack Design, a third-party design guide, describes the usual hierarchy: Epics contain Stories, Tasks, and Bugs. A Story is a feature from the user’s perspective, and an Epic is a big feature made of several stories. For design it suggests custom types such as “Design Task” or “Design Spike”, the latter a time-boxed exploration that delivers decisions, not finished work. It is a third party’s recommendation, not an Atlassian norm.
A practical rule: an issue type should help make a decision. If the team cannot say what makes a “Design Task” different from a “Story”, the type is unnecessary.
How do the backlog and statuses work?
According to Atlassian’s help, there are two kinds of backlog. The Scrum backlog shows the space’s work grouped into a backlog and sprints; you rank each item by dragging it and move it into a sprint by dragging it there. The Kanban backlog has two sections, Backlog and Selected for Development, and keeps planning out of the team’s way so the board shows only work in progress. An admin must enable it for each board.
Statuses describe an item’s place in the workflow, and board columns are mapped to them. By default, a Scrum board’s columns are To Do, In Progress, and Done, and a Kanban board’s are Backlog, Selected for Development, In Progress, and Done. Jira only counts work in the right-most column as complete, so a status such as “Canceled” must be mapped there or it can block closing a sprint. Hack Design suggests To Do, In Progress, Review, and Done for design. It is an example, not a default. What matters is that each status has a shared meaning. A “Review” status that does not say who reviews or what is reviewed is useless.
The handoff to development is the most delicate point. A status such as “Ready for development” should mean the design is approved, the screens are linked, and the error cases are documented.
How does it connect with Figma?
According to Figma’s help, the integration is installed with the Figma for Jira app and requires a Jira Software account, plus permission to view the linked file. It lets you link files or prototypes to a work item and preview the design without leaving Jira. The work item shows “Design updated” when the linked file has changed since you last viewed it, and “Ready for dev” mirrors the file’s Dev Mode status in Figma. The Jira plugin in Figma lets you link existing work items to pages or layers and create new work items from Figma.
Figma’s help also says embeds cannot be added in Jira Align or Jira Service Desk with this integration (its name for that product). If your team uses those tools, check before planning the flow. The help states no plan requirements. Jira has Free, Standard, Premium, and Enterprise plans; check Atlassian’s pricing page for prices and limits.
When is Jira NOT the right choice for design?
- When development does not use Jira. There is no point taking design to a board nobody watches. Use the tool the development team uses.
- When design work is exploratory. An open space, such as FigJam or Miro, is usually better for thinking before turning something into a ticket.
- When you only need to log a one-off request. Opening an issue for every small change clutters the board and adds nothing.
Hack Design recommends doing design thinking in Figma, Notion, or a notebook, not living in Jira, batching updates, and moving work to Jira when it is ready for development. It is a third party’s opinion, but it matches the idea of having a single source of truth for each decision.
Example
Illustrative example: a product team uses Jira with a Scrum backlog. A junior designer wants to take on the redesign of the invoices screen.
- Work items: an Epic “Invoicing redesign” with five Stories, one per flow.
- Statuses: To Do, In Progress, Review, Ready for development, Done. “Ready for development” requires a Figma link and a list of error cases.
- Link: each Story links to its Figma frame. When the file changes, Jira shows the “Design updated” notice.
- Problem found: one Story moved to development without its error cases. An explicit check is added to the definition of “Ready for development”.
The change was small: one sentence in the definition of a status. But it stopped development from building without half the information.
For the design handoff side, the article on design handoff describes what should reach development, and the article on project management covers how work is organized over time.
If your team already uses AI agents on the board, the article on handoff in the AI era covers what changes in that handoff.
Common mistakes
- Creating issue types that nobody can tell apart.
- Defining statuses without agreeing what each one means.
- Sending design decisions to Jira that should live in Figma.
- Opening an issue for every small change.
- Moving an issue to development without a design link or error cases.
- Planning the Figma integration without checking which Jira products your company uses (Software, Align, or Service Desk).
Sources
- Atlassian, ‘Work,’ your way: Jira’s language is evolving to better represent all teams (November 13, 2024)
- Atlassian, Use your scrum backlog
- Atlassian, Use your kanban backlog
- Atlassian, Configure columns
- Atlassian, Work items in Jira Software
- Atlassian, Jira pricing
- Figma, Jira integration (Figma help)
- Hack Design, Jira (third-party guide)