How to ensure design changes get made when Engineering is overloaded
You don’t have to feel awful requesting design changes from a busy engineer
"Yeah, I'll get around to those design changes when I can, but I'm looking at 8 hours of coding today." An overworked Engineer told me, and it wasn't the first time.
Sometimes, it's not just you that's juggling a full workload. It's also the Engineering team.
I've been in standups where Engineers said they'd be around in the afternoon (after napping in the office) because they were up all night doing security/bug fixes.
Adding extra design work, like fixing design issues, feels particularly awful in these cases. However, not pushing for these design changes means a bad experience for the end user.
Although your Engineers mean well, they may be dragged from product to product, and if you don't tackle the issue immediately, it may result in a bad interface.
What do you do in these cases? You first start by learning to prioritize work.
The importance of priority and compromise
Working as a UX team of One, I've learned that to be successful, you need to prioritize.
You might have 30 design changes, doing a heuristic evaluation, that you'd like Engineering to make.
However, if you demand, "All 30 of these changes are top priority, and they must get done immediately," your work often becomes a low priority.
Why? Because it's taking the "All or Nothing" approach.
If you're unwilling to concede an inch (i.e., thinking of UX in a vacuum), then Product Managers and Engineers must allocate appropriate time to tackle that.
You know when that occurs? After all the pressing stuff is done.
After all the fires have been put out and the Minimum Viable Product (MVP) has been released, your Engineer might have time to make design changes.
Or, some executive might see, "Hey, this guy's free," and drag your Engineer elsewhere, meaning your design changes never get done.
So, we must learn to prioritize. To do this, we can use a prioritization tool like RICE.
Rice: an estimation tool to help designers understand the priority
PMs often use RICE as a Product Management tool to prioritize the backlog.
UX doesn't need to do that but can use RICE to answer a single question:
What would be a top priority if you had to prioritize an issue based on four specific criteria?
Using RICE can give insight into how product managers think and give greater insight into what the team might find top priority.
I've explained RICE in detail, but here is a quick summary. RICE consists of 4 categories:
Reach: How many users are likely to be affected by this problem?
Impact: How severe is this problem?
Confidence: How much evidence do you have of Reach and Impact?
Effort: How long will this effort take?
Each category can then be quantified and put into further buckets. So, for example, Reach would either be :
A lot of users will be affected by this problem (4 pts)
Some users will be affected by this problem (2 pts)
A few people will be affected by this problem (1 pt)
You then prioritize based on the following formula:
As a result, you can get a list of numerically sorted priorities:
RICE score (8) Ensure the user advances automatically when clicking "Save" ((4 * 2 * .5) / .5)
RICE score (4) Fix the dark-mode versions of buttons ((2 * 2 * .5) / .5)
RICE score (2) Align headers and spacing of title and subtitle ((4 * .5 * .5) / .5)
Are these the exact numbers that Product Managers would use? Probably not. But by thinking about priority helps you do two things:
You think about 'priority' from a different viewpoint than UX
You make it easy for Product Managers to approve these changes (since you've done a draft of their work)
The second point is critical, as Product Managers will likely be one of the key allies in ensuring these design changes get made.
If you tell Engineers to make specific design changes, it may or may not happen. But if it comes from the Product Manager instead, even the overworked Engineer will listen and try to accomplish it.
That's especially the case if you say, "Hey, while there's a total of 30 possible design changes, these 6 are the most important to have a functional MVP".
The only other thing you need to do is make it as easy as possible to understand what to change.
Context, or showcasing the exact issue
There are a few different ways to show context around the design issue, often depending on how your Engineer works.
I can't speak for all Engineers, but the ones I've talked to often "overload tasks with UX."
I've heard several Engineers say, "Hey, I'm fixing the search filters on the backend today, and I remember there was a UX issue with them as well. Let me fix the search filter issue while I'm at it."
In other words, the idea is to make it convenient and accessible for users to find specific UX issues while working on something. As a result, I often rely on JIRA tickets (or other ticketing software) to form a backlog.
A ticket like "UX issues on the Search page " allows the Engineer to pull up the ticket and look for issues to tackle while working on whatever they need to do.
If you have Engineers who instead say, "Today, I'm going to tackle some UX debt as a whole," annotating your designs may work better.
Whether it's documentation in a Figma file, screenshots and stickies in Figjam, or something else, the idea is to showcase a list of problems to fix across the entire design that the Engineer can tackle.
In any case, this is how you can bring up UX work that needs to be done even if your Engineers are struggling.
While it's not great, it doesn't have to suck to fight for users
When everyone's stretched thin, it can feel awful to be the one to add more work.
We've all been there: you’re busy with a full workload, and a PM drops by and asks you to do even more work. It sucks to be the one doing that to Engineers, especially if they're struggling.
But, consider the alternative.
Alternatively, you give the Engineer a pass, release subpar designs, and then hundreds, thousands, or even millions of users struggle with a bad interface with glaring usability problems.
There will always be time and work constraints, but you are the one who needs to take a stand and ensure that what you designed is what gets built.
And who knows? Sometimes, that thing you thought would require considerable effort is something engineers can do in 10 minutes.
It doesn't hurt to ask engineers and make it as easy as possible for them to do so.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. He teaches a course, Data-Informed Design, on becoming a more effective designer using the power of Data.