Home
Design System Weekly is a curated bulletin of inspirational and design system resources I find interesting and wish to share. It's written Benoît Meunier.
Lastest bulletin
± A big bulk of november links
TELUS Design System: Building a community
Two wonderful things about this post:
The federated model described by Nathan is basically a Tree and Branch network - the perfect hybrid. Tree and Branch networks are:
Easily scalable - just add a new branch
Consensus driven - branch node validates all decisions
Fault tolerant - errors are confined to single branches
Process friendly - branch node helps expedite information relays
And the phased approach:
Split components within a monolithic repo
Split components into Core and Community
Build out the branches
Agree upon community principles and guidelines
Design Systems: From Project Done to Product Sustained
Manage and support a sustainable design system
Align team interests across products
Inspire designers to share their work
Aligning. Sustain. Share. Design system is not tech oriented.
Design Systems: Mastering Design at Scale - Series Trailer
As the digital landscape gets bigger and more complex, design as become as complex as the organisations themselves.
The most exciting design systems are boring
Design-system builders should resist the lure of the new. Don’t confuse design-system work with a rebrand or a tech-stack overhaul. The system’s design patterns should be familiar, even boring.
The job is not to invent, but to curate.
It’s a design systems, not a brand guideline.
Design systems should always extract their patterns from working code.
Because Design Systems is not a place for untested ideas. Extract proven ideas from production interfaces is the main task:
Extract proven patterns from legacy applications.
Build pilot apps alongside the design system that prove out new and necessary design patterns.
Part 1 and 2 via https://medium.com/interactive-mind/design-systems-and-agility-part-1-of-2-b96c188acfca, https://medium.com/@daughterofbev/design-systems-and-agility-part-2-of-2-42418819f65a
So many insights. Practical tips. So many.
“Organisations which design systems… are constrained to produce designs which are copies of the structure of these organisations”
- Conways Law (1968)
Six lessons learned by creating a design system at a fast-moving start-up
Oscar builds digital tools for a range of users, including members, providers, brokers, employers, and a wide array of Oscar employees.
I love transcription of keynotes.
In one of my biggest project right now, we have inconsistent design (partners vs users) but when you take a step back, it’s coherent with the experience. It’s not a design system applied blindly.
Design System Imposter Syndrom
Take time to focus on what your organization needs or what gap a design system can fill.
Reach out to other teams building design systems. It will remind you we’re all still learning, and may provide some helpful tips.
Always remember to make decisions with your product’s user needs in mind. At the end of the day, design systems are used to build products that help each organization’s specific users achieve their goals.
Design Systems: benefits, challenges & solutions
When you’re building a design system or feel a component doesn’t feel right, ask your self:
What problem do we want to solve?
Is there an already built component we can use to solve that problem?
If we create a new component, can it solve other problems?
And yes.
We want to have our house in order before building a castle
— Pedro Moreira da Silva, Senior UX Designer at GitLab
Understanding why design systems are important for UX/HCD designers and cross-functional teams.
Design Systems at Startup Scale: Yes, Please!
...
Design System Imposter Syndrome
Typical symptoms of the syndrome may include:
Spending too much time comparing your UI design language/toolkit/guide to many of the extensive systems showcased on styleguides.io.
Second guessing or not feeling confident in the decisions you’re making because you don’t think they’re great ideas.
Putting off sharing the work you’ve done to your boss or project stakeholders because it’s not an extremely exhaustive list of UI patterns and components.
Coming up with random names for your design system because it doesn’t include all of the details that highly publicized design systems have.
Ahahaha
When NOT to Use a Design System
Your Development Team is Small and Communicates Well
Your Team Isn’t Doing Much Active Product Development
Your Business Has Limited Runway
In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.