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.
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.
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.
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.
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.
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.
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.