Tags: styleguide

101

sparkline

Monday, June 4th, 2018

Bulb Design System

I really like the way that this pattern library includes research insights to provide justification for design decisions.

Monday, May 7th, 2018

Design systems

Talking about scaling design can get very confusing very quickly. There are a bunch of terms that get thrown around: design systems, pattern libraries, style guides, and components.

The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.

This is something that Cennydd mentioned recently:

Here’s my thing with the modularisation trend in design: where’s the gestalt?

In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.

I understand the urge to fixate on patterns. They’re small enough to be manageable, and they’re tangible—here’s a carousel; here’s a date-picker. But a design system is big and intangible.

Games are great examples of design systems. They’re frameworks. A game is a collection of rules and constraints. You can document those rules and constraints, but you can’t point to something and say, “That is football” or “That is chess” or “That is poker.”

Even though they consist entirely of rules and constraints, football, chess, and poker still produce an almost infinite possibility space. That’s quite overwhelming. So it’s easier for us to grasp instances of football, chess, and poker. We can point to a particular occurrence and say, “That is a game of football”, or “That is a chess match.”

But if you tried to figure out the rules of football, chess, or poker just from watching one particular instance of the game, you’d have your work cut for you. It’s not impossible, but it is challenging.

Likewise, it’s not very useful to create a library of patterns without providing any framework for using those patterns.

I would go so far as to say that the actual code for the patterns is the least important part of a design system (or, certainly, it’s the part that should be most malleable and open to change). It’s more important that the patterns have been identified, named, described, and crucially, accompanied by some kind of guidance on usage.

I could easily imagine using a tool like Fractal to create a library of text snippets with no actual code. Those pieces of text—which provide information on where and when to use a pattern—could be more valuable than providing a snippet of code without any context.

One of the very first large-scale pattern libraries I can remember seeing on the web was Yahoo’s Design Pattern Library. Each pattern outlined

  1. the problem being solved;
  2. when to use this pattern;
  3. when not to use this pattern.

Only then, almost incidentally, did they link off to the code for that pattern. But it was entirely possible to use the system of patterns without ever using that code. The code was just one instance of the pattern. The important part was the framework that helped you understand when and where it was appropriate to use that pattern.

I think we lose sight of the real value of a design system when we focus too much on the components. The components are the trees. The design system is the forest. As Paul asked:

What methodologies might we uncover if we were to focus more on the relationships between components, rather than the components themselves?

Wednesday, March 21st, 2018

Hudl Uniform

This design system takes an interesting approach, splitting the documentation between designing and coding.

The first visual identity for UK Parliament

Some lovely branding work for the UK Parliament, presented very nicely.

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:

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:

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.

Thursday, January 11th, 2018

TNZ Pattern Library Docs

New Zealand has a pattern library (in Fractal, no less).

Friday, January 5th, 2018

Herman: Automated Pattern Libraries | OddBird

A lightweight style guide generator. This one uses SassDoc to parse out the documentation for colours, type, etc.

Thursday, December 14th, 2017

Why Design Systems Fail ◆ 24 ways

Great advice from Una on getting buy-in and ensuring the long-term success of a design system.

Monday, December 4th, 2017

A11Y Style Guide

A library of accessible UI elements that you can use as a starting point, complete with HTML and CSS. Alas, no JavaScript, but there’s always Heydon’s inclusive components for that.

Tuesday, November 28th, 2017

Design Systems Handbook - DesignBetter.Co

A weirdly over-engineered online book with bizarre scrolljacking (I would advise disabling JavaScript but then all the links stop working so you won’t be able to go past the table of contents) but it’s free and the content—by Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield— looks good:

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 collection of awesome design systems

A table of design systems, pattern libraries, style guides, or whatever we’re calling them.

Wednesday, November 1st, 2017

Distilling How We Think About Design Systems

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.

Thursday, October 19th, 2017

Design Systems | susan jean robertson

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!

Wednesday, October 4th, 2017

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

Friday, September 29th, 2017

Photon Design System

Most design systems I link to are for websites, so interesting to see this one for a web browser: Firefox.

There are guidelines for tone of voice and motion design as well as the usual guidelines for typography, colour, and interface elements.

Wednesday, August 23rd, 2017

Integrating Animation into a Design System · An A List Apart Article

Alla looks at ways of documenting animations into a pattern library. I tell ya, her book is going to be unmissable!

Saturday, August 12th, 2017

I made a style guide for my personal web site and you should too.—zachleat.com

Here’s Zach’s style guide. But the real reason I’m linking to this is his lovely description of having a personal website that grows over time:

As my own little corner of the web unceremoniously turned ten years old this year, it’s really starting to feel more like a garden than a piece of software. I certainly enjoy tending to it. I can plant what I like and with proper care it can grow into something useful.

Wednesday, August 9th, 2017

Patterns Day 2017: Paul Lloyd on Vimeo

Paul pulls no punches in this rousing talk from Patterns Day.

The transcript is on his site.

Patterns Day 2017: Paul Lloyd

Thursday, August 3rd, 2017

Patterns Day 2017: Alice Bartlett on Vimeo

At Patterns Day, Alice shared what she has learned from shepherding the Origami project within the Financial Times.

Patterns Day 2017: Alice Bartlett

Saturday, July 29th, 2017

Patterns Day 2017: Jina Anne on Vimeo

Jina invented an entirely new genre for her Patterns Day talk—autobiographical fantasy.

Patterns Day 2017: Jina Anne