Now that I’ve been at Red Hat for nearly 5 years, I’ve built a lot of relationships with teams and individuals across the organization. As a UX leader in an organization, once you have established these relationships and educated those around you with what UX can achieve, the inevitable next problem is prioritization of all the incoming requests that suddenly start to appear.
The most common designer prioritization mistakes
Priority by interest
I’ve seen many designers default to this. They find things that are best defined, and seem most interesting, to spend their time on because they feel more effective doing this, and there is the most immediate reward (I enjoy it, I see quick results, people see my design prowess quickly, I add to my portfolio, etc.).
The problem with this strategy is that over time, you’ll start to realize that most of the time, following this strategy means that you are having the least impact on the organization or product. These projects usually fall into two main categories:
- Projects that are well defined because they are small and aren’t challenging the limits of what we can offer our users. They often don’t result in great work or change. “Oh, I’ll just keep working on these icons until someone can tell me what that next version of the product really is supposed to be, then I’ll work on designing it.” No! Go talk to people and use design to suss out the possibilities of what the next version of that product could be – it will further your career far more than those extra icons in your portfolio will!
- Projects that are interesting from a designers point of view because they allow for creative freedom through visualization as they are described, but as they are described usually doesn’t consider reality, and they often result in designs that never are fully implemented because they didn’t have the right support behind them.
Priority by the loudest/most connected person
This can be a hard one to handle. The loudest voice, or the most connected voice, sometimes seems to appear to “win” in the priority argument just so that you can get that monkey off of your back. These can be some of the most unhealthy projects for UX teams as team members recognize that they’re working on something that doesn’t matter in grand scheme of UX work for the company, and get frustrated or despondent about their work. Sometimes these are unavoidable, but by building out a regular review system as described below, you can ensure that these projects are a rare exception rather than the norm.
Building a better priority system
Identify a board of reviewers
Find the stakeholders that matter in your organization. Build a way to talk to them about priorities. As a UX design lead, this has almost never been just my manager as the only stakeholder involved to determine my priorities. It often involves someone from Product Management, Engineering Management, UX Management, and maybe other key stakeholders.
Establish a cadence of status and project review
Determine a cadence you can meet with those stakeholders, and figure out a way to report out your continuous status to this group inside and outside of those meetings. At Red Hat, we began establishing UX Status dashboards to help show the projects and their status. We recognized that sometimes UX “priority” is not equivalent to company “priority”. Some products might have high visibility user experience work that is higher priority for UX than the product that makes the most revenue, or has the most focus for future viability in the market. Having these in depth discussions about why a project might be high priority for UX when it is lower priority from a business standpoint are the key types of discussions you want from these sessions.
After running these sessions for about a year, we have refined the dashboards and had much richer conversations with our stakeholders. These conversations have led to more funding for UX as well as a deeper understanding from the key stakeholders across the organization about what UX can offer, how it will impact their goals, and how we do our work in relationship with their teams.
1 comment for “UX Project Prioritization”