This is a great resource for writing documentation, which is very important in any design system.
- Haley Hughes (Airbnb)
In each case, the objects don’t just describe a UI widget. They mean something very specific in the context of the product.
Design systems fix the common problems, not the easy ones
Don’t get trapped in defining things instead of explaining things. Sarah Federman
Of all the investments and effort we put into improving our documentation site, our biggest success this year came from the time we put into the UI kit we created for Sketch.
design systems should be like the ship of Theseus — as their components change and are replaced, they should fundamentally remain the same vessel with the same purpose.
Your design systems ability to bridge gaps between disciplines is a superpower
The components act as your ingredients, while the patterns and guides act as your recipes.
This time, we wanted to design our design system, just like we’d design one of our product experiences. We weren’t starting with a completely blank slate, though. We wanted to consolidate the resources we had, and create a system that felt unified, accessible, collaborative, and based on a coherent vision. Most importantly, we wanted a system that would fit with Spotify’s culture of autonomy—one that could scale across multiple platforms and use cases.
Design systems are not just an embodiment of aesthetics and brand identity, they represent an organization’s workflow and processes.
When creating a sustainable culture, your design system is only as strong as your relationships with the teams who use it.
This article is great for the early stages of design system development. It includes a great activity to get everyone on the same page with the priority of high-level user stories such as "As an adopter, how do I get updates".
A good design system should be a collection of your organization’s best institutional knowledge.
Having product principles to help guide individual and team decision making meaningfully improves our collective product process.
Good design principles are memorable. Good design principles help you say no. Good design principles aren’t truisms. Good design principles are applicable.
At the end of the day, the system is an internal tool and our coworkers are its users. Their human, just like us, and they want to do a good job, just like us. By empathizing, reassuring, educating, remaining flexible, sharing, communicating, and staying positive we’ve overcome many hurdles and are excited to take on new challenges in the future.
A quality component feels like the company and works as intended every time for all users — a crafted balance of brand essence and science.
But it turns out a design system can't be perfected in solitude because it's rooted in human relationships. It serves as a mirror for the company, a reflection of the dynamics at play between designers, engineers, product managers and even customers.
Reduce the distance between your documentation and code. By co-locating documentation and code, it’s more likely that you’ll remember to update the documentation when a component changes.
Barriers to involvement are often invisible The more complex an organization gets, the more we need to lean on a system to enable competent, cohesive decisions
If you try to over-optimize for UI consistency, you’ll end up with a system that is too rigid or can’t adapt to consumer needs. If you over-emphasize development speed, you’ll likely sacrifice quality. Instead, we should optimize for resilience and adaptability. Alan B Smith
Product teams’ primary concern is getting work out the door, not to uphold the integrity of the design system.
Great documentation should be less like a document and more like a workshop.
The most important thing I’ve learned about writing doc is to always be writing doc. Don’t trigger it by a step in the process. Instead, start a living document that grows as you research, design, code and complete a system feature.
- Adam Rowe, Morningstar Design System
There’s always more stories to tell, more scenarios to exhibit, more guidelines you could write. Some of them are important. But maybe not as much as other things you could do. And that’s ok. Don’t get anxious about it. Your end goal isn’t doc, it’s end-customer experience quality and speed-to-market.
Update when someone asks you a question — this is probably my biggest piece of advice on the topic of documentation.
In the GOV.UK Design System, which I work on, we use realistic copy in most of our examples. We’ve found it helps to give our users an idea of how something works in context and shows, at least implicitly, what good copy looks like.
Guided theme building allows your components to be themed to a degree that allows third parties to use them to create their own product, with its own look and feel, but removes the risk of people over-customizing them.
Centralized style libraries, accessible by both design and development tools, will serve as the place to make updates without having to revise coded components.
When designing an accessible color system, using a perceptually uniform color model (like CIELAB) helped us understand how each color appears to our eyes as opposed to how it appears to a computer.
The most effective design systems contain a branded point of view unique to them — things that make their design system more specific to the product they’re for — along with common design best practices.
... since launch, we’ve found that our early adopters highly value our documentation as a single source of truth.
The reason for introducing a design system in a company is not because so people can work less, but because so people can work better. I want people to focus on the important things, and reduce the amount of repetitive work they do.
Even though there is plenty of design systems by other companies, they all address certain business needs which most likely differ from ours.
Good names help team members who did not design or build the patterns understand their use. Good names help onboard new hires faster. Good names are memorable.
Use all your powers to give your offsite / unsupported teams every conceivable resource and tool they’ll need to help themselves. You can never guarantee that their copy will be wonderful, but at least you’re helping establish some kind of baseline. Unremarkable functional copy is always better than utterly fucked copy.
Creating a technology dependency in order to achieve a specific UI style inherently limits where that UI can go.
- Pattern Patter
- Design Doesn't Scale
- A Design System isn't a Project. It's a Product, Servicing Products
- Patterns ≠ Components
- Principles of Designing Systems
- Right-Sizing the Rectangles
- UI component explorers - your new favorite tool
- Balancing Platforms in a Design System
- Space in Design Systems
- Contributions to Design Systems
- Design System Doc Components
- Design System Features, Step-by-Step
- Researching Design Systems
- GE's Predix Design System
- Documenting Components Pt. 1
- Design Systems are a Single Point of Failure
- Beyond Tools: How Building A Design System Can Improve How You Work
- Design Systems in the Wild
- Selling a Design System Before Asking For Buy In
- Building a Successful Design System — 3 Lessons for Design Managers
- Design Systems
- The Design System Product
- The Salesforce Team Model for Scaling a Design System
- Developing a design environment
- Keeping your design system evergreen
- Distinct Design Systems
- Design System Weaknesses
- The system always kicks back
- Design Systems Ops