Our Design System is a Meeting
A team of designers, even if united in a common purpose, with all the principles and all the good intentions, shall experience entropy. Thus is the universe. Members of a design team are (currently) humans. Humans (currently) are fairly different. Our approaches, backgrounds, and expertise vary, even over a small team of seven designers. To make things even harder, designers at Braintree aren’t on a central team together. We are locally settled into product teams that are cross-functional. We work closely with engineers, PMs, operations, and marketing. Stakeholders abound. This gives us wonderful and deep insight into the products we’re building, strengthens our working relationships with non-designers, and makes collaboration at the product level really easy.
This also makes collaborating with other designers much harder.
It can be difficult for us to transfer knowledge when we are so deeply embedded on our teams, and though we each have a pair that we are working with continuously, it’s harder to quickly get on the same page with other pairs in an hour crit session every week. We are tool-agnostic and process-agnostic, and the nature of our team org gives a lot of autonomy to individual and pair designers.
Entropy
This beautiful design autonomy at Braintree means designers have the freedom to choose our tools and argue about them. It means we have the individual authority to use our design guts to make decisions. This also means we end up making things that look wildly different, and last year, it seemed like this might be getting a little out of hand.
On the Sites team, we’d been working on redesigning our contact form. There were some usability issues we were aiming to correct, and we’d also decided that it needed to look more cohesive with both our developer documentation and our marketing website. This, however, was more challenging than it seemed on the surface. We had wanted to update our form fields which were a slightly updated version of a fairly old pattern that we knew had some usability issues: difficult to differentiate the Label and Placeholder at a glance, hard to target the input with a mouse, etc.
When searching around other Braintree properties for a new pattern to use, it became apparent that we didn’t really have a reliable one.
Some inputs on forms were similar to what we’d already had with the label above the input, some had borders on top and bottom. Some were more ala Google Material Design styled with a single line for the input. Some were dynamic floating labels, some were static. Some newer ones were fully enclosed in a border. Focus states were all over the place, and so were typeface choices, some using our main brand typeface and others using only our secondary with different weights. What should have been a fairly straightforward style update ended up opening the tip of yarn that would unravel a can of iceberg worms.
We, of the design team, knew that things weren’t always the same and that there was some flexibility in what we were implementing, but we didn’t necessarily notice how far off we were wandering from one another. We were shipping features with our teams, and to an extent, everything looked great, albeit very individually great.
We decided a design audit was in order, and that meant we took a bunch of screenshots and dumped them into… Flickr. Remember Flickr? Turns out the tagging system in there was the perfect way to get a state of the union, low bar design audit going. Take searching in our photostream for a component like a button.
Super easy! Super distressing!
Well, it’s really just the colors throwing that off, let’s search by buttons and color. That’ll show we’re pretty consistent.
Narrator: It did not.
Icons? Surely we all use the same basic icons.
?!
The case for consistency
After our problems were laid bare in Flickr, we agreed that, though no official Design Team body exists, we needed to come together to maintain a certain level of consistency amongst our various properties. It was still important for each designer to maintain their autonomy and ability to iterate quickly and try new things, but we also wanted to stop wasting time re-solving problems. Better design solutions could evolve from sharing. As a group, we knew consistency would benefit us and we started by acknowledging its importance:
- Consistency strengthens the brand by underscoring reliability
- Consistency provides a focused experience, reducing cognitive load for users
- Consistency builds user trust
What next?
Where do you begin to pull together so many different things? Some are really easy to align on but also aren’t that important in the grand scheme of user interfaces: border radiuses and shadows are just numbers that can be copied over. Yet, if you have enough of these things together, they also build out much of the basic look and feel. How friendly did we think the interfaces needed to feel? How crisp? What is a Braintree?
It’s hard to talk about this stuff without getting existential and into the brand. Easy to decide what HEX colors the brand is, much, much harder to collectively decide when and how much color to use. How can you consistently reproduce something subjective like spatial sensibility?
Begin the design Align™
We started a weekly 30-minute meeting, dubbed Design Align, to try discussing some of these individual pieces, starting with the less important but easier ones. The first one turned out to be incredibly easy. Border radii. Some were using 2px, some 4px, maybe others with a 1px difference. Most people wanted a little roundness, we felt sharp corners with our slab brand typeface started to feel too cold. We landed on 4px being the most common. Wrote it down in our internal wiki. Job done, high fives all around.
Next, we moved to buttons. This took us a few weeks to crack. There were color issues introduced. When do we use that blue for primary buttons? Isn’t the brand blue a bit intense? What about secondaries? What about the type? We knew the border-radius, but a stroke around them? Shadow? It was immediately more difficult to have this discussion. It became pretty clear how much we’d been siloed in our own decision-making processes and that we needed to share context about these decisions more often.
There were some days the Design Align meeting was smooth as butter, decisions were easy, or rationale made sense for a specific thing, and everyone got on board quickly. We did a quick heatmap user click test for deciding the color/styling of our links and gained some surprising insight that helped us make a solid decision. However, while most of these decisions we worked through and captured (clearly it’s still a bit of a WIP) were difficult and hard-won over a series of meetings, sometimes we’d chase around the same idea after a few weeks; everyone would get so sick of talking about it that we’d just drop it and talk about something else. Sometimes the solution was to agree to disagree for the time being, then come at it from another angle. But little by little, we began to build on that first border radius decision, and slowly, we also began shipping these changes to our properties.
We’re not 100% there, but we’re moving in the right direction, and have made some huge strides in claiming back a feeling of consistency.
There are technical limitations to establishing consistent interfaces and products. Every application that the designers work on uses different and evolving technologies. Copy/pasting CSS styles isn’t an easy option for us, and we also use different design programs, so a strict library is hard to update and share — it’s hard enough keeping the wiki page up-to-date. For the past year, we’ve talked nearly every week, argued and compromised and agreed and the same all over again the next week, yet our most tangible artifacts are the least “designed” things — a Flickr account and a Confluence page.
The discussion was, and remains hard work. Talking is hard. Putting down your ego is hard. Sitting down and making an effort every week is hard. Understanding different viewpoints is hard. Self-motivating an undertaking like this is hard. Those things will not change; a central system with a cool style guide online or shared components will not make any of those things less difficult.
So, What is a design system?
You tell me, person, I have no idea! So much of digital product design is invented or copied over from other disciplines or “modernized” that it’s hard to tell where these ideas originated. (That’s not really true, I just haven’t researched, but I’m not a reporter, and this isn’t journalism.) Perhaps a design system is things like a published style guide or a CSS repo that starts every project, or a set of measurements and guidelines in a big book. It could be a shared library or a massive symbol file, maybe a team that coordinates and deploys new patterns. These things certainly look like design systems, and that’s what comes up if you search or read, but it seems to me that the real design system exists in the ephemeral discussion, not in the artifacts produced. I think I’d define a design system as mostly messy and difficult decision-making — maybe just humans talking. Guess our design system is a meeting*, yours might be, too.
*Hey, that’s the title of this piece!
