Ask Zhippy: Design System Advice Issue #2

Zhippy’s back with another installment of design system advice! If you have a design system question and yearn for Zhippy’s advice, message Zhippy with this form.

Winning engineers over

Dear Zhippy,

I love zeroheight, and it’s been amazing for our design system team! But I’m struggling with getting other engineering teams to use it. They use Storybook, and we have Storybook embedded in our zeroheight styleguide. But the engineers push back and say, “Well, I use Storybook already. What’s the point of going to zeroheight?” What should I tell them to convince them otherwise?

Help,

Frustrated Designer

Dear Frustrated Designer,

We feel your pain! This is a common challenge for design system teams. And we understand that using new tools or changing day-to-day routines can feel difficult and take time. When teams use zeroheight to document their design system, they aren’t asking people to stop using the tools they need to do their work. Instead, tools like zeroheight bridge communication between those tools and their users. Figma is primarily a designer’s world, so it can feel weird for engineers to be in it (even with DevMode). Likewise, Storybook is mainly an engineer’s tool, and being in that can give designers the heebie-jeebies. zeroheight connects those tools and serves as a common ground where everyone can meet. 

Its value might not be apparent to people unfamiliar with leveraging design system documentation. So here’s what we often tell skeptics:

• zeroheight serves as that “single source of truth.” People can quickly reference it and know the proper components, files, stories, etc., to use from their system. So no one has to question if the random Figma file or Storybook story is what they should use.
• Documentation provides usage guidelines on when and how to use design system elements. For example, an engineer is coding a feature and notices the button group order is different than usual. Rather than contacting the designer, they can visit the documentation to see if the guideline has changed or if this is a possible error. This is a great way to find answers without waiting for people to reply. We’ve known engineers to reference usage guidelines to suggest better or more feasible ways to implement things into the product. Looking up the usage guidelines provides confidence in proposing potential solutions.
• Reference documentation when noticing differences. Sometimes designs and code can fall out of alignment, especially when your teams are moving fast. Suppose an engineer is coding something, and the component they’re pulling in looks slightly different from the provided designs. In that case, they can reference the documentation to see what might be going on. It could be an error in the design file, the coded library needs updating, or a new component must be created and added to the design system. 

It’s important for people consuming the design system to know the ask isn’t to read the design system documentation from cover to cover (although that would be nice). Instead, they should frequently reference it when they need definitive information. Like Wikipedia, most of us aren’t reading it cover to cover; we reference it when we need to know more about a topic. 

If you’re still struggling, we recommend finding a few engineers who are allies that can advocate for it and demonstrate how they’re using it. When respected engineers lead by example, that can help motivate others.

Good luck and we hope this helps!

–Zhippy

Figma File Organization

Hi Zhippy,

My teammates can’t decide what’s the best way to organize our design system Figma files. They’re getting too big and are becoming difficult to open and work with. We are a large enterprise company with multiple products that are mostly consistent in their UI. They share the same colors, some of the same components, but different products definitely have unique components. Should we organize files by product? Should we organize by type of component – e.g., all form elements in one file? We’ve even seen some places that create a Figma file for each component – e.g., one file for buttons and another for dropdowns. Is that something we should try?

Thanks,

Organizationally Challenged

Dear Organizationally Challenged,

This is an excellent question that our design advocates often hear about. For larger companies that have multiple brands, we usually recommend the following:

• Define a “base” design system containing the most common components all products share. (Think of Google’s Material 3) Create a “base” Figma file.
• For each product or product group, create a minor design system that contains components for that product or product group. Think of a product group as a suite of similar products (like the Google Workspace apps – Docs, Sheets, etc.) that have standard components for that group but aren’t common enough to live in the base. Create a Figma file for each product or product group. Sometimes a product is so different that it might need its own component library. (For example, Google Maps is very different from all of Google’s products.)

You can still create styles for colors, type, etc., in your base file and pull them into components for your other, more specific design systems. This will ensure consistency and avoid rework.

We don’t recommend organizing by component groupings like form elements, etc. This requires designers to remember how they must think about elements, and they can inadvertently pull a button from Product C when they’re designing for Product A. If component libraries are organized by base, product group, and product, it’s much easier for people to find what they need and stay focused.

Similarly, we don’t recommend creating individual Figma files for each component. We just think that it’s brutal to maintain over time. And you might get dizzy opening and closing all those files! 😉

Happy organizing,

Zhippy

Design System Deep Cuts

Hey Zhippy,

Hope you’re having a great summer! I need some design system inspo. I’m tired of looking at Carbon, Material, Lightning, Polaris, and Atlassian. I keep looking for other sites, but of all the apps I love, they don’t seem to have a public design system. (OMG, teams, please make your design systems public!!) Do you have any recommendations for some other well-documented design system sites? Deep cuts are appreciated!!

Thx,

Jaded

Dear Jaded,

I love those design systems, but I totally hear you. You can only browse those systems so much. I agree, I wish more companies would make their design systems public, but they might have reasons for keeping them private. I asked my teammates what other design systems they reference for inspiration, and here’s what we’ve come up with:

• Uber’s Base
• REI’s Cedar (newly redesigned!!)
• News UK’s NewsKit
• GitLab’s Pajamas
• The zeroheight showcase – I’d be remiss if I didn’t mention some great examples from our customers!

If there’s something you’re specifically looking for, we’ve recently written about some of our top 5 favorites by topic:

• Top 5 underrated design systems
• Top 5 design systems with great documentation on patterns
• Top 5 design systems with great accessibility documentation
• Top 5 design systems with content design guidelines

Hope you find some new inspiration to propel your work!

Cheers,

Zhippy

Zhippy is always eager to help and share design system advice with you. If you have any questions, design system dilemmas, or need advice to improve your design system documentation or strategy, don’t hesitate to reach out! Simply message Zhippy with this form, and our lovable mascot will gladly lend a paw.