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.
Thursday, September 13th, 2018
Tuesday, September 4th, 2018
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.
Saturday, September 1st, 2018
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.
Tuesday, August 21st, 2018
Mozilla’s work-in-progress style guide and pattern library.
Saturday, August 11th, 2018
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.
Wednesday, July 25th, 2018
The history of design systems at Clearleft
We decided to ask the Fractal community for help, and the response has been overwhelming. We’ve received so many offers of support in all forms that we can safely say that development will be starting up again shortly.
Although Fractal itself is barely two years old, it’s part of a much longer legacy at Clearleft…
It all started with Natalie. She gave a presentation back in 2009 called Practical Maintainable CSS . She talks about something called a pattern porfolio—a deliverable that expresses every component and documents how the markup and CSS should be used.
When Anna was interning at Clearleft, she was paired up with Natalie so she was being exposed to these ideas. She then expanded on them, talking about Front-end Style Guides. She literally wrote the book on the topic, and starting curating the fantastic collection of examples at styleguides.io.
At Clearleft, rather than deliver an inflexible set of static pages, we present our code as a series of modular components (a ‘pattern portfolio’) that can be assembled into different configurations and page layouts as required.
Such systematic thinking was instigated by Natalie, yet this is something we continually iterate upon.
To see the evolution of Paul’s thinking, you can read his three part series from last year on designing systems:
- Theory, Practice, and the Unfortunate In-between,
- Layers of Longevity, and
- Components and Composition
Later, Charlotte joined Clearleft as a junior developer, and up until that point, hadn’t been exposed to the idea of pattern libraries or design systems. But it soon became clear that she had found her calling. She wrote a brilliant article for A List Apart called From Pages to Patterns: An Exercise for Everyone and she started speaking about design systems at conferences like Beyond Tellerrand. Here, she acknowledges the changing terminology over the years:
Pattern portfolio is a term used by Natalie Downe when she started using the technique at Clearleft back in 2009.
Front-end style guides is another term I’ve heard a lot.
Personally, I don’t think it matters what you call your system as long as it’s appropriate to the project and everyone uses it. Today I’m going to use the term “pattern library”.
(Mark was always a fan of the term “component library”.)
Now Charlotte is a product manager at Ansarada in Sydney and the product she manages is …the design system!
Thinking back to my work on starting design systems, I didn’t realise straight away that I was working on a product. Yet, the questions we ask are similar to those we ask of any product when we start out. We make decisions on things like: design, architecture, tooling, user experience, code, releases, consumption, communication, and more.
It’s been fascinating to watch the evolution of design systems at Clearleft, accompanied by an evolution in language: pattern portfolios; front-end style guides; pattern libraries; design systems.
There’s been a corresponding evolution in prioritisation. Where Natalie was using pattern portfolios as a deliverable for handover, Danielle is now involved in the integration of design systems within a client’s team. The focus on efficiency and consistency that Natalie began is now expressed in terms of design ops—creating living systems that everyone is involved in.
When I step back and look at the history of design systems on the web, there are some obvious names that have really driven their evolution and adoption, like Jina Anne, Brad Frost, and Alla Kholmatova. But I’m amazed at the amount of people who have been through Clearleft’s doors that have contributed so, so much to this field:
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.
Here’s an intriguing proposal that would allow web apps to indicate activity in an icon (like an unread count) in the same way that native apps can.
This is an interesting one because, in this case, it’s not just browsers that would have to implement it, but operating systems as well.
Wednesday, July 18th, 2018
Erika has written a great guest post on Ev’s blog. It covers the meaning, the impact, and the responsibility of design …and how we’ve been chasing the wrong measurements of success.
We design for the experience of a single user at a time and expect that the collective experience, and the collective impact, will take care of itself.
Tuesday, July 17th, 2018
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.
Tuesday, July 10th, 2018
Components and concerns
But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:
This echoes a point made previously in a slidedeck by Cristiano Rastelli.
Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?
In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:
Your starting point should always be well-structured markup.
This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.
That’s basically an application of starting with the rule of least power.
In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:
We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”
There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.
My point is this:
- Separating structure, presentation, and behaviour is a good idea.
- Separating an interface into components is a good idea.
Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.
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.
Tuesday, June 26th, 2018
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.
Monday, June 25th, 2018
Why Design Systems Fail by Una Kravets
Una works at the Bustle Digital Group, which publishes a lot of different properties. She used to work at Watson, at Bluemix and at Digital Ocean. They all have something in common (other than having blue in their logos). They all had design systems that failed.
Design systems are so hot right now. They allow us think in a componentised way, and grow quickly. There are plenty of examples out there, like Polaris from Shopify, the Lightning design sytem from Salesforce, Garden from Zendesk, Gov.uk, and Code For America. Check out Anna’s excellent styleguides.io for more examples.
What exactly is a design system?
It’s a broad term. It can be a styleguide or visual pattern library. It can be design tooling (like a Sketch file). It can be a component library. It can be documentation of design or development usage. It can be voice and tone guidelines.
When Una was in College, she had a print rebranding job—letterheads, stationary, etc. She also had to provide design guidelines. She put this design guide on the web. It had colours, heading levels, type, logo treatments, and so on. It wasn’t for an application, but it was a design system.
Primer by Github is a good example of this. You can download pre-made icons, colours, etc.
Code usage guidelines
AirBnB has a really good example of this. It’s a consistent code style. You can even include it in your build step with
Design usage documentation
Carbon by IBM does a great job of this. It describes the criteria for deciding when to use a pattern. It’s driven by user experience considerations. They also have general guidelines on loading in components—empty states, etc. And they include animation guidelines (separately from Carbon), built on the history of IBM’s magnetic tape machines and typewriters.
Voice and tone guidelines
Of course Mailchimp is the classic example here. They break up voice and tone. Voice is not just what the company is, but what the company is not:
- Fun but not silly,
- Confident but not cocky,
- Smart but not stodgy,
- and so on.
Voiceandtone.com describes the user’s feelings at different points and how to communicate with them. There are guidelines for app users, and guidelines for readers of the company newsletter, and guidelines for readers of the blog, and so on. They even have examples of when things go wrong. The guidelines provide tips on how to help people effectively.
Why do design systems fail?
Una now asks who in the room has ever started a diet. And who has ever finished a diet? (A lot of hands go down).
Nobody uses it
At Digital Ocean, there was a design system called Buoy version 1. Una helped build a design system called Float. There was also a BUI version 2. Buoy was for product, Float was for the marketing site. Classic example of 927. Nobody was using them.
Una checked the CSS of the final output and the design system code only accounted for 28% of the codebase. Most of the CSS was over-riding the CSS in the design system.
Happy design systems scale good standards, unify component styles and code and reduce code cruft. Why were people adding on instead of using the existing sytem? Because everyone was being judged on different metrics. Some teams were judged on shipping features rather than producing clean code. So the advantages of a happy design systems don’t apply to them.
It’s like going to the gym. Small incremental changes make a big difference over the long term. If you just work out for three months and then stop, you’ll lose all your progress. It’s like that with design systems. They have to stay in sync with the live site. If you don’t keep it up to date, people just won’t use it.
It’s really important to have a solid core. Accessibility needs to be built in from the start. And the design system needs ownership and dedicated commitment. That has to come from the organisation.
You have to start somewhere.
Communication is multidimensional; it’s not one-way. The design system owner (or team) needs to act as a bridge between designers and developers. Nobody likes to be told what to do. People need to be involved, and feel like their needs are being addressed. Make people feel like they have control over the process …even if they don’t; it’s like perceived performance—this is perceived involvement.
Ask. Listen. Make your users feel heard. Incorporate feedback.
Good communication is important for getting buy-in from the people who will use the design system. You also need buy-in from the product owners.
Showing is more powerful than telling. Hackathans are like candy to a budding design system—a chance to demonstrate the benefits of a design system (and get feedback). After a hackathon at Digital Ocean, everyone was talking about the design system. Weeks afterwards, one of the developers replaced Bootstrap with BUI, removing 20,000 lines of code! After seeing the impact of a design system, the developers will tell their co-workers all about it.
You need to build with composability and change in mind. Primer, by Github, has a core package, and then add-ons for, say, marketing or product. That separation of concerns is great. BUI used a similar module-based approach: a core codebase, separate from iconography and grid.
Semantic versioning is another important part of having a solid architecture for your design system. You want to be able to push out minor updates without worrying about breaking changes.
Use the same convention in your design files, like Sketch.
What about tech stack choice? Every company has different needs, but one thing Una recommends is: don’t wait to namespace! All your components should have some kind of prefix in the class names so they don’t clash with existing CSS.
Una mentions Solid by Buzzfeed, which I personally think is dreadful (count the number of
!important declarations—you can call it “immutable” all you want).
AtlasKit by Atlassian goes all in on React. They’re trying to integrate Sketch into it, but design tooling isn’t solved yet (AirBnB are working on this too). We’re still trying to figure out how to merge the worlds of design and code.
This is what it’s all about. Using the design system has to be the path of least resistance. If the new design system is harder to use than what people are already doing, they won’t use it.
Provide hooks and tools for the people who will be using the design system. That might be mixins in Sass or it might be a script on a CDN that people can just link to.
Start early, update often. Design systems can be built retrospectively but it’s easier to do it when a new product is being built.
Bugs and cruft always increase over time. You need a mechanism in place to keep on top of it. Not just technical bugs, but visual inconsistencies.
So the five pillars of ensuring a successful design system are:
- Solid architecture
- Reduce friction
When you’re starting, begin with a goal:
We are building a design system because…
Then review what you’ve already got (your existing codebase). For example, if the goal of having a design system is to increase page performance, use Web Page Test to measure how the current site is performing. If the goal is to reduce accessibility problems, use webaim.org to measure the accessibility of your current site (see also: pa11y). If the goal is to reduce the amount of CSS in your codebase, use cssstats.com to test how your current site is doing. Now that you’ve got stats, use them to get buy-in. You can also start by doing an interface inventory. Print out pages and cut them up.
Once you’ve got buy-in and commitment (in writing), then you can make technical decisions.
You can start with your atomic elements. Buttons are like the “Hello world!” of design systems. You’ve colours, type, and different states.
Then you can compose elements by putting the base elements together.
Do you include layout in the system? That’s a challenge, and it depends on your team. If you do include layout, to what extent?
Regardless of layout, you still need to think about space: the space between base elements within a component.
Bake in accessibility: every hover state should have an equal (not opposite) focus state.
Think about states, like loading states.
Then you can start documenting. Then inform the users of the system. Carbon has a dashboard showing which components are new, which components are deprecated, and which components are being updated.
Keep consistent communication. Design and dev communication has to happen. Continuous iteration, support and communication are the most important factors in the success of a design system. Code is only 10% of a sytem.
Also, don’t feel like you need to copy other design systems out there. Your needs are probably very different. As Diana says, comparing your design system to the polished public ones is like comparing your life to someone’s Instagram account. To that end, Una says something potentially contraversial:
You might not need a design sytem.
If you’re the only one at your organisation that cares about the benefits of a design system, you won’t get buy-in, and if you don’t get buy-in, the design system will fail. Maybe there’s something more appropriate for your team? After all, not everyone needs to go to the gym to get fit. There are alternatives.
Find what works for you and keep at it.
Wednesday, June 20th, 2018
- 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
Sunday, June 17th, 2018
This looks like a really good (and free!) online book all about design ops.
Friday, June 15th, 2018
Do we have too many design systems?
Spoiler: the answer is “no”. There. Saved you a click.
(Not really; you should definitely click.)
Tuesday, June 5th, 2018
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’.
Monday, June 4th, 2018
I really like the way that this pattern library includes research insights to provide justification for design decisions.
Sunday, June 3rd, 2018
In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.
I think Dave is right. At this point, it’s possible to be a React developer exclusively.
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.