Tuesday, February 4th, 2020
Friday, December 13th, 2019
At the risk of being a broken record; HTML really needs
<tooltip>elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements.
I wish browsers would prioritize accessibility improvements over things like main thread scheduling optimization to unblock tracking pixels and the Sisyphean task of competing with native.
If we really want to win, let’s make it easy for everyone to access the Web.
Wednesday, December 11th, 2019
The Technical Side of Design Systems by Brad Frost
You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.
I will attempt to liveblog the Frostmeister…
“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.
A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.
A design system the story of how an organisation gets things done.
When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.
Brad’s going to talk through the life cycle of a project.
He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:
- Reduce technical debt—less frontend spaghetti code.
- Faster production—less time coding common UI components and more time building real features.
- Higher-quality production—bake in and enforce best practices.
- Reduce QA efforts—centralise some QA tasks.
- Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
- Useful reference—an essential resource hub for development best practices.
- Future-friendly foundation—modify, extend, and improve over time.
Once you’ve explained the benefits, it’s time to kick off.
Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.
How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.
Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.
How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.
Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.
Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?
You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.
Design and build
Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:
Embrace the snowflakes.
The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.
When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.
The design system informs our product design. Our product design informs the design system.
Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.
So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.
It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.
The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.
Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.
You can bake best practices into your design system. You can make accessibility a requirement in the code.
What does it mean to “launch” a design system?
A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.
There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:
- Least integrated: static.
- Front-end reference code.
- Most integrated: consumable compents.
Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.
Consumable UI components need to be bundled, packaged, and published.
Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.
A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.
What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.
That’s where design tokens come in. You can define your design language in a platform-agnostic way.
This is hard.
- Your design system must live in the technologies your products use.
- Look at your product roadmaps for design system pilot project opportunities.
- Establish code conventions and use tooling and process to enforce them.
- Build your design system and pilot project UI screens in a frontend workshop environment.
- Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
- Use semantic versioning to manage ongoing design system product work.
- Use design tokens to feed common design properties into different platforms.
You won’t do it all at once. That’s okay. Baby steps.
Tuesday, December 10th, 2019
The Mythology of Design Systems by Mina Markham
Design systems have dominated web design conversations for a few years. Just as there’s no one way to make a website, there is no one way to make a design system. Unfortunately this has led to a lot of misconceptions around the creation and impact of this increasingly important tool.
Drawing on her experiences building design systems at two highly visible and vastly different organizations, Mina will debunk some common myths surrounding design systems.
Mina is a designer who codes. Or an engineer who designs. She makes websites. She works at Slack, but she doesn’t work on the product; she works on slack.com and the Slack blog. Mina also makes design systems. She loves design systems!
There are some myths she’s heard about design systems that she wants to dispel. She will introduce us to some mythological creatures along the way.
Myth 1: Designers “own” the design system
Mina was once talking to a product designer about design systems and was getting excited. The product designer said, nonplussed, “Aren’t you an engineer? Why do you care?” Mina explained that she loved design systems. The product designer said “Y’know, design systems should really be run by designers” and walked away.
Mina wondered if she had caused offense. Was she stepping on someone’s toes? The encounter left her feeling sad.
Thinking about it later, she realised that the conversation about design systems is dominated by product designers. There was a recent Twitter thread where some engineers were talking about this: they felt sidelined.
The reality is that design systems should be multi-disciplinary. That means engineers but it also means other kinds of designers other than product designers too: brand designers, content designers, and so on.
What you need is a hybrid, or unicorn: someone with complimentary skills. As Jina has said, design systems themselves are hybrids. Design systems give hybrids (people) a home. Hybrids help bring unity to an organization.
Myth 2: design systems kill creativity
Mina hears this one a lot. It’s intertwined with some other myths: that design systems don’t work for editorial content, and that design systems are just a collection of components.
Components are like mermaids. Everyone knows what one is supposed to look like, and they can take many shapes.
But if you focus purely on components, then yes, you’re going to get frustrated by a feeling of lacking creativity. Mina quotes @brijanp saying “Great job scrapbookers”.
Design systems encompass more than components:
- High level principles.
- Brand guidelines.
- Coding standards.
- Accessibility compliance.
A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.
Rules and creativity are not mutually exclusive. Rules can be broken.
For a long time, Mina battled against one-off components. But then she realised that if they kept coming up, there must be a reason for them. There is a time and place for diverging from the system.
It’s like Alice Lee says about illustrations at Slack:
There’s a time and place for both—illustrations as stock components, and illustrations as intentional complex extensions of your specific brand.
Your design system is your pantry, not your cookbook.
If you keep combining your ingredients in the same way, then yes, you’ll keep getting the same cake. But if you combine them in different ways, there’s a lot of room for creativity. Find the key moments of brand expression.
There are strict and loose systems.
Strict design systems are what we usually think of. AirBnB’s design system is a good example. It’s detailed and tightly controlled.
A loose design system will leave more space for experimentation. TED’s design system consists of brand colours and wireframes. Everything else is left to you:
Consistency is good only insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context justifies it.
A good design sytem helps you improvise.
Thinking about strict vs. loose reminds Mina of product vs. marketing. A design system for a product might need to be pixel perfect, whereas editorial design might need more breathing room.
Mina has learned to stop fighting the one-off snowflake components in a system. You want to enable the snowflakes without abandoning the system entirely.
A loose system is key for maintaining consistency while allowing for exploration and creativity.
Myth 3: a design system is a side project
Brad guffaws at this one.
Okay, maybe no one has said this out loud, but you definitely see a company’s priorities focused on customer-facing features. A design system is seen as something for internal use only. “We’ll get to this later” is a common refrain.
“Later” is a mythical creature—a phoenix that will supposedly rise from the ashes of completed projects. Mina has never seen a phoenix. You never see “later” on a roadmap.
Don’t treat your design system as a second-class system. If you do, it will not mature. It won’t get enough time and resources. Design systems require real investment.
Mina has heard from people trying to start design systems getting the advice, “Just do it!” It seems like good advice, but it could be dangerous. It sets you up for failure (and burnout). “Just doing it” without support is setting people up for a bad experience.
The alternative is to put it on the roadmap. But…
Myth 4: a design system should be on the product roadmap
At a previous company, Mina once put a design system on the product roadmap because she saw it wasn’t getting the attention it needed. The answer came back: nah. Mina was annoyed. She had tried to “just do it” and now when she tried to do it through the right channels, she’s told she can’t.
But Mina realised that it’s not that simple. There are important metrics she might not have been aware of.
A roadmap is multi-faceted thing, like Cerebus, the three-headed dog of the underworld.
Okay, so you can’t put the design sytem on the roadmap, but you can tie it to something with a high priority. You could refactor your way to a design system. Or you could allocate room in your timeline to slip in design systems work (pad your estimates a little). This is like a compromise between “Just do it!” and “Put it on the roadmap.”
A system’s value is realized when products ship features that use a system’s parts.
The other problem with putting a design system on the roadmap is that it implies there’s an end date. But a design system is never finished (unless you abandon it).
Myth 5: our system should do what XYZ’s system did
It’s great that there are so many public design systems out there to look to and get inspired by. We can learn from them. “Let’s do that!”
But those inspiring public systems can be like a succubus. They’re powerful and seductive and might seem fun at first but ultimately leave you feeling intimidated and exhausted.
Your design system should be build for your company’s specific needs, not Google’s or Github’s or anyone’s.
Slack has multiple systems. There’s one for the product called Slack Kit. It’s got great documentation. But if you go on Slack’s marketing website, it doesn’t look like the product. It doesn’t use the same typography or even colour scheme. So it can’t use the existing the design system. Mina created the Spacesuit design system specifically for the marketing site. The two systems are quite different but they have some common goals:
- Establish common language.
- Reduce technical debt.
- Allow for modularity.
But there are many different needs between the Slack client and the marketing site. Also the marketing site doesn’t have the same resources as the Slack client.
Be inspired by other design systems, but don’t expect the same resutls.
Myth 6: everything is awesome!
When you think about design systems, everything is nice and neat and orderly. So you make one. Then you look at someone else’s design system. Your expectations don’t match the reality. Looking at these fully-fledged design systems is like comparing Instagram to real life.
The perfect design system is an angel. It’s a benevolent creature acting as an intermediary between worlds. Perhaps you think you’ve seen one once, but you can’t be sure.
The truth is that design system work is like laying down the railway tracks while the train is moving.
For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing codebase.
Mina got to do a complete redesign in 2017, accompanied by a design system. The design system would power the redesign. Everything was looking good. Then slowly as the rest of the team started building more components for the website, unconnected things seemed to be breaking. This is what design systems are supposed to solve. But people were creating multiple components that did the same thing. Work was happening on a deadline.
Even on the Hillary For America design system (Pantsuit), which seemed lovely and awesome on the outside, there were multiple components that did the same thing. The CSS got out of hand with some very convoluted selectors trying to make things flexible.
Mina wants to share those stories because it sometimes seems that we only share the success stories.
Share work in progress. Learn out in the open. Be more vulnerable, authentic, and real.
Saturday, November 16th, 2019
An interesting project that will research and document the language used across different design systems to name similar components.
Thursday, November 7th, 2019
I really like the work that IF are doing to document patterns around handling data:
- Signing in to a service
- Giving and removing consent
- Giving access to data
- Getting access to data
- Understanding automated decisions
- Doing security checks
Each pattern has a description, advantages, limitations, and examples.
Saturday, September 21st, 2019
There seems to be a tendency to repurpose existing solutions to other people’s problems. I propose that this is the main cause of the design sameness that we encounter on the web (and in apps) today. In our (un)conscious attempts to reduce the effort needed to do our work, we’ve become experts in choosing rather than in thinking.
A very thoughtful piece from Stephen.
When we use existing solutions or patterns, we use a different kind of thinking. Our focus is on finding which pattern will work for us. Too quickly, we turn our attention away from closely examining the problem.
Wednesday, September 11th, 2019
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
- Current design systems thinking limits free, playful expression.
- Design systems uncover organisational disfunction.
- Continual design improvement and delivery is a lie.
- Component-focussed design is siloed thinking.
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
Tuesday, September 3rd, 2019
Making the case for moving your navigation to the bottom of the screen on mobile:
Phones are getting bigger, and some parts of the screen are easier to interact with than others. Having the hamburger menu at the top provides too big of an interaction cost, and we have a large number of amazing mobile app designs that utilize the bottom part of the screen. Maybe it’s time for the web design world to start using these ideas on websites as well?
Friday, August 23rd, 2019
This is a really interesting distinction:
An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.
An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).
It’s certainly true that intentional design systems will invariably bake in a number of (unproven?) assumptions.
Thursday, August 22nd, 2019
Keep what you need, delete what you don’t and add whatever you like on top of whats already there.
Friday, August 9th, 2019
The good folks at Sparkbox ran a survey on design systems. Here are the results, presented in a flagrantly anti-Tufte manner.
Saturday, August 3rd, 2019
This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.
Tuesday, July 23rd, 2019
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.
On Twitter, Chris mentioned that “It would be nice if the talks had their topic listed,” which is a fair point. So here goes:
- Yaili’s talk is about design systems,
- Amy’s talk is about design systems,
- Danielle’s talk is about design systems,
- Varya’s talk is about design systems,
- Emil’s talk is about design systems, and
- Heydon’s talk is about a large seabird.
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.
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.
Sunday, July 21st, 2019
A case study from Twitter on the benefits of using a design system:
With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.
I think that could be boiled down to this:
Component-based design favours composition over invention.
I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.
Monday, July 15th, 2019
Mike follows up on the changes made by email startup Superhuman after his initial post:
I will say this: if you were skeptical of Superhuman’s commitment to privacy and safety after reading the last article, you should probably be even more skeptical after these changes. The company’s efforts demonstrate a desire to tamp down liability and damage to their brand, but they do not show an understanding of the core problem: you should not build software that surreptitiously collects data on people in a way that would surprise and frighten them.
Wednesday, July 3rd, 2019
A really excellent analysis by Mike of a dark pattern in the Superhuman email app.
That’s right. A running log of every single time you have opened my email, including your location when you opened it. Before we continue, ask yourself if you expect this information to be collected on you and relayed back to your parent, your child, your spouse, your co-worker, a salesperson, an ex, a random stranger, or a stalker every time you read an email.
Exactly! This violates the principle of least surprise. Also, it’s just plain wrong.
Amazingly though, Mike has been getting pushback from guys on Twitter (and it’s always guys) who don’t think this is a big deal.
Anyway, read the whole thing—it’s fair, balanced, and really well written.
Monday, July 1st, 2019
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.
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.
Well done for yet another fantastic event. The calibre of speakers was so high, and it was reassuring to hear they have the same trials, questions and toil with their libraries. So insightful, so entertaining.— Barry Bloye (@barrybloye) June 29, 2019
Had the most amazing time at the #PatternsDay, catching up with old friends over slightly mad conversations. Huge thanks to @adactio and @clearleft for putting together such warm and welcoming event, and to all the attendees and speakers for making it so special ❤️— Alla Kholmatova (@craftui) June 29, 2019
Had a blast at #PatternsDay !!! Met so many cool ppl— trash bandicoot (@freezydorito) June 28, 2019
I’ve had a hell of a good time at #PatternsDay. It’s been nice to finally meet so many folks that I only get to speak to on here.— Andy Bell (@andybelldesign) June 28, 2019
As expected, the @clearleft folks all did a stellar job of running a great event for us.
An amazing day was had at #PatternsDay. Caught up with friends I hadn’t seen for a while, made some new ones, and had my brain expand by an excellent set of talks. Big hugs to @adactio and the @clearleft team. Blog post to follow next week, once I’ve got my notes in order.— Garrett Coakley (@garrettc) June 28, 2019
Rachel makes the case for integrating content design patterns into component libraries:
Instead of content design systems and visual design systems existing in isolation, the ideal is one design system that accommodates everything, marrying the content and design together in the way it will actually be used and experienced.
Sunday, June 30th, 2019
Amy’s talk at Patterns Day was absolutely brilliant! Here’s an account of the day from her perspective.
The evident care Jeremy put into assembling the lineup meant an incredible mix of talks, covering the big picture stuff right down to the nitty gritty, and plenty in between.
Her observation about pre-talk nerves is spot-on:
I say all of this because it’s important for me and I think anyone who suffers with anxiety about public speaking, or in general, to recognise that having a sense of impending doom doesn’t mean that doom is actually impending.