I like the idea of “design bugs”:
Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called “design bugs.” These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration.
- What problems will a component library solve?
- Is everyone on the project behind the component library?
- How will the component library be used?
- What tool(s) will be used to build the component library?
- Where should the component library live?
- How granular should the library be? How should it be organized?
- How will component code be scoped? What about page layout?
- What data will the library use? What else should it have?
Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp, a more agnostic spiritual successor to AirBnB’s React Sketchapp.
The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.
After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with
In this excerpt from his forthcoming book, Cennydd gives an overview of what GDPR will bring to the web. This legislation is like a charter of user’s rights, and things don’t look good for the surveillance kings of online advertising:
The black box will be forced open, and people will find it’s full of snakes.
Great advice from Una on getting buy-in and ensuring the long-term success of a design system.
When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.
In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:
- The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
- My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
- My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.
A great in-depth report from Alice on creating, running, and most importantly, selling an in-house design system. This makes a great companion piece to her Patterns Day talk.
Where internal teams seem to go wrong is not appreciating that the thing they’re building is still a product and so it needs to compete with other products on the market.
A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt.
A table of design systems, pattern libraries, style guides, or whatever we’re calling them.
I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.
With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.
A collection of publicly available design systems, pattern libraries, and interface guidelines.
The slides from Yesenia’s talk on scenario-driven design.
Advice on building design systems:
- If you can avoid being ambiguous, please do.
- Favor common understanding over dictionary correctness.
- Make great operations a priority.
- Don’t get trapped in defining things instead of explaining things.
Susan reviews Alla’s superb book on design systems:
If you’re interested in or wanting to create a design system or improve the one you have or get buy in to take your side project at work and make it part of the normal work flow, read this book. And even better, get your colleagues to do the same, so you’ll have a shared understanding before you begin the hard work to build your own system.
Susan also published her highlights from the book. I really like that!
18F: Digital service delivery | Building a large-scale design system: How we created a design system for the U.S. government
Maya Benari provides an in-depth walkthrough of 18F’s mission to create a consistent design system for many, many different government sites.
When building out a large-scale design system, it can be hard to know where to start. By focusing on the basics, from core styles to coding conventions to design principles, you can create a strong foundation that spreads to different parts of your team.
There’s an interface inventory, then mood boards, then the work starts on typography and colour, then white space, and finally the grid system.
The lessons learned make for good design principles:
- Talk to the people
- Look for duplication of efforts
- Know your values
- Empower your team
- Start small and iterate
- Don’t work in a vacuum
- Reuse and specialize
- Promote your system
- Be flexible