How I write better Jira tickets as a designer
TL;DR
Writing dev tickets always felt like translating design-brain into developer-brain badly. Now Codex does that translation for me, using an MCP server to pull my Figma and whiteboard context directly, turning it into tickets, checking builds against the original design, and writing the docs after, so I still think like a designer and lose less context in the handover.
Writing Jira tickets is not why I became a designer.
I know what I mean when I design something. I know why that component changed, what happens when a user takes the weird route through the flow, and why there are six almost-identical frames sitting next to each other in Figma.
Then I need to turn all of that into an implementation ticket.
Suddenly I'm writing acceptance criteria.
Not really the vibe.
So I've been experimenting with using Codex as the translator between my design brain and the people who actually have to build the thing.
And it's turning into a surprisingly useful workflow.
Enter Codex
The setup looks like this:
Figma + FigJam / Miro → Codex → Jira / GitHub Issues → Dev → Codex-assisted QA → Documentation
I'm not moving everything into Codex.
Figma is still where I design. FigJam or Miro is where I map the journey, requirements and decisions behind it. Jira or GitHub is where the dev team tracks the work.
Codex sits in the middle.
A little conductor's podium from where I can orchestrate the handovers without having to become particularly technical myself.
First, give it the design
I connect Codex to Figma using an MCP server.
That sounds considerably more technical than what I'm actually doing.
Basically, it gives Codex a way to access my design context directly instead of me taking screenshots, copy-pasting things or attempting to explain which of the four grey rectangles I'm talking about.
Figma gives it the design.
Then FigJam or Miro gives it the context.
That's where I've already mapped things like the user journey, new requirements, scenarios and the decisions that led to the change.
Together they tell a much fuller story:
Here's what I designed. And here's why.
Here’s where Codex earns its keep
This is the bit I actually care about.
I'm not asking Codex to make technical decisions for me.
I'm asking it to take something I understand very well and translate it into a format that's more useful to someone working in development.
The problem. The requirements. The relevant scenarios. Edge cases. Acceptance criteria.
I can review the result in normal language, correct anything it misunderstood, then ask Codex to create the actual Jira ticket or GitHub Issue through the relevant integration.
No copy-paste relay race.
And the developer gets a normal ticket in the place where they already work.
They don't need to adopt my workflow. Or care that Codex was involved at all.
The handoff goes both ways
The slightly unexpected part comes after development.
When the developer says "ready for review", I can bring Codex back into the process.
It already knows what I designed and why. It knows what went into the implementation ticket. With access to the implementation, it can help me compare what was built against that original intent.
Did we cover the scenarios?
Are the states there?
Does the interaction match?
Is something behaving differently from what we agreed?
I'm still doing the design QA. Codex just helps me interrogate what's been built without requiring me to understand the code underneath it.
And when it does find something technical?
"Explain that to me as a designer."
Genuinely useful.
What we designed vs. what actually shipped
Only after QA do I want to document the change.
For a small design system update, that might just be a changelog in Figma.
For something larger, Codex can take the context it already has and help turn it into Confluence documentation.
The nice part is that I'm documenting what actually shipped, not the thing we thought we were going to ship three weeks ago.
Because those aren't always the same thing.
Less lost in translation
There are plenty of conversations about using AI to generate interfaces or helping designers write code.
That's not really what interests me here.
I don't particularly want Codex to make me a developer. I want it to help me work better with developers.
I can keep thinking in journeys, interactions, scenarios and design decisions.
The developer can keep thinking in whatever mysterious things developers think about.
And Codex can help translate between the two.
Same tools. Same people. Hopefully a little less lost in translation.
