Infusing AI into the Work Item

Work items are the backbone of Jira, yet the interface has remained a "one-size-fits-all" scrolling form., used by millions daily to track everything from bugs to epics. As Jira evolved toward AI-driven experiences, this view emerged as a critical opportunity for transformation. Despite being a team's source of truth, work items often fluctuate between two extremes: too sparse to be useful, or too cluttered to be understood. This information density creates a paradox where more work leads to less clarity, forcing teams to hunt for answers: What’s the status? What’s the next step? Who owns the momentum?

Work items are where everything happens in Jira, but the experience hadn't meaningfully evolved to match the lifecycle of work. It was the same shape whether the item was a one-line placeholder or a dense artefact with months of discussion, attachments, and dependencies. Users had to do the work of triaging what mattered, every time they opened it, creating three major challenges:

• The "Chore" to create: Writing out every detail, setting up requirements, and breaking down big tasks takes a lot of time. People spend more time setting up the work than actually doing it.
• The "Sparse" start: Many items begin as just a title. In a rigid UI, these feel hollow and unhelpful, offering no guidance on what information is missing to move the work forward.
• The "Cluttered" maturity: As work scales, items become "information graveyards." A single task can balloon into 50+ scattered comments and nested dependencies. The truth is in there, but it's buried under a massive cognitive tax.

Whether an item is empty or overwhelmed, the burden falls entirely on the user. This leads to work arounds or for teams to abandon Jira for Slack or spreadsheets just to get a straight answer. We recognised that generative AI is uniquely suited for these tasks in helping generate the foundation when an item is new, and helping synthesise the noise once it becomes complex

I partnered with a researcher to understand how AI could reshape the work item experience. We conducted concept testing with eight marketers from both Jira and competitor tools (like Monday.com) to find out:

• Which directions best met user needs, and what could be improved?
• What could we learn from the directions that didn't win?
• What existing pains, needs, and behaviours should we leverage?

Coming out of the research, a specific opportunity stood out: when users open an existing work item, they spend real time re-orienting. Scrolling through comments, checking what changed, figuring out what's blocking progress. For dense or long-running items, this can take minutes of reading before any actual work happens.

An AI generated summary panel, at the top of the work item, promised to fast track that but only if it knew what to say. A summary of an empty work item is useless while a summary of a year old task with 200 comments needs to be ruthlessly prioritised. The design problem wasn't "what does the summary look like" it was "what should the summary be, given how much is actually there?"

Before designing anything new, I began by auditing every AI experience already present on the work item. A few patterns became clear:

• Fragmentation. AI showed up in multiple places with inconsistent voice, surface, and interaction models.
• Redundancy. Several features were quietly solving overlapping problems in slightly different ways.
• No hierarchy. Users had no sense of which AI experience to reach for in which situation.

I then built a framework for the summary component that mapped the work item onto a spectrum of content density - from empty placeholder to very dense. For each state, the framework defined three things:

• What the work item looks like: the observable content signals (description length, comment volume, attachments, subtasks, dependencies, history depth).
• How AI should respond: the underlying summary behaviour and tone.
• Suggested actions: what we should prompt the user to do next.

The framework helped in the following ways:

• It made the invisible explicit: "Summary" stopped being one thing and became five coordinated behaviours.
• It gave the team a shared vocabulary: PMs, engineers, and other designers could talk about "the moderately detailed state" and mean the same thing.
• It made the edge cases designable: Empty and dense states got the same rigour as the happy path.

With the framework in place, the design became a series of focused problems rather than one overwhelming one. I began by designing the end vision flows of where we wanted the experience to go. Then pared it back to an experience more achievable in the short run as our MVP.

The AI summary was one of several generative experiences I designed across the work item. Each addressed a different moment in the work item lifecycle.

The research report was shared broadly across the organisation, reaching 103 viewers - including executives and leaders across multiple teams. It received recognition as a clear, well-structured piece of strategic design work that shaped how the broader team understood the opportunity.

The AI summary system is scheduled to launch at Team ‘26, Atlassian’s flagship global conference. The project reinforced a core principle: good AI design isn’t about how much it can generate, it’s about removing friction from how teams already work.

The structured response framework also crystallised how AI is most effective when it’s anchored. Rather than unleashing models to be conversational and open ended, framing them in a clear structure made them dramatically more useful. A framework isn't a constraint on AI, it's a design pattern that makes AI useful at scale.

The open question I'm still sitting with is how do you design for appropriate trust in AI experiences? If users trust the AI too little, they’ll ignore it and keep doing the manual work. If they trust it too much, they might miss a critical detail the AI skipped. The density framework is a start — it changes how the AI behaves based on how much data is available — but "calibrated trust" is a design problem we are only just beginning to solve.