3 common mistakes that cause last minute design blowups
You’ve meticulously crafted the perfect design. You’ve thought through every workflow, interaction, and pixel. You’re three days away from shipping your work and the CEO (or your product manager) says:
This is great. But I think we need to be a lot more transformative. Let’s reimagine this interface as if we’re helping orcas find and hunt baby seals in the North Atlantic.
Three days is definitely not enough time to deal with all the design implications of this change and you’re about to be savaged like a tiny, plump seal in icy waters.
Last minute blow ups and misalignment are huge stressors for us as designers.
It’s our job to figure out the workflows, interactions, and visual interfaces that engineers will build. So if there’s a late stage blow up, it’s our credibility that gets undermined. We’re ultimately responsible for delivering something that is coherent, aligned, and ready for development.
So what can we do to prevent this all too common issue?
Figure out where the missiles will come from
Before designing anything you need to figure out who has the power to support or blow up your work.
Who will be building this thing? Who is your main business stakeholder (product manager/owner/CEO)? What other teams or individuals will be affected by your work (marketing, content, legal)?
If you want to make your life a lot less painful, split these folks into three categories in decreasing order of engagement: inclusion, alignment, and awareness.
What do I mean by engagement? There are certain people who need to be actively included in your decision making process. You cannot agree to disagree with them. They need to be bought in and approve of the direction you’re taking. There are others you can just make aware of your decisions. You don’t need their approval or agreement.
Typically your inclusion group would feature the core product team. Your engineers, designers, PMs, and data scientists.
Your alignment group might feature people whose input can help you succeed but who you don’t need approval from to proceed. Subject matter experts, customer support, and sales are all examples.
And your awareness group would feature individuals on cross-functional teams as well as senior executives.
You should actually write this list down somewhere. Performing this exercise will help you on multiple levels:
- You can stop going in circles trying to design by committee because it’s clear who needs to be convinced and who needs to simply be informed.
- You can still gather lots of wide ranging input because you’ve explicitly thought about who would be useful to consult.
- And you figure out who needs to be kept in the loop so they don’t nuke your work at the last minute.
Once you've done this, you'll have clarity around where a blow up might arise. But how can you reduce the frequency and magnitude of these conflagrations?
An ounce of prevention is worth a pound of cure. Especially when it comes to radiation poisoning from being nuked.
Set a north star
If the nuclear apocalypse hit and Google Maps stopped working, how would you find your friends and family? You’d probably use landmarks to head in roughly the right direction. Or a paper map if you thought ahead. The best approach? Use a paper map and compass to head to a prearranged meeting point.
So when your designs get nuked part way through a sprint, what should you do? The same thing.
Now that you have a clear sense of who you need to get bought in, you can work with your PM to figure out the business value, strategic fit, and user problems you’re trying to address with this feature.
It’s possible that your PM will put this together for you. It’s also possible that they won’t, in which case you it's up to you to elicit or generate answers to these questions yourself.
When you have a solid draft together, you should review this north star with the rest of your inclusion group. Once you internally approve of it, you should share it with folks in your awareness and alignment groups.
If you don’t all agree on what you’re trying to accomplish and why, how are you ever going to agree on a design direction?
What you’re doing here is reducing both the likelihood and magnitude of a blowup. If there is disagreement, you’ll all still be pulling in roughly the same direction.
During this initial product review engineering will likely ask what you’ve done to validate your assumptions. Be ready to speak to that and negotiate with them over what level of evidence they need to feel comfortable building a solution of this type.
Another issue that manifests at this phase of work is under specification. Your PM or CEO has a specific vision for how we might solve this problem and writes a set of requirements to solve the user problems you’ve settled on. Two major problems can arise here:
- The product vision has conflicts and negative implications that cannot be noticed in the abstract.
- The product vision is perfect but features a lot of nuance and detail that is implied but not perfectly captured by the requirements.
Wireframes might be a little out of fashion these days, but it’s hard to specify requirements for a visual interface without a visual representation. Work with your PM or CEO to represent their ideas visually as early as you can so you can all understand concretely where the issues, nuances, and opportunities are for this feature. If you want to create low-fi designs like we did in the days of old, go for it. If you want to skip ahead and use design system components to rapidly throw something together, feel free to do that too, you degenerate youth.
Okay, so we have clarity on where blow-ups might come from and how we might reduce the magnitude/frequency of them. What we don’t know is when a blow-up may arise. Luckily there’s a simple solution.
Build an early warning system
You want to know when the missiles are in the air. Ideally, you want to know before a working nuke has even been constructed. How can you accomplish that? By gathering intel.
You have a working list of people who can help your work succeed or can sink it. You need to reach out to them and check in frequently to watch for misalignment.
Why do you need to reach out? Why not just share a video or post an update somewhere?
Because sometimes people are too busy to dig in and really understand the status of your work. Especially people who have the organizational power to tank your work.
What does frequently mean here? I would say almost daily with your inclusion group, weekly with your alignment group, and somewhere between weekly and bi-weekly with your awareness group. These don’t have to be long check-ins and they don’t all have to be synchronous. But you’ll want to ratchet up the intensiveness of your check-ins if you detect something is off. If you ping your engineers a design and their response is shock and horror because they expected something completely different, it’s time to talk about it synchronously.
Again, this is something that your PM can and should also be thinking about. If you have a PM that takes all this on, that’s great. You still may want to check in with your various stakeholders yourself from time to time as a safeguard. And definitely check in with the PM frequently.
If you have a PM that is not doing this stuff, you can’t throw up your hands. You have to take it on. Because push comes to shove, you’re the one telling engineering to build this interface that looks and works a certain way. It’s your job to make sure that interface is aligned and ready to go. It’s not an easy job, but it’s an important one.
Nuclear non-proliferation for designers
So there you have it. A three step plan for preventing one of the most nefarious and painful occurrences in the life of designers (and developers): The late stage blow-up.
- Map your stakeholders so you understand who can support or tank your work
- Set a north star so disagreement is fruitful and not counterproductive
- Build an early warning system by checking in with your stakeholders frequently
If you found this advice helpful, sign up. I write and think a lot about psychology, influence, and managing weird interpersonal dynamics as a designer. Honestly, most of what we do as designers is navigating a maze of bizarre psychological dynamics. Let’s get better at it so we can help more people and become more valuable in the process.