I was in a 1:1 with one of my frontend engineers.
We were close to launching a new feature at a time our startup was humming along, shipping software many times every day as we rapidly developed a new product.
“I want to ship this, but Marcus (our designer) sent me a bunch of stuff to fix. These redlines are like a pixel here and a pixel there. Half of these things are just on Safari and just at this specific screen size.”
“Wait. Redlines?”
“Yeah. He took a screenshot of the staging site and overlaid his original design over it and highlighted in red all the stuff that was slightly off.”
Before things got to this point, I’d fielded grumbling from Marcus about his designs not being translated faithfully in production, and I’d included his feedback in our acceptance testing cycle … and then we hit this wall.
We eventually worked our way through this, by resetting things to the larger context and goal we were after, and settling on a ship-and-fix cadence that we actually delivered on (a rarity I’ve heard from design friends).
But, I had a chat with a design friend recently – who also joked about the rarity of that ship-and-fix agreement being held up – that helped me figure out what was going on there and reinforced how I think about working with designers.
In design school, designers are taught that design will save the world. They’re not entirely wrong from an everything-around-you-has-been-touched-by-the-hands-of-a-designer perspective.
They’ve also been in an environment that involves cutthroat, brutal feedback from one another.
Your work is the most important work in the world, and it needs to be _perfect_ or you’ll get roasted by other designers – and probably yourself.
A key part of the experience literally is critiquing sessions – where other design students and the instructor rip apart your work in front of you, like a more vicious, nitpicky code review.
Then they come out of this perfection-seeking environment and land in the world of software.
A world of infinite screen sizes, fuzzy requirements, strongly held opinions, and ever-shifting platforms.
And they have to interact with software developers who work in a world of mess, and bugs, and imperfections everywhere. A world where it’s lucky that anything works at all.
We cut corners, accrue debt and live in a swamp of broken things.
We don’t know perfect. Nothing’s perfect.
The clash of this honed perfectionism and learned imperfection is at the core of the interaction we started with.
Designers – over time, sometimes – can soften from this, but it never really goes away.
Here are some tips:
- Acknowledge the importance of design. There are engineers and engineering leaders who react to design as a nuisance, an impediment. It’s a step to “make things look pretty.” The thing is, all software is _designed_ by somebody. I’ve seen enough engineering-designed software to greatly appreciate and prefer the design of, well, designers. They make our software more usable, more delightful and plain _better_. Let them know that! Many of them have come from an environment lacking in validation for their work.
- If you’re going to do a ship-and-fix, follow through. Our goal at that long ago startup was to ship software as quickly as possible so we could figure out if it solved a customer pain – if anyone would use it at all. In that context, getting features out of our brains and into the hands of customers as fast as possible served the business best. Reframing our process in that lens allowed us to compromise on a plan that could accomplish that goal and still deliver a solid design. When you make this sort of compromise with anyone, you need to follow through with the commitment.
- Componentized design. One way we eventually got through this impasse was working together on a design system – components and lego blocks of a sort that we could plug in to rapidly iterate on new product ideas. It might take some work to get everybody aligned, but getting things standardized will also make designers’ lives better once you’re through.
- Return to the point. At the end of the day, you’re often acting as a mediator between a perfectionist and a pragmatist or even a defeatist. Things can devolve into passive aggression, points scoring, redlining, and grumbling unless you can pull both sides out of the gutter and get everyone aligned on a common, agreed goal. Get folks to focus on the problem to be solved, and a lot of personal squabbles tend to fade.
One final story to leave you with.
That startup I mentioned earlier got better over time with matching design to finished product after a lot of ship-and-fix cycles – and a lot of up front negotiation that we can talk about some other day.
When that startup got acquired, after a short period there was a project to align all the acquired companies in the portfolio to a common navigation, colors, fonts and the like.
There was a lengthy design document – too lengthy, really – that each team was handed with how things should work and look.
Only one team nailed the design – even with so thorough documentation and specs.
It was mine.