I completed Dan Mall‘s course Design Systems 101. 😎🎉Woohoo! *crowd cheer*.
Dan put together an engaging self-paced course – you won’t be dozing off while watching video after video. Often, you’ll watch him do the work and are encouraged to try it yourself. At the same time, the course isn’t overwhelming. Dan provides the essential fundamentals for both designers and engineers to get started on design systems.
This is a recap of what I learned.
Benefits
Design systems help to scale digital products:
- Having common solutions ready -> efficient
- Reusability -> consistency
- Frees up time -> innovation
Course
Course focus is on 3 types of design systems:
- Digital product – has its product owner, roadmap (ex. Polaris)
- Process – shared way of working (ex. design sprint)
- Practice – allocate time and get good at using it
Other types:
- Brand identity/visual language
- Projects – project is a one off with an output
- Tools and templates – to take and modify (ex. HTML boiler plate)
- Service – team providing consultations
Theory will only get you so far. Design system practice is vital (learning by doing). Tools and technology aren’t as important as culture and politics.
Design and Dev Tools
Design tools:
- Figma – multiplayer, plugins, less creating more reusing
- Sketch
- Photoshop
Dev tools:
- Visual Studio Code – terminal side-by-side with code, packages can be pain to setup
- CodePen – HTML+CSS+Javascript, settings allow easy use of packages (ex. Bootstrap), multiplayer
Use design system as a user
Try using unfamiliar design systems to build something as a user. This helps you understand design system user needs and pain points, guiding you on what to focus on when creating your own.
Examples of design systems:
Dan tried using 3 different systems to recreate Nike homepage. Every system is different and suitable for a different type of product.
Agile
Working software over comprehensive documentation — Agile Manifesto
Most roles at a company create documentation including designers. Only role creating actual software are developers. They write the code!
Hot potato
Ask a group of people, “Where are we going for a lunch?” and they’ll draw a blank. It’s easier to revise than create from scratch. Suggest McDonalds, and watch suggestions roll in.
Use generative AI to come up with (bad) ideas. Then eliminate the bad ones.
Refine
Refine ideas like drawings. Start with a rough sketch, then refine until you reach a sufficient fidelity.
The same approach can be applied to building products:
- Start with a plain text outline for your website: navigation, hero, articles, footer.
- Create simple HTML.
- Improve HTML.
- Add CSS.
Sketching directly in code is easy if design system provides necessary components: just put the pieces together.
Product -> Design system
Design system doesn’t exist in a vacuum. It’s interconnected with products customers use. Build just enough so it’s useful.
Virtuous cycle
Design system and products exist in a virtuous cycle. The mistake people make is they begin the cycle in a wrong place.
‘Make design system and then use design system’ approach rarely works. It’s difficult because the value of design system hasn’t been proven. Creating components in a vacuum is too abstract.
Pilot
Instead, make a pilot like they do on TV.
The mindset should be “components are extracted form product and put into design system for future use” and not “components are created in design system and put into product”.
Byproduct
Design systems components are a byproduct of good ol’ fashioned product work. Your team is already familiar with the product development process.
Process
- Make product or feature.
- Extract components.
- Use it to make a new product/feature.
Prioritize mundane
Design system should prioritize problems that teams confront over and over.
Your job is to curate, no invent. Invention takes place in products (try, test & pluck out worthy components). Don’t push new frontiers — gather settled solutions.
Canon
A good analogy is the Star Wars canon as a design system and the expanded universe as a product. The expanded universe serves as a space for experimentation, where new ideas are tested. Proven characters and stories that resonate are then accepted into the canon.
Your job as a design system professional is to spot commonalities, collect them, catalog them, and encourage and influence them to happen more, on purpose.
In addition to components themselves, a good design system provides guidelines on how to use its components, eliminating time-wasting questions like, “Should this be a popover or a lightbox?”
3rd time’s the charm
Add component to design system if 3 and more teams need it.
Component extraction process
1) Inventory
Grab screenshots or comps of UI elements from multiple products. For example, all input fields, cards, or buttons.
Prioritize elements that are used most often.
2) Commonalities
Identify commonalities:
- What is it that all of them have?
- What most have?
- What some have?
- What only few?
For example,
- all input fields have a white background,
- most have a placeholder text,
- some have rounded corners,
- only few have icons.
3) Build
Create component based on commonalities you identified. Don’t make a different one. This reduces the effort needed to persuade others to adopt it.
Don’t pre-optimize, build only what you need.
4) Test component in products
Swap the current component and the new one — Indiana Jones style.
Does anything break? Note down issues. Address them if they occur in three or more products.
Use design tokens to store reused values (colors, spacings, typography…).
How to keep design and development components in sync?
As of 2024, no tools can do this for you—it’s a manual process. Maintain the smallest possible set of components. Fewer components mean less work, so be smart about it. Only keep what you can realistically manage.
Environment
Product dependencies
The design system exists as one of the key dependencies for a product. Other dependencies include a digital asset management system for images, a content management system for copy, and a database for data. The product itself runs on React. All these dependencies are interconnected, forming a larger system composed of various parts and their relationships.
Connections
Understanding these connections is crucial. Don’t focus only on individual parts of the system. Think about the connections – for example:
- How can we make it easier for the design system to integrate with React?
- How can it better interact with the digital asset management system?
The more conversations we have about these interactions, the more successful the system will be.
System of systems
With this perspective, you see the design system not as an isolated entity but as a system within a system. This allows you to discuss it in relation to other dependencies, fostering a more holistic approach.
Documentation
Chronicle your experience as you use the system, much like journaling. Do something successfully, then write about it.
You want users of your design system to feel like Harry Potter discovering an old potions book, filled with handwritten notes from the Half-Blood Prince, guiding them to perfect the Draught of Living Death.
Explain the process in such a way so that anyone can use the system to build something. Ask someone new to use the system and chronicle their steps.
Reference site
Much like a LEGO store, reference site should display examples of what can be build with the design system. The focus is on the end result.
Individual components (bricks) are in the back of the store.
Tools
Storybook provides a list of components and documentation pages. Visitors are able to change component properties. Figma designs can be linked.
Zeroheight and Supernova are specifically designed for creating design system documentation.
Any tool for building websites can be used to build a documentation website: WordPress, Framer, Drupal…
Coverage
Ideally, 80% of components come from the design system. Team can focus their efforts on the remaining 20%.
There are many reasons why a particular design may have low design system coverage:
- Custom components
- Fork or duplicate of a design system component
- Earlier version of a component that was later generalized and contributed to the design system
- Components that originated from the design system but were changed substantially
- Design system components in non-design system containers
- Custom components in design system containers