Kill Your Darlings to Let Your Design System Live
To create consistency, sometimes you have to tear everything apart
I first heard the phrase “kill your darlings” in a journalism class in college. In the context of writing, “darlings” are the phrases, paragraphs or even whole chapters that writers are most proud of. That sense of pride can actually be a red flag: when a writer gets attached to a certain piece of writing, they don’t care if it’s actually clear to the reader. When you fall in love with something, it’s hard to see its flaws.
This same principle applies to design systems.
As designers, we often get too attached to designing experiences that align with our individual aesthetic. That might not be a problem for one-off projects but at NerdWallet, we have a design team of 34 people. We’re all working towards a goal of empowering users to make smart financial decisions, but we’re all working on different pieces of the NerdWallet experience. How can we get individual designers to abandon their respective “darlings” and start working within a system?
This problem is one of the reasons NerdWallet spun up a design systems team. (I’m on it, hi! 👋🏼).
When we dove deeper into the root of our inconsistency problem, we realized product designers who are embedded within teams working on different features can easily lose sight of the product as a whole. To solve for this, we hosted a Pattern Party (largely inspired by Brad Frost’s Interface Inventory and Nathan Curtis’ Component Cut-Up workshop, but with a Nerdy twist).
In order to build your design system, you have to see it in its entirety
Yes, we literally captured screenshots and printed as many different pages of our product as possible. This is the most painstaking but necessary part of the process. In order to properly host a Pattern Party, we needed to represent the entire product on paper. It’s important to use screenshots rather than Sketch files (which would’ve been the easier route) so you can get a better idea of any discrepancies that might’ve occurred in the development stage.
Once the screenshots were compiled, we loaded them onto platform-specific artboards — one for native app screenshots, one for web screenshots and one for mobile web screenshots. Then we printed out each 42-inch artboard on our plotter and cut out the screenshots one by one.
(We did this in a room with a record player and only one record — Bon Iver’s For Emma, Forever Ago. It was moody AF.)
Once we had the patterns, we just needed the party. This step involved collecting zig-zag scissors, patterned prizes, and patterned food items. And trying to convince a group of black-and-denim wearing designers to pull out their best patterned attire for the party (we got a lot of fun socks).
Where my party pa-party pa-party people at?
During our pattern party, each group of designers tackled the screenshots of our product across an entire platform (one group for native, one group for web, one group for mobile web). Everyone was given the same instructions: cut components out of the screenshots and group them how you see fit. What’s a “component”? What constituted a “group”? We didn’t define those things — on purpose. We wanted to see what the teams of designers would do naturally, in the interest of seeing the different ways we think about these terms.
It was telling that designers from different feature teams had different names for the same components. For example, designers who worked mostly on mobile formed “cell” groupings while other designers called the same component “rows.” Additionally, some designers pulled out an entire “card” as a component while others broke it up into a header, content and CTA. This made it clear that we need to take a step back further and do the foundational work of defining how we think about patterns, groups and components.
As groups of designers cut patterns and taped their groupings onto the wall, the team began to uncover their “darlings” and how they were at odds with the product as a whole.
Post-party reflections
The most important takeaway from the workshop was that — given the nature of apps and websites — no one had seen the entire product side-by-side all at once. Once we could view it holistically, we spotted an abundance of variants in components that were performing the same function across the product (think: accordions, tooltips, drop-down arrows, etc). As we cut the product apart, these “darlings” became glaringly obvious.
Nobody intended things to be this way! It’s just what happens when designers work toward different product goals and use different building blocks (pre- and post-design system).
With all these variants at play, it became hard to tell what was really *NerdWallet*. In the chaos, we were losing usability, consistency, and brand expression. We don’t want to discourage creativity in general — we just want to encourage using the same components for basic product functions. This has the two-fold benefit of decreasing the work required of our users and letting designers’ creativity shine where it’s needed most.
Now that we’ve done the work of breaking down and grouping our existing patterns, we’ll go through each set to identify the best option within each group. We’ll ask questions like: Which pattern helps users accomplish their goals? Which pattern is the most accessible and inclusive? Which pattern is the most on-brand?
As we answer these questions and identify winning patterns, we’ll graduate them into our design system and craft a plan to update or deprecate old components.
There’s quite a bit of work to be done, but that’s the fun of building out a living design system. Since the pattern party, we’ve seen an increase in designers using existing components, contributing new components, and generally discussing the system as a whole more often.
It’s never fun to kill your darlings — after all, you were so proud of them once! But creating an experience that is clear, consistent, and understandable for our users is something we can all get behind.
Many thanks to Piper Chester and Nat Bolton for helping prep for the Pattern Party, and to Kimra McPherson and Sarah-Beth Zoto for their helpful eyes on this write-up.
