Don’t Bring a Paintbrush to a Gunfight
Supporting your design choices with more than design language
--
And so the story goes,
PM/Eng/CEO: I think you should change the designs.
Designer: But that will increase the cognitive load.
Designer: And that is less approachable.
Designer: And that will create a paradox of choice.
Designer: [insert other design-y arguments]
PM/Eng/CEO: 😐 I think you should change the designs.
The problem
You show up to a design review equipped with a paintbrush as your communication tool—but you’re facing a room full of guns.
When people attempt to communicate in different languages, it’s never effective. You’ll explain things multiple times, in multiple ways, but still struggle to get your message across. The underlying issue is that no matter how you say it, you’re still fundamentally speaking a different language.
Similarly, unless you’re conversing with a fellow designer, it probably isn’t super effective to communicate in esoteric design language. I know, using fancy design jargon will make you appear smart—but do you want to look smart or be effective? What good is it to be the smart person that nobody listens to?
Nobody gives a shit about your paintbrush.
This is your problem, not theirs.
If you need to communicate with someone who doesn’t speak your language, that is your problem, not theirs. As designers, we can’t expect the people we work with to learn our language.
Don’t get me wrong, I totally empathize with the feeling of passionately pitching a design you whole-heartedly know is right, and it’s not resonating or getting through to your coworker. It’s a shitty feeling and a quick way to get your blood boiling. But—at the end of the day, it’s your problem to solve.
The solution—speak their language
The simple solution here is to speak the same language. But of course, this is easier said than done. Learning a new language can be a daunting task, especially when you need to learn many of them. The language of a PM, Engineer, Marketer, and CEO all have their own intricacies. This is how I recommend approaching it…
Focus on the language you need to learn. Need to communicate with a PM? Their language is based in metrics, timelines, and project scope. Engineers? It’s all about technical capabilities, effort assessments, and product performance. Your CEO? Frame your design pitches around business impact.
Once you identify what embodies a particular language, you just need to start speaking it. Hold yourself accountable to doing it. After each design review, ask yourself if you spoke a different language than your own.
Enough with the metaphor…
Ok, ok. Let’s look at a couple of real examples we experienced at Shyp.
Story 1: Too much cognitive load
Defending a design decision by saying “it reduces cognitive load” makes sense for designers, but will surely be written off as design bullshit by many others. This, unfortunately, was the exact justification our team used when attempting to reduce the complexity of a recipient search component in our app. The PM was quick to ask why this was worth changing. He wasn’t buying it.
So, we started speaking his language. We rolled up our sleeves in Mixpanel and found that our users were spending an average of 25 seconds on this search step. 25 seconds for a simple task. That’s insane. Further, 65% were using the fallback way to get through the flow. We said it in a way the PM could understand.
Story 2: Building style guides
The Shyp Design Team has put a ton of effort into creating and managing style guides for each of our 5 products. These style guides have become deeply important on many levels—they allow us to design faster and more consistently. But having the styles in design files is only half the battle. The patterns and components should be built in code to mirror the style guides.
The problem we faced was justifying the effort required to implement these style guides with our engineering team. We could have pitched the importance of consistent visuals throughout our products or how this will ensure being “pixel perfect”. But for someone who may not understand the value in those things, it’s not a great rationale.
Instead, we pitched the effort investment as exactly that— an investment. We invest engineering effort up front, and it’ll pay back ten times over as it reduces repetitive, tedious engineer work later. For instance, when a component style changes in the future, you can update it in a single place, instead of finding it everywhere throughout the product and rebuilding it many times. It’s an easy conversation when you frame things in engineering effort and time saved.
Consider this a rallying cry for designers to continue earning your seat at the table. Ditch your paintbrush, and bring your gun. Without it, you’ll find yourself clawing at the door on the way out—wondering why people stopped caring about the things you had to say.
Hit me on Twitter or follow the Shyp Design publication for more thoughts from our design team.
