November 21, 2023 Smashing Newsletter: Issue #432

We’d be absolutely delighted to meet you online and in-person this and next year. We sincerely wish you a lot of hope, optimism, positive energy, and love these days.

— Vitaly

1. Organizing Design System Libraries

Looking for a few tips to manage your Figma libraries without any friction? Jérôme Benoit has your back: In “How To Organize Your Design System At Scale”, he explains how you can set up a design system with 900 shared components and 25 designers — with product-specific domain components and shared ownership between the design system guild and product designers.

In many products, different feature teams often have very different needs, and that’s why secondary design systems emerge. With this setup, all teams are still working within one single design system, pulling and pushing components between levels and having search across all design work in all domains at once — without an organizational overhead! (vf)

2. Why Design Systems Fail

When building design systems, we need to keep in mind that they need to meet the needs of our organization, its culture, and its internal as well as external users. It’s quite critical to consider early where and when the design system work will happen. Often it’s an isolated effort of a single team in a small department, and as such, it often has a very hard time getting critical adoption or achieving alignment across the entire organization.

Karen VanHouten has put together a very honest overview of common issues with design system projects and how to resolve them. Ideally, the design system effort shouldn’t live on the fringes of the business but within business-critical teams — by finding allies for your design system early in the process and bringing them on board to contribute. (vf)

3. Designing A Design System Component From Scratch

It’s tempting to jump straight to Figma to explore a new design and see how the UI will change with it. It’s fine to experiment and try things out, but make sure to constrain the time and level of detail. Otherwise, you’ll end up designing a solution to a problem that doesn’t exist.

Rama Krushna Behera has written a comprehensive guide on how to add a new component to a design system — from auditing and proof of concept to reviews, variants, organization, accessibility, and release. Important note: Bring engineers and QA early on board to avoid big surprises down the line. (vf)

4. Design System Checklist (PDF)

The point of a design system is not to be fully comprehensive and cover every possible component you might ever need. It’s all about being useful enough to help designers produce quality work faster and be flexible enough to help designers make decisions, rather than make decisions for them.

In that regard, you may want to check out the Design System Checklist (available in PDF format) by Nathan Curtis. It’s a practical 2-page worksheet for a 60-minute team activity that is designed to choose the right parts, products, and people for your design system. A neat little helper to get your system off the ground! (vf)

5. Upcoming Workshops and Conferences

That’s right! We run online workshops on frontend and design, be it accessibility, performance, or design patterns. In fact, we have a couple of workshops coming up soon, and we thought that, you know, you might want to join in as well.

As always, here’s a quick overview:

• Advanced Modern CSS Masterclass Dev
  with Manuel Matuzović. Nov 27 – Dec 11
• Successful Design Systems Workflow
  with Brad Frost. Nov 28 – Dec 12
• Design Management Masterclass UX
  with Slava Shestopalov. Nov 30 – Dec 8
• Streamlining Your Websites Content Workflow
  with Paul Boag. Dec 7–15
• Deep Dive On Accessibility Testing Dev
  with Manuel Matuzović. Jan 8–22
• UX Strategy Masterclass UX
  with Vitaly Friedman. Jan 23 – Feb 6
• Resilient & Maintainable CSS Dev
  with Miriam Suzanne. Feb 26 – Mar 12
• Interface Design Patterns (Spring 2024) UX
  with Vitaly Friedman. Mar 8 – Apr 5
• Smart Interface Design Patterns Video Course UX
  9h-video + Live UX Training with Vitaly Friedman
• Jump to all workshops →

6. Design Guidelines For Teams

I see many teams trying to mandate design guidelines by blocking launch unless the design meets every single criterion on a 4-page checklist. While this might work to ensure consistency, often, it breaks the team’s spirit as guidelines feel heavily and rigorously enforced — often without exceptions.

Designers should really have a strong sense of ownership over the guidelines that they personally shape and develop. An interesting case study by Linzi Berry on how the Lyft team enforces design quality by clearing time for designers, distributing ownership and pushing design QA early in the process. Ultimately, make time and space for the designers in your team to set and follow the guidelines. They might not need stricter rules or mandates; they need time, trust, and autonomy to make good decisions on their own. (vf)

7. Design System In 90 Days Canvas

A canvas often acts as a great conversation starter. It’s rarely complete, but it brings up topics and problems that one wouldn’t have discovered on the spot. We won’t have answers to all questions right away, but we can start moving in the right direction to turn a design system effort into a success.

Dan Mall kindly shares a canvas he has used with many enterprise clients to help them get a design system product up and running (and adopted!) in 90 days or less (FigJam template available). The canvas includes useful prompts to create a design system for small and large organizations that are building a design system or plan to set up one. Saved! (vf)

8. How To Name Design Tokens

Naming is hard! How do we name and organize design tokens in our design systems? Let’s take a look at some do’s, don’ts, guides, and examples to get started. Design tokens represent small, repeatable design decisions. Instead of using exact HEX or px-values, we refer to a token whose name describes how and where they are used. It makes it much easier to update the design by changing one value in one place and not breaking anything else in between.

We break apart every single UI component into standalone tokens. The more specific these tokens are, the more confidence we have in using and changing them across the product. But the more generic the tokens, the more flexibility we have in using them. In fact, component tokens are where most design system teams struggle.

Naming patterns are exhibited via naming levels; common levels are category, concept, property, variant/scale, and state. Regular design systems typically use a few levels, but large multi-platform systems might have as many as 5–6 naming levels. (vf)

9. News From The Smashing Library

Promoting best practices and providing you with practical tips to master your daily coding and design challenges has always been at the core of everything we do at Smashing.

In the past few years, we were very lucky to have worked together with some talented, caring people from the web community to publish their wealth of experience as printed books. Have you checked them out already?

• Understanding Privacy by Heather Burns
• Touch Design for Mobile Interfaces by Steven Hoober
• Image Optimization by Addy Osmani
• Check out all books →

That’s All, Folks!

Thank you so much for reading and for your support in helping us keep the web dev and design community strong with our newsletter. See you next time!

This newsletter issue was written and edited by Geoff Graham (gg), Cosima Mielke (cm), Vitaly Friedman (vf), and Iris Lješnjanin (il).

Smashing Newsletter

Useful front-end & UX bits, delivered once a week. Subscribe and get the Smart Interface Design Checklists PDF — in your inbox. 🎁

Your (smashing) email Subscribe →

Front-end, design and UX. Sent out 1× a week.
You can always unsubscribe with just one click.