In my career I’ve heard this conversation play out over and over:
Engineer: “Um, we have no idea what UX is even doing.”
UX: “OK, why don’t we try to add the UX tickets to Jira?”
Engineer: “Um. Damn. That many stories? That is going to clutter everything up.”
UX: “Product, what should I be getting ahead of?”
Product: “Well, um, I have this Google Doc you can look at.”
Engineer: “What’s next? Is this ready to be worked on?”
And, I’ve seen teams try these three options to remedy the situation:
Option 1: Keep UX work in a separate system
Product and UX maintains intricate to-do lists for design and research work OUTSIDE of the primary ticketing system.
Pros: It keeps the ticketing system “clean and uncluttered.”
Con: No one knows what UX is working on, and it is impossible to view the dependencies. The backlog is obscured making it tough to get the “big picture.”
Notes: UXers often have a difficult time explaining the rhythm of their work. They regularly scan for work on the horizon, and “get ahead” of that work by doing research, producing mockups, tinkering, etc. These systems are highly individual. I’ve seen designers use Trello, Basecamp, Google Tasks, stickies, and their notebooks to manage this work. In many cases, it goes unappreciated simply because it is not visible.
Option 2: Track UX work in the ticketing system as distinct and separate tickets
When UX is working on something, it is described as being “In Progress” (along with engineering work).
Pros: This gives a clear sense of WIP (work in progress), and the current burden on UX.
Con: It creates too much clutter/too many tickets, and UX work often falls out of sync with release cycle.
Notes: The trouble here is that design work itself is not shippable, and again it often doesn’t flow in the same way that engineering work flows. So you’ll finish a sprint and the board — digital or physical — will become cluttered with design tickets. Ideally, you’ll have a Shipped status, and therein lies the problem. Unless this design work is related to a customer-consumable/shippable item, it isn’t Done. You could argue that this approach is problematic for user-stories in general. Any time you break up a story based on functional roles (back-end/front-end, for example), you are diluting the story and creating a dependency management game.
Option 3: Track UX as work related to user-focused tickets
UX work is attached to a user-focused story, from early phase backlog refinement to shipped/done.
Pros: It clearly describes dependencies and allows for a “pull” system for design and research, which promotes just-in-time work and remains very user-goal focused.
Cons: But, it may require sub-tasks, and multiple people assigned to a particular ticket. This approach requires strong stories and story splitting practices.
Notes: If UX is getting involved on a ticket before engineering (in an analysis/ design/research phase), then it is reasonable to call that work exactly what it is: analysis/design/research. It is similar to the work of engineering architects, business analysts, etc. Some models, like LeanUX, favor less upfront work and eschew the staggered sprint approach. Other teams do a good bit of pre-planning and design before they hand it off to engineering. When the work starts, it typically throws off lots of design tasks along with QA and engineering tasks. These remain with the story.
My bias is for Option 3. It strikes the best balance between:
- Preventing unnecessary pre-work. (We’ve all had efforts killed after being reassured that the work was, in fact, going to happen.)
- Keeping the system clean.
- Reflecting reality.
- Clearly describing the value-stream, as work further to the right gets closer to release and customer outcomes.
- Giving “credit” to UX for the work they do that goes unappreciated.
This post was originally published by John Cutler, Senior Product Manager on Medium. For more on the challenges faced by UX and Product Management, read The Dynamic Duo.