Aligning Interests Between Design and Engineering
I’ve just come out of a quick meeting with our design team, the agenda: Styles or Symbols? We’ve thus far been using nested Symbols for things like “easily change the background colour for a button” or “easily switch which corner the tether is for a popover.” For some of those (changing the colour of a button), we can now use Styles. The question is: should we?
There are many different arguments to be made for either options, but they all boil down to: how flexible do we want our toolbox to be?
Surely the answer is “very flexible”? Surely.
What if we think about the fact that while the polar opposite of “flexible” can be “inflexible” or it could also be phrased as “easily consistent”?
Consistency aids Clarity
Our design team have 4 values, which we use to determine the quality of our work. In order, they are “Be Clear”, “Be True”, “Be Friendly” and finally, “Be Bold”. Clarity is the most important thing, and sometimes we need to be flexible in how we use our pattern library to deliver “clarity” but more often than not, clarity is delivered by remaining “true” and consistent. It’s clear what this does because something that looks like this always does the same thing. There will be exceptions—and clarity trumps consistency because when things need to change to be clear, things need to change (and often that means our pattern library needs to evolve and adapt.)
But these are exceptions. And these exceptions come with real costs.
Exceptions and changes come with real engineering costs
Specifically, anytime we make an exception, there’s a real Engineering cost—both to implement and to maintain this exception. We increase risks that updates will clash with this exception and thus we’ll introduce bugs and lower the quality of our software over time. These exceptions must be well-earned, and well-thought-through.
We should try to avoid exceptions if at all possible. And to minimise the above risks, when an exception is made, we should try instead to develop our pattern library to be able to handle this new scenario. That also comes at a cost.
Designers should feel those costs
And so when we talk about Symbols vs Styles, I don’t think of “how flexible do we want our designers’ toolset to be”, I think of “how will this change impact the small incentives or disincentives that our designers have everyday and will that increase or harm alignment with our Engineering partners?”
Our outcome? We will continue to use Symbols when we are designing for the application, but when we develop for our pattern library, we’ll use styles. The important friction we want to maintain is “Oh, this will require changing the pattern library”. We’ll also use Text Styles when designing for the app, as this will increase alignment with Engineering (and make us more efficient) because the options presented are much more limited than having to remember and implement Text Styles from scratch every time.
I’m glad that as a design team, our conversations and tooling decisions consider the impacts on other teams and how these decisions can increase our empathy with how our decisions will impact other teams.
Does your design team think about that?
We’re hiring for a bunch of Engineers at Vend right now. If you’d like to work with a pretty good Product Design team, who also think about the impact on you (as an Engineer) when they make all kinds of decisions, then apply for a role with us. We’d love to have you.
