A terrific talk by Adrian Holovaty. I really hope front-end developers talk its message to heart.
Sunday, April 15th, 2018
Monday, April 2nd, 2018
Scenario-Driven Design Systems by Yesenia Perez-Cruz
In the last few years, we’ve seen a lot of change in web design as we have to adapt to so many viewports and platforms. We’ve gravitated towards design systems to manage this. Many people have written about the benefits of design systems, like AirBnB.
But how do you define a design system? You could say it’s a collection of reususable components.
Donella Meadows wrote Thinking in Systems. She said:
A system is an interconnected group of elements coherently organized in a way that achieves something.
A good design system inspires people to work with it. A bad system gets bloated and unusable. Yesenia has seen systems fail when there’s too much focus on the elements, and not enough focus on how they come together. Yesenia has learned that we should start our design systems, not with components, or modules, or legos, but with user scenarios.
Yesenia works at Vox Media. They have eight editorial networks. Two and a half years ago, they started a project to move all of their products to one codebase and one design system. Maintaining and iterating on their websites was getting too cumbersome. They wanted to shift away from maintaining discrete brands to creating a cohesive system. They also wanted to help their editorial teams tell stories faster and better.
It was hard. Each brand has its own visual identity, editorial missions, and content needs. So even though they wanted eight brands to use one design system, there needed to be enough flexibility to allow for unique needs.
There were some early assumptions that didn’t work. There was a hunch that they could take smaller modular components to address inconsistencies in design: layout, colour, and typography. They thought a theming system would work well. They started with layout modules, like three different homepage hero elements, or four different story blocks. They thought they could layer colour and typography over these modules. It didn’t work. They weren’t reflecting critical differences in content, tone, and audience. For example, Curbed and Recode are very different, but the initial design system didn’t reflect those difference.
That brings us back to Donella Meadows:
A system is an interconnected group of elements coherently organized in a way that achieves something.
They weren’t thinking about that last part.
They learned that they couldn’t start with just the individual components or patterns. That’s because they don’t exist in a vacuum. As Alla says:
Start with language, not systems.
They started again, this time thinking about people.
- What’s the audience goal?
- Is there a shared audience goal across all brands or are there differences?
- What’s the editorial workflow?
- What range of content should this support?
This led to a much better process for creating a design system.
Start with a fast, unified platform. It should load quickly and work across all devices. All patterns should solve a specific problem. But that doesn’t mean creating a one-size-fits-all solution. A design system doesn’t have to stifle creativity …as long as the variants solve a real problem. That means no hypothetical situations.
Identify scenarios. Brad uses a UI inventory for this. Alla talks about a “purpose-directed inventory”. Map core modules to user journeys to see how patterns fit together in the bigger picture. You start to see families of patterns joined together by a shared purpose. Scenarios can help at every level.
The Salesforce design system starts by saying “Know your use-case.” They have examples of different patterns and where to use them. Thinking in user-flows like this matches the way that designers are already thinking.
Shopify’s Polaris system also puts users and user-flows at the centre: the purpose of each pattern is spelled out.
The 18F Design System doesn’t just provide a type system; it provides an explanation of when and where to use which type system.
At Vox, “features” are in-depth pieces. Before having a unified system, each feature looked very custom and were hard to update. They need to unify 18 different systems into one. They started by identifying core workflows. Audience goals were consistent (consume content, find new content), but editorial goals were quite different.
They ended up with quite a few variations of patterns (like page headers, for example), but only if there was a proven content need—no hypothetical situations.
Brand expression for features is all about the details. They started with 18 very different feature templates and ended up with one robust template that works across device types but still allowed for expression.
The “reviews” pieces had a scorecard pattern. Initially there was one unified pattern that they thought would be flexible enough to cover different scenarios. But these scorecards were for very different things: games; restaurants, etc. So people’s needs were very different. In the end, instead of having one scorecard pattern, they created three. Each one highlighted different content according to the user needs.
Homepages were the most challenging to unify. Each one was very distinct. Identifying core workflows took a lot of work.
What’s the value of the homepage? Who is the audience? What are they looking for?
They talked to their users and distilled their findings down into three user goals for homepages:
- What’s new?
- What’s important?
- What’s helpful?
Those needs then translated into patterns. The story feed is there to answer the question “What’s new?”
When it came to variations on the home page, they needed to make sure their design system could stretch enough to allow for distinctly different needs. There’s a newspaper layout, an evergreen layout, a morning recap layout.
Again, Alla’s advice to focus on language was really helpful.
In the process of naming an element, you work out the function as a group and reach agreement.
The last piece was to have a scalable visual design system. Brands need to feel distinct and express an identity. They did this by having foundational elements (type scale, colour system, and white space) with theming applied to them. Thinking of type and colour as systems was key: they need to cascade.
But how do you tell good variation from bad variation? Variation is good if there’s a specific problem that you need a new pattern to solve—there’s a user scenario driving the variation. A bad variation is visual variation on components that do the same thing. Again, the initial design system provided room for “visual fluff and flair” but they were hypothetical. Those variations were removed.
The combination of a scenario-driven system combined with theming allowed for the right balance of consistency and customisation. Previously, the editorial team were hacking together the layouts they wanted, or developers were creating one-off templates. Both of those approaches were very time-consuming. Now, the reporters can focus on telling better stories faster. That was always the goal.
There’s still a lot of work to do. There’s always a pendulum swing between consistency and variation. Sometimes the design system goes too far in one direction or the other and needs to be recalibrated. They want to be able to add more detailed control over typography and spacing.
To wrap up:
- Successful design patterns don’t exist in a vacuum.
- Successful design systems solve specific problems.
- Successful design systems start with content and with people.
Tuesday, March 27th, 2018
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.
Wednesday, March 21st, 2018
Part one of a deep dive by Nathan into structuring design system documentation, published on Ev’s blog.
Monday, March 5th, 2018
Sunday, March 4th, 2018
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.
Friday, March 2nd, 2018
- 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?
Tuesday, February 27th, 2018
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.
Friday, February 2nd, 2018
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
Thursday, January 25th, 2018
Design ops for design systems
Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.
Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.
Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.
There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.
Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:
- Styleguides, Pattern Libraries and Design Languages
- Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?
- Design Systems, Style Guides, and Pattern Libraries: Oh My!
- What’s the difference between style guides, pattern libraries, and design systems?
None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.
There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:
- Why Design Systems Fail
- Tips for in-house teams in a free market software culture
- Putting your design system into practice
Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.
I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:
Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.
Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.
Sunday, January 14th, 2018
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.
Thursday, January 11th, 2018
Friday, January 5th, 2018
Thursday, December 14th, 2017
Great advice from Una on getting buy-in and ensuring the long-term success of a design system.
Thursday, December 7th, 2017
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.
Wednesday, December 6th, 2017
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.
Monday, December 4th, 2017
Tuesday, November 28th, 2017
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.
Monday, November 27th, 2017
A table of design systems, pattern libraries, style guides, or whatever we’re calling them.