Why being proactive with questions helps avoid last-minute design changes
Team members often don’t pay attention until it’s their turn to work
“I’d like to start the meeting by asking if Engineering has questions for UX,” I said, already knowing the answer.
There were only two possible responses:
No one would respond since my Designs were too far in the future for Engineering
A whole bunch of critical questions would come at once since Engineering started work on the Design
While this phenomenon isn’t horrible in isolation, it often leads to hasty, last-minute changes that hurt the user experience.
To understand why this occurs, you must understand the fundamental difference between how Design and fields like Engineering work.
Design is like sculpting, Engineering is like 3D printing
To explain why Design is fundamentally different, let’s talk about additive and subtractive manufacturing.
Many team members (especially engineers) operate like 3D printers with additive manufacturing. The idea is that you start from nothing and build something, layer by layer.
Engineering, for example, would build a front-end environment and then build a specific feature, piece by piece, according to specifications.
While this approach tends to have less “waste” (i.e., time and resources wasted), it fails to account for the larger picture, consistency, and how things fit together. Engineers rely on others to make those decisions.
This approach doesn’t work for Designers: we can’t design something in isolation. For example, all Engineering might want from a prototype is the “two onboarding screens” we were tasked with building.
However, Designers must consider several additional things, such as:
What is the Homepage, post-onboarding, going to look like?
What does the Homepage look like if the user skips onboarding during the process?
How are users getting to onboarding? Are they clicking a link in the e-mail, and what might that look like?
What critical concepts are we discussing during onboarding, and do we have links to that documentation?
Etc.
Because we’re examining how the feature fits into the larger picture, we’re like sculptors with a block of marble doing subtractive manufacturing. We gather data to carve this block of infinite possibilities into 1 (or more) design solutions to show our team.
However, this often leads to the root of this problem: people are too overwhelmed by their current responsibilities to pay much attention to the upcoming ones.
Current vs upcoming, the most common point of team friction
Because we’re working with essentially two different philosophies, one of the all-too-common clashes you may have is current vs upcoming work. I’ve been in meetings, trying to talk with Engineering about upcoming work and features, only to be met with blank stares and silence.
I get it. When we’re swamped with work, something due four weeks from now might as well not exist.
However, if you can’t address these problems ahead of time, you often get less-than-stellar results because “Engineering needs to build this in two weeks.” I’ve had to completely re-design a product in two weeks because of these last-minute changes.
So, how exactly do you navigate this tricky situation? You can start by aligning with the Product team.
Align with the Product team
These issues often come down to a matter of authority. You might want Engineering to pay attention, but their minds might be elsewhere.
So, get the Product Manager on board. Create a venue to discuss current and upcoming work in detail. You might have to complete visuals or design artifacts slightly earlier to do this, but it can allow for very productive conversations.
However, doing so gets the Product team on board with helpful and constructive conversations. One such conversation may be around the MVP scope of your Design.
By discussing and having the Product Manager decide and consider the design scale early on, Engineering will have to talk with the Product team if they want to make last-minute changes.
To assist with these conversations, use Variants intelligently.
Booleans/Variants: Build and then hide stuff
One of the skills I’ve been learning is adding Boolean properties to existing Figma Variants. Doing this allows me to follow the Design approach of subtractive manufacturing:
Build a future version of a feature page, then, through boolean logic, scale it back.
Creating Variants (and Boolean logic) with components ensures you only have to build something once. If your team is interested in adding additional features in the future, it can be as simple as toggling them on in the Design.
This allows you to adjust your designs to what your team needs.
Designers scout ahead, but your team may not be ready
I’ve worked with Engineers who would ask me nearly identical questions one month after I’d asked them in a meeting.
In that past meeting, they weren’t paying attention or working on something else. However, one month later, when it was their turn to work on this feature, they soon became just as curious as me.
Sorting these things out before a severe time crunch is critical to avoiding last-minute surprises.
Even when Engineering (or other team members) think something looks good at a glance, that doesn’t mean they won’t somehow discover a million different problems (from their point of view) once they start working on it.
After all, that’s what you often encounter as well, when you start digging into previous designs.
Kai Wong is a Senior Product Designer and Creator of the Data and Design newsletter. His course, Data-Informed Design, shows you how to work more efficiently and effectively as a designer by incorporating Data.