A starter list of Fractal examples and links. You can expand it.
A great selection of links about design systems, collected and categorised.
You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.
Marissa Christy outlines the reasons why your design system might struggle:
- The redesign isn’t prioritized
- The tech stack is changing
- Maintenance takes discipline
But she also offers advice for counteracting these forces:
- Get buy-in from the whole team
- Prioritize a lightweight re-skin on older parts of the product
- Treat a design system like any other product project: start small
- Don’t wait for others. Lead by example.
- Finally, don’t compare yourself to others on the internet
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.
I know I’m biased because I work with Jerlyn, but I think this in-depth piece by her is really something! She suveys the design system landscape and proposes some lo-fi governance ideas based around good old-fashioned dialogue.
Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.
It can start small.
What we get from the pattern library is time and freedom to be creative. I’ve seen people claim pattern libraries are the death of creativity and innovation in design. For us, it’s the opposite of that.
You really don’t need jQuery any more …and that’s thanks to jQuery.
I’m going through a pattern library right now, and this rings true:
I’m of the opinion that all cards in a Card UI are destined to become baby webpages. Just like modals. Baby hero units with baby titles and baby body text and baby dropdown menu of actions and baby call to action bars, etc.
In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSS’s cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if it’s just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
Mozilla’s work-in-progress style guide and pattern library.
A step-by-step guide to wrapping up a self-contained bit of functionality (a camera, in this case) into a web component.
Mind you, it would be nice if there were some thought given to fallbacks, like say:
<simple-camera> <input type="file" accept="image/*"> </simple-camera>
I strongly recommend that you read Going Offline by Jeremy Keith. Before his book, I found the concept of service workers quite daunting and convinced myself that it’s one of those things that I’ll have to set aside a big chunk of time to learn. I got through Jeremy’s book in a few hours and felt confident and inspired. This is because he’s very good at explaining concepts in a friendly, concise manner.
The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.
I like the questions that the TELUS team ask about any potential components to be added to their design system:
- Is it on brand?
- Is it accessible?
- Has it been tested?
- Can it be reused?
They also have design principles.
(Caveat: because everything’s happening in
script elements in the browser, what’s outlined here will only do client-side rendering.)
It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.
I’ve thought often of how our design and prototyping tools for the web are often not of the web. Tools like Photoshop and Sketch and Invision create approximations but need to walk the line between being a tool to build native apps and to build web apps. They do well in their ability to quickly validate designs but do little to validate technical approach.