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.
Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!
After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.
The Gov.uk design system is looking very, very good indeed—nicely organised with plenty of usage guidelines for every component.
Guidance on using components and patterns now follow a simple, consistent format based on task-based research into what users need in order to follow and trust an approach.
- Know where you stand before starting the journey
- Make sure everyone is speaking the same language
- Integrate the right tools into your team’s workflow
A collection of collections.
This site is dedicated to compiling and sharing useful resources for Designers and UI Developers.
Do we have too many design systems?
Spoiler: the answer is “no”. There. Saved you a click.
(Not really; you should definitely click.)
I’ve been wondering about this for quite a while: surely demanding specific patterns in a password (e.g. can’t be all lowercase, must include at least one number, etc.) makes it easier to crack them, right? I mean, you’re basically providing a ruleset for brute-forcing.
Turns out, yes. That’s exactly right.
When employees are faced with this requirement, they tend to:
- Choose a dictionary word or a name
- Make the first character uppercase
- Add a number at the end, and/or an exclamation point
If we know that is a common pattern, then we know where to start…
The steps that the Canva team took to turbocharge their design ops.
I’ll talk about why creating a shared design system has boosted our organizational productivity—and how you can help your teams improve product quality while reducing your company’s ‘design debt’.
I really like the way that this pattern library includes research insights to provide justification for design decisions.
This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.
No longer focused on recreating the wheel (or icon), designers can turn their attention to different types of challenges.
Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)
A great slide deck from Alla, all about design principles. From purpose to principles to patterns.
Prompted by his recent talk at Smashing Conference, Mark explains why he’s all about the pace layers when it comes to design systems. It’s good stuff, and ties in nicely with my recent (pace layers obsessed) talk at An Event Apart.
Structure for pace. Move at the appropriate speed.
A terrific talk by Adrian Holovaty. I really hope front-end developers talk its message to heart.
The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.
Part one of a deep dive by Nathan into structuring design system documentation, published on Ev’s blog.