What to do when your UX team is spread too thin
“There are far more features and teams to support than there are designers to support them.”
Sound familiar? Overextended design teams often selflessly soldier on and cover as many projects as possible, thinking it’s better to give projects some support than to give them no support. After all, imagine what kind of awful things might happen without UX input!
Obviously, there are many problems with spreading your team too thin:
- individuals must constantly switch contexts, giving each project a small and distracted slice of their cognitive power
- team members can burn out due to overwork and low job satisfaction, exacerbating your problem
- ALL of the work suffers — even the most critical work will not be your best work
Another issue that is commonly overlooked makes the problem even worse.
I (don’t) feel your pain
Too often, the product organization never feels the pain of an overloaded UX team for one simple reason — they keep getting support! Their design needs are satisfied so where’s the problem? Teams might wish the work was completed a little faster or the designs were a little better, but those are relatively small costs to bear. It’s just not enough pain to justify headcount, which is exactly what you need. Instead of hiring designers they can hire more engineers to build more features! Besides, the design team always seems to make it work so, again, where’s the problem?
Make the pain felt by saying “no”
When making the case for headcount, soft arguments just don’t work, so I’m here to suggest that no support is better than some (i.e. too little). You need the product organization to feel the pain of a team that is understaffed so that you can convincingly argue for more headcount. Don’t bother with arguments like “the team is working too hard” or “we can’t craft beautiful experiences”. It’s too subtle. Instead, say “no” to a lot of stuff. When support is removed, the pain is felt and securing headcount is much more likely. But be aware that this path is not easy and teams will likely be upset. After all, no one likes being in pain.
Have a framework for when and why to say “yes”
While you’re busy saying “no”, it is critically important to say “yes” to the right things and to knock those things out of the park with the best work your team can produce. Choosing what to say yes to will require a solid understanding of company priorities as well as the relative priority of each project the product organization is undertaking. Additionally, UI complexity and user experience impact of each project need to be factored into your decision making process so that you are maximizing the value of your team against the highest priorities.
Support unsupported teams… a little
No one wants to leave their product teams high and dry and there are some things you can do to help ease (but not remove) the pain.
In a mature organization most projects are incremental and can lean on established design patterns. Point teams to the existing patterns that best fit the problems they are trying to solve.
Hosting office hours for a couple of hours a couple times a week allows product teams to get needed UX guidance while minimizing context switching and overextension for your team. Make sure your team leaves office hours without any homework! Their support should be limited to the office hours timeslot.
For the projects your team is fully supporting, be sure that the work is contributing to a design system. The design system will allow you to scale across more teams with higher quality and will help alleviate resourcing challenges over the long term by giving product teams assets that help them do the right thing with less UX intervention.
Better work AND more headcount
If you say “no” to something because your team is fully occupied, delivering great work on the highest priority projects, few will object. From there it’s reasonable and logical to argue that supporting more projects requires more headcount. When those new headcount are added, the same criteria will apply — high priority, high impact projects are supported first. In turn, your team can focus and deliver their best work on the projects that matter most.
