Journal tags: styleguides

13

Patterns Day video and audio

If you missed out on Patterns Day this year, you can still get a pale imitation of the experience of being there by watching videos of the talks.

Here are the videos, and if you’re not that into visuals, here’s a podcast of the talks (you can subscribe to this RSS feed in your podcasting app of choice).

On Twitter, Chris mentioned that “It would be nice if the talks had their topic listed,” which is a fair point. So here goes:

It’s fascinating to see emergent themes (other than, y’know, the obvious theme of design systems) in different talks. In comparison to the first Patterns Day, it felt like there was a healthy degree of questioning and scepticism—there were plenty of reminders that design systems aren’t a silver bullet. And I very much appreciated Yaili’s point that when you see beautifully polished design systems that have been made public, it’s like seeing the edited Instagram version of someone’s life. That reminded me of Responsive Day Out when Sarah Parmenter, the first speaker at the very first event, opened everything by saying “most of us are winging it.”

I can see the value in coming to a conference to hear stories from people who solved hard problems, but I think there’s equal value in coming to a conference to hear stories from people who are still grappling with hard problems. It’s reassuring. I definitely got the vibe from people at Patterns Day that it was a real relief to hear that nobody’s got this figured out.

There was also a great appreciation for the “big picture” perspective on offer at Patterns Day. For myself, I know that I’ll be cogitating upon Danielle’s talk and Emil’s talk for some time to come—both are packed full of ineresting ideas.

Good thing we’ve got the videos and the podcast to revisit whenever we want.

And if you’re itching for another event dedicated to design systems, I highly recommend snagging a ticket for the Clarity conference in San Francisco next month.

Patterns Day Two

Who says the sequels can’t be even better than the original? The second Patterns Day was The Empire Strikes Back, The Godfather Part II, and The Wrath of Khan all rolled into one …but, y’know, with design systems.

If you were there, then you know how good it was. If you weren’t, sorry. Audio of the talks should be available soon though, with video following on.

The talks were superb! I know I’m biased becuase I put the line-up together, but even so, I was blown away by the quality of the talks. There were some big-picture questioning talks, a sequence of nitty-gritty code talks in the middle, and galaxy-brain philosophical thoughts at the end. A perfect mix, in my opinion.

Words cannot express how grateful I am to Alla, Yaili, Amy, Danielle, Heydon, Varya, Una, and Emil. They really gave it their all! Some of them are seasoned speakers, and some of them are new to speaking on stage, but all of them delivered the goods above and beyond what I expected.

Big thanks to my Clearleft compadres for making everything run smoothly: Jason, Amy, Cassie, Chris, Trys, Hana, and especially Sophia for doing all the hard work behind the scenes. Trys took some remarkable photos too. He posted some on Twitter, and some on his site, but there are more to come.

Me on stage. Inside the Duke of York's for Patterns Day 2

And if you came to Patterns Day 2, thank you very, very much. I really appreciate you being there. I hope you enjoyed it even half as much as I did, because I had a ball!

Once again, thanks to buildit @ wipro digital for sponsoring the pastries and coffee, as well as running a fun giveaway on the day. Many thank to Bulb for sponsoring the forthcoming videos. Thanks again to Drew for recording the audio. And big thanks to Brighton’s own Holler Brewery for very kindly offering every attendee a free drink—the weather (and the beer) was perfect for post-conference discussion!

It was incredibly heartwarming to hear how much people enjoyed the event. I was especially pleased that people were enjoying one another’s company as much as the conference itself. I knew that quite a few people were coming in groups from work, while other people were coming by themselves. I hoped there’d be lots of interaction between attendees, and I’m so, so glad there was!

You’ve all made me very happy.

The schedule for Patterns Day

Patterns Day is less than three weeks away—exciting!

We’re going to start the day at a nice civilised time. Registration is from 9am. There will be tea, coffee, and pastries, so get there in plenty of time to register and have a nice chat with your fellow attendees. There’ll be breaks throughout the day too.

Those yummy pastries and hot drinks are supplied courtesy of our sponsors Buildit @ Wipro Digital—many thanks to them!

Each talk will be 30 minutes long. There’ll be two talks back-to-back and then a break. That gives you plenty of breathing space to absorb all those knowledge bombs that the speakers will be dropping.

Lunch will be a good hour and a half. Lunch isn’t provided so you can explore the neighbourhood where there are plenty of treats on offer. And your Patterns Day badge will even get you some discounts…

The lovely Café Rust is offering these deals to attendees:

  • Cake and coffee for £5
  • Cake and cup of tea for £4
  • Sandwich and a drink for £7

The Joker (right across the street from the conference venue) is offering a 10% discount of food and drinks (but not cocktails) to Patterns Day attendees. I highly recommend their hot wings. Try the Rufio sauce—it’s awesome! Do not try the Shadow—it will kill you.

Here’s how the day is looking:

Registration
Opening remarks
Alla
Yaili
Break
Amy
Danielle
Lunch
Heydon
Varya
Break
Una
Emil
Closing remarks

We should be out of the Duke of York’s by 4:45pm after a fantastic day of talks. At that point, we can head around the corner (literally) to Holler Brewery. They are very kindly offering each attendee a free drink! Over to them:

Holler is a community based brewery, always at the centre of the local community. Here to make great beer, but also to help support community run pubs, carnival societies, mental health charities, children’s amateur dramatic groups, local arts groups and loads more, because these are what keep our communities healthy and together… the people in them!

Holler loves great beer and its way of bringing people together. They are excited to be welcoming the Patterns Day attendees and the design community to the taproom.

Terms and conditions:

  • One token entitles to you one Holler beer or one soft drink
  • Redeemable only on Friday 28th June 2019 between 4:45 and 20:00
  • You must hand your token over to the bar team

You’ll get your token when you register in the morning, along with your sticker. That’s right; sticker. Every expense has been spared so you won’t even have a name badge on a lanyard, just a nice discrete but recognisable sticker for the event.

I am so, so excited for Patterns Day! See you at the Duke of York’s on June 28th!

Sponsor Patterns Day

Patterns Day 2 is sold out! Yay!

I didn’t even get the chance to announce the full line-up before all the tickets were sold. That was meant to my marketing strategy, see? I’d announce some more speakers every few weeks, and that would encourage more people to buy tickets. Turns out that I didn’t need to do that.

But I’m still going to announce the final two speakers here becuase I’m so excited about them—Danielle Huntrods and Varya Stepanova!

Danielle is absolutely brilliant. I know this from personal experience because I worked alongside her at Clearleft for three years. Now she’s at Bulb and I can’t wait for everyone at Patterns Day to hear her galaxy brain thoughts on design systems.

And how could I not have Varya at Patterns Day? She lives and breathes design systems. Whether it’s coding, writing, speaking, or training, she’s got years of experience to share. Ever used BEM? Yeah, that was Varya.

Anyway, if you’ve got your ticket for Patterns Day, you’re in for a treat.

If you didn’t manage to get a ticket for Patterns Day …sorry.

But do not despair. There is still one possible way of securing an elusive Patterns Day ticket: get your company to sponsor the event.

We’ve already got one sponsor—buildit @ wipro digital—who are kindly covering the costs for teas, coffees, and pastries. Now I’m looking for another sponsor to cover the costs of making video recordings of the talks.

The cost of sponsorship is £2000. In exchange, I can’t offer you a sponsor stand or anything like that—there’s just no room at the venue. But you will earn my undying thanks, and you’ll get your logo on the website and on the screen in between talks on the day (and on the final videos).

I can also give you four tickets to Patterns Day.

This is a sponsorship strategy that I like to call “blackmail.”

If you were really hoping to bring your team to Patterns Day, but you left it too late to get your tickets, now’s your chance. Convince your company to sponsor the event (and let’s face it, £2000 is a rounding error on some company’s books). Then you and your colleagues need not live with eternal regret and FOMO.

Drop me a line. Let’s talk.

Three more Patterns Day speakers

There are 73 days to go until Patterns Day. Do you have your ticket yet?

Perhaps you’ve been holding out for some more information on the line-up. Well, I’m more than happy to share the latest news with you—today there are three new speakers on the bill…

Emil Björklund, the technical director at the Malmö outpost of Swedish agency inUse, is a super-smart person I’ve known for many years. Last year, I saw him on stage in his home town at the Confront conference sharing some of his ideas on design systems. He blew my mind! I told him there and then that he had to come to Brighton and expand on those thoughts some more. This is going to be an unmissable big-picture talk in the style of Paul’s superb talk last year.

Speaking of superb talks from last year, Alla Kholmatova is back! Her closing talk from the first Patterns Day was so fantastic that it I just had to have her come back. Oh, and since then, her brilliant book on Design Systems came out. She’s going to have a lot to share!

The one thing that I felt was missing from the first Patterns Day was a focus on inclusive design. I’m remedying that this time. Heydon Pickering, creator of the Inclusive Components website—and the accompanying book—is speaking at Patterns Day. I’m very excited about this. Given that Heydon has a habit of casually dropping knowledge bombs like the lobotomised owl selector and the flexbox holy albatross, I can’t wait to see what he unleashes on stage in Brighton on June 28th.

Emil Björklund Alla Kholmatova Heydon Pickering
Emil, Alla, and Heydon

Be there or be square.

Tickets for Patterns Day are still available, but you probably don’t want to leave it ‘till the last minute to get yours. Just sayin’.

The current—still incomplete—line-up comprises:

That isn’t even the full roster of speakers, and it’s already an unmissable event!

I very much hope you’ll join me in the beautiful Duke of York’s cinema on June 28th for a great day of design system nerdery.

Patterns Day 2: June 28th, 2019

Surprise! Patterns Day is back!

The first Patterns Day was in the Summer of 2017, and it was a glorious—a single day devoted to all things design system-y: pattern libraries, style guides, maintainability, reusability. It was a lot of fun, so let’s do it again!

Patterns Day 2 will take place on Friday, June 28th, in the beautiful Duke of York’s cinema in Brighton. If you went to the first Patterns Day, then you’ll know how luxuriously comfy it is in there.

Tickets are £175+VAT. The format will likely be the same as before: an action-packed day of eight talks, each 30 minutes long.

I’ve got an amazing line-up of speakers, but instead of telling you the whole line-up straightaway, I’m going to tease a little bit, and announce more speakers over the next few weeks and months. For now, here are the first three speakers, to give you an idea of the quality you can expect:

  • All the way from the US of A, it’s Una Kravets, who needs no introduction.
  • From the Government Digital Service, we’ve got Amy Hupe—she’ll have plenty to share about the GOV.UK design system.
  • And we’ve got Yaili, now a senior designer at Microsoft, where she works on the Azure DevOps design system.

Patterns Day will have something for everyone. We’ll be covering design, development, content strategy, product management, and accessibility. So you might want to make this a one-day outing for your whole team.

If you want to get a feel for what the day will be like, you can watch the videos of last year’s talks

Tickets for last year’s Patterns Day went fairly fast—the Duke of York’s doesn’t have a huge capacity—so don’t dilly-dally too long before grabbing your ticket!

The history of design systems at Clearleft

Danielle has posted a brief update on Fractal:

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.

It’s so gratifying to see that other people are finding Fractal to be as useful to them as it is to us. We very much appreciate all their support!

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.

When Paul joined Clearleft, it was a perfect fit. He was already obsessed with style guides (like the BBC’s Global Experience Language) and started writing and talking about styleguides for the web:

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:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. 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:

Natalie Downe, Anna Debenham, Paul Lloyd, Mark Perkins, Charlotte Jackson, and Danielle Huntrods …thank you all!

Why Design Systems Fail by Una Kravets

I’m at An Event Apart Boston where Una is about to talk about design systems, following on from Yesenia’s excellent design systems talk. I’m going to attempt to liveblog it…

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.

Styleguides

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.

Design tooling

Primer by Github is a good example of this. You can download pre-made icons, colours, etc.

Component library

This is where you get the code. Una worked on BUI at Digital Ocean, which described the interaction states of each components and how to customise interactions with JavaScript.

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 eslint-config-airbnb and stylelint-config-airbnb.

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.

Investment

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

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.

Buy-in

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.

Solid architecture

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.

Major.Minor.Patch

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.

Reduce Friction

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:

  1. Investment
  2. Communication
  3. Buy-in
  4. Solid architecture
  5. 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.

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?

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.

Patterns Day videos

Eleven days have passed since Patterns Day. I think I’m starting to go into withdrawal.

Fortunately there’s a way to re-live the glory. Video!

The first video is online now: Laura Elizabeth’s excellent opener. More videos will follow. Keep an eye on this page.

And remember, the audio is already online as a podcast.

Patterns Day speakers

Ticket sales for Patterns Day are going quite, quite briskly. If you’d like to come along, but you don’t yet have a ticket, you might want to remedy that. Especially when you hear about who else is going to be speaking…

Sareh Heidari works at the BBC building websites for a global audience, in as many as twenty different languages. If you want to know about strategies for using CSS at scale, you definitely want to hear this talk. She just stepped off stage at the excellent CSSconf EU in Berlin, and I’m so happy that Sareh’s coming to Brighton!

Patterns Day isn’t the first conference about design systems and pattern libraries on the web. That honour goes to the Clarity conference, organised by the brilliant Jina Anne. I was gutted I couldn’t make it to Clarity last year. By all accounts, it was excellent. When I started to form the vague idea of putting on an event here in the UK, I immediately contacted Jina to make sure she was okay with it—I didn’t want to step on her toes. Not only was she okay with it, but she really wanted to come along to attend. Well, never mind attending, I said, how about speaking?

I couldn’t be happier that Jina agreed to speak. She has had such a huge impact on the world of pattern libraries through her work with the Lightning design system, Clarity, and the Design Systems Slack channel.

The line-up is now complete. Looking at the speakers, I find myself grinning from ear to ear—it’s going to be an honour to introduce each and every one of them.

This is going to be such an excellent day of fun and knowledge. I can’t wait for June 30th!

Sharing pattern libraries

I’ve been huffduffing talks from this year’s South by Southwest, revisiting some of the ones I saw and catching up with some of the ones I missed.

There are some really design and development resources in there that I didn’t get to see in person:

One talk I did get to see was Andy’s CSS for Grown Ups: Maturing Best Practices.

CSS for Grown Ups: Maturing Best Practices on Huffduffer

It was excellent.

You can have a look through the slides.

He talks about different approaches to creating maintainable CSS for large-scale projects. He touches on naming conventions for classes, something that Nicolas Gallagher wrote about recently. And while he makes reference to SASS and Compass, Andy makes the compelling point that’s what more interesting than powerful tools is the arrival of powerful approaches like SMACSS and OOCSS.

Over and over again, Andy makes the point that we must think in terms of creating design systems, not simply styling individual pages—something that Paul has also spoken about. One of the most powerful tools for making that change in thinking is in the creation of style guides for the web and Paul has even created blog dedicated to the BBC’s style guide.

Andy referenced the BBC GEL style guide in his talk but pointed out that because it’s published as a PDF rather than markup, it isn’t as powerful as it could be—there’s inevitably a loss of signal when the patterns are translated into HTML and CSS. Someone from the BBC was in the audience, and in the Q and A portion, acknowledged that that was a really good point.

After the talk I got chatting with Lincoln Mongillo who worked on the recent responsive redesign of Starbucks.com. He mentioned that they created a markup and CSS style guide for the project. “You know what would be really cool?” I said. “If you published it!”

Here it is. It’s a comprehensive library of markup patterns; exactly the kind of resource that Anna wrote about in 24 Ways.

In my experience, creating a pattern library for any project is immensely valuable, whether you’re working in a team of two or a team of two hundred. I’ve found they work well as the next step after Style Tiles: a way of translating the visual vocabulary of a site into markup and CSS without getting bogged down in the specifics of page structure or layout (very handy for a Content First approach). The modularity of a pattern library enforces a healthy .

I’m really pleased to see more and more pattern libraries being made public. That’s one of the reasons why I shared my pattern primer and Dan shared his Pears theme for Wordpress:

Breaking interfaces down into patterns has been immensely helpful in learning and re-evaluating the best possible code to implement them.

But Pears isn’t about how I code these patterns—it’s a tool for creating your own.

I love that. These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

For that, I am very grateful.