We’re wrapping up 2018 and at many companies UX design is still a black hole where magic happens. This can lead to several problems, so this is a perfect area for DesignOps to assist in helping with tools and processes.
If you don’t track UX work, then you may run into these issues:
- You lose visibility into what everyone is working on
- Without visibility you lose the power to estimate your work and plan around those estimates
- Without estimates it gets difficult to plan development sprints and launch dates
- Without estimates others will set timelines for you that are less than ideal
- Product managers and developers are already tracking everything in JIRA, so you start to be the odd one out
- Sometimes designers flat out don’t know what they’re supposed to do coming into work on Monday and what the priorities are
Whether you have a dedicated DesignOps team, or you just have a knack for making the lives easier for your design team, tracking UX work is a problem worth solving. We’ll take a look at one of many ways to solve this.
Use JIRA to Track UX Work
I just used the “J” word, so bear with me while I try to salvage this. If your development team is using JIRA (like most are) and your product team is creating epics and stories in JIRA, then what a great place to tie in as a design team. You may be using more designer friendly task tools such as Trello or Asana, and you still can, but I would also take a look at just using JIRA.
There are a million different ways to set this up in JIRA and it will largely depend on how your organization has set up JIRA, but we’ll cover some common themes that I have used.
Use a Separate Project for UX
One setup that has worked out over and over for me is to keep UX work on a separate project. In JIRA there are projects and projects can have different boards. Having a separate project allows you to fully own it without interference from other teams. Another great advantage is you can size your design tasks without affecting the velocity of development teams.
Create Columns That Work for Design
To make things as simple as possible for designers you should at most have three or four columns that align with their process. I typically use backlog, to do, in progress, and done. This allows each designer to see what they have in the backlog, what’s lined up to do for the week, what they’re currently working on, and what’s done.
Epic, Story, Task?
What type you use for your design tasks will vary on the organization and there are no hard-set rules. Where I currently work, we moved towards everything in our project being tasks. The reason why we set it up this way is because as an organization we decided that using tasks for designs made it more understandable compared to stories for development. Whether that makes sense or not it really doesn’t matter. The only thing that matters is that everyone knows how to use them.
How Does This Align with Product and Engineering?
We aligned our tasks with stories that a product manager creates. On our end we know there is a design need from the product team, so we create a task in our project. We then link the new task to the story from product and select “is depended on by.” This creates a relationship where when anyone opens up that story, they see that moving forward with the story depends on that design task being done. It will even show what step that design task is in such as “In Progress.”
Sizing a Task
Sizing items by complexity has been a popular method of engineering teams. However, let’s go through how well this works with design in this scenario.
Product Manager: we have a sprint starting on the 25th, will you have the designs ready for the feature?
Designer: well, for complexity I sized it at a 13.
Product Manager: so… will we have everything we need for the engineering team prior to the 25th?
Designer: it may or may not be.
As designers we often can’t estimate how long tasks will take us based off of complexity since we don’t measure velocity and not to mention our path of creation varies greatly from engineering teams.
Working in a different project allows us to change how we “point” our tasks. The method I found to work the best is to just use days. I don’t mean tracking every minute and hour against a task, but instead use it in terms of normal working days. Designers should be able to easily size their different tasks and be relatively close. How long will it take you to create the notification feature? Well… I would say 3 days is a good estimate for ideation, and then 2 to mock it up and prototype it, and then 2 days to write a testing script and test with a few users. This gets us close enough and is acceptable.
Bringing It All Together
As a design leader I work with the product teams to ensure we were keeping our backlog filled with items that need design work. A good habit is end of day Friday or first thing Monday morning you should meet with your design teams and go over your project boards. Here’s what I would cover:
- Is there anything we didn’t close out from last week? Do we need more time, is there a blocker, or did we just forget?
- There’s 5 days in the week, so we can pull in 5 points worth of tasks. What are we pulling in?
- Is there anywhere we are hurting and need to redirect design resources to meet a deadline?
By the end of the meeting everyone knows what they are doing for the week and what they’re delivering. This is more of an efficiency process, but when I’ve ran this in the past, I’ve been pretty surprised at how much the designers liked the process. They knew that when they came in Monday morning, they had clear expectations for the week.
Another great benefit is that we can now have realistic conversations with product and engineering teams. How many times has a product manager asked you if they could have a large feature in a small amount of time? Now you can break out your process and create a task for the different steps it would take to achieve a good design.
If your timeline does not match a team’s schedule, then you can now have the conversation around how much of a priority is their feature compared to others? Do you have bandwidth to pull from a different area, or does someone else’s work have to be reprioritized? On my JIRA boards I have an instant snapshot of what every designer is doing, how long it will take them, whether or not there’s bandwidth in different areas, or if a designer is buried in work and needs some relief.
There are many ways to track UX work, but this is one worth exploring. From the perspective of DesignOps this helps align tools, achieve better efficiency, and helps out both the design team and the organization. This type of setup brings more visibility into UX and creates a better understanding of what designers do.