Design
Writing Design Tickets That Work
by Katie Tavares
7 min read2 July 2025
Contents
The idea for this blog post was born from a challenge that most designers will recognize: tickets. I was working on a high pressure project and the tickets had become more of a blocker than a launchpad. This was noticeably slowing down my workflow. Don’t get me wrong, the intentions behind each ticket were good, but the execution often left gaps. Some lacked the context I needed to make confident design decisions, while others leaned too far in the opposite direction, outlining a step-by-step solution that left little room for the creative problem-solving that is my job description.

I shared some feedback, but in the process of doing that I realized the issue wasn’t purely about individual tickets, it was fundamentally about alignment across the team.

That led me to putting together some internal guidelines. I did my best to compile a list of clear and approachable points, meant to help anyone on the team write more effective design briefs. On the project these guidelines were introduced, we had a significant decrease in the back and forth that tickets were causing.

At Pixion, we’re big on AI innovation. We’re always looking for ways to integrate smart tools into our workflow so we can deliver results faster and collaborate better. With that philosophy in mind, the team took the guidelines I had created and integrated them into their LLMs of choice. The result has been tickets that are well structured and set designers up for success every time.

This post is a version of those same guidelines that we’d like to share with you. A designer’s perspective, based on a simple but powerful structure: What, Why and How?

Let’s break it down.

The What (Needs to Be Done?)
Copied!

Let’s start with the basics. The “What” should clearly describe the task at hand. Be specific. The clearer the ask, the faster we can jump into solution mode.

❌ Avoid: “Design a better way for users to manage their content.”

✅ Try this instead: “Design a system that allows users to group and label their content in customizable categories. Users should be able to create, rename, and reorder categories as needed.”

Clarity up front allows us to understand the goal from the start. With that, we can design with more intent and precision.

The Why (Is It Needed?)
Copied!

Design is about solving problems, not just making things look good. That’s why understanding why a task exists is critical.

What’s the user problem we’re addressing? Why now? How does it tie into the bigger picture?

When you include this kind of background we’re not just checking boxes, we can design with purpose.

💡 For example, instead of saying “make this easier to use”, provide some more context. Something like: “Users have reported difficulty navigating large content libraries. They often lose track of items and have requested ways to filter and group content more effectively. This change is expected to reduce support tickets and improve engagement.”

With that context we’re aligned on the why, and that unlocks more targeted and intentional design decisions.

The How (Should It Be Done?)
Copied!

This part isn’t about telling us what the solution looks like, just letting us know what we need to keep in mind. Think of it as a space to flag anything that might shape our direction, things like technical limitations, brand guidelines, legal requirements… anything that could impact scope or direction.

Highlight what must be considered, but leave room for the design thinking process.

💡 For example: “This needs to work within the existing mobile layout and follow accessibility standards for contrast.”

Now we’re designing with alignment, not surprises.

Acceptance Criteria
Copied!

We need to know how success will be measured. What does “done” look like? What functionality needs to be included? What should be testable or demo-ready by the end? The best format is a simple checklist. When that’s clear, everyone wins.

Prioritization
Copied!

Designers often have multiple tickets in play. Knowing which ones are critical versus “nice to have”-s helps us prioritize and collaborate more effectively. This makes a big difference in how we plan and communicate.

That’s a Wrap!
Copied!

The best tickets do more than tell us what to do, they also explain why and how.

When you write tickets using this format, you’re not just assigning a task, you’re setting your design team up to do their best work. Strategically, thoughtfully and user-centered.

So here’s a big thank you to the PMs and engineers who already work this way, and a special shout-out to my team members who are always open to learning and improving our collaborative environment.

If you’re just getting started, give our structure a try. Your design team will thank you.

Keep ReadingCheck out more blogs