Who Are Design Systems For?

Specific design systems, I mean. Design systems, as a concept, are something just about any site can benefit from.

A lot of hype goes into design systems these days. Just the other day, an organization’s published their design system publicly and I got a slew of DMs, emails, and Slack messages encouraging me to check it out. “Looks good to me,” I said. But I’m merely knocking on the hood of a new car, so to speak. I haven’t sat in it. I haven’t driven it around the block, let alone driven it cross-country or tried to dig Cheerios out from between the seats. I’m sure I’d have more opinions after building a site or 10 with it (excuse the mixed metaphors).

So that leads me to a few questions. Can I build a site with this design system? Should I build a site with it? Is it for me? Or wait… who is this for?

They all have accordions.

Well not all of them, but bear with me, because there is a point to be made.

Bootstrap has an accordion too! Developers totally understand Bootstrap.

Whatever you think of it, I don’t see much confusion around Bootstrap. You link up the CSS, you use the HTML they give you and — 💥 — you have components that are ready to rock.

It’s possible that Bootstrap is a more of a “pattern library” than a “design system.” I dunno. There is probably something to that distinction, but the naming semantics (if there are any) seem to be used interchangeably, so distinguishing Bootstrap as one or the other doesn’t alleviate any confusion.

Developers reach for Bootstrap because…

  • It helps them build faster.
  • They get good quality “out of the box” if they aren’t particularly great at HTML and CSS themselves.
  • They want to be accessible and Bootstrap has been through the accessibility ringer.
  • [Insert your reason.]

Appealing, yet these seem to be somewhat table stakes for any design system and not exclusive to Bootstrap alone.

Hmmmm… Maybe I’ll have a gander around and choose a non-Bootstrap solution for my next project.

A lot of people are in this boat.

Maybe the next project is React so we want a design system that makes React a first-class citizen. Maybe we had trouble customizing Bootstrap to our liking. Maybe we just saw the default look of another design system and thought that would be a better fit. Maybe we are just bored of Bootstrap. Lots of reasons to look outside of Bootstrap, just as there are lots of reasons to look to it.

Since other design systems have accordions, too, can’t I just… pick one?

Sorta?

One immediate consideration is the license. Salesforce’s Lightning Design System is often pointed to as a leader in the world of design systems and has influenced a lot of the current thinking around them. Yet, it is not open source licensed. Actually, it is open source licensed. It uses BSD Clause-3 (MIT-like) for everything but the fonts and icons, which are Creative Commons Attribution-NoDerivatives 4.0. I’m told: “anyone could reuse the code in their project that don’t have anything to do with Salesforce. They just can’t reuse it in a way that’s mimicking the system too closely.”

That’s not a problem — it’s probably a good thing for Lightning. It’s not a general purpose grab-it-and-go for all web developers on Earth as the target audience. It’s for Salesforce and the slew of teams on different development stacks building things for Salesforce. If you’re not building a Salesforce thing, it’s not for you.

Then why is it public and not some internal document for the Salesforce team? I can’t answer for them, but as I understand it, Salesforce is so enormous that they have both internal and external teams using it. So, perhaps making Lightning a public document is the most useful way to make it available to everyone who needs it.

There’s also the nice side effect that they get good press for it, and that can’t hurt hiring efforts. I’ve also heard having a public design system can spark interesting and useful conversations.

Carbon Design System, on the other hand, is open source licensed. They also have an entire section explaining who should use the system:

Carbon is the official implementation of the IBM Design Language for product and web designers, and represents an ever-growing ecosystem of design assets and guidance. With a comprehensive set of human interface guidelines, design kits, and documentation, Carbon helps designers work faster and smarter.

That doesn’t quite tell me what I want to know. It looks like IBM stuff out of the box, so it’s definitely for IBM.

It’s open source so I can use it if I want to. But is it really for me and my random projects? Do they want me to use it for that? Am I, random developer, who they are thinking about with this project? Or is it IBM-first, random developer second?

Company first, the world second.

If a design system is by a company, then it’s for the company. It might also be open source, but any ol’ random developer who wants to use it isn’t the target audience.

It might not even technically be a company who makes it. It could be a government!

One really great design system is the U.S. Web Design System, which just went 2.0. It’s gorgeous! It looks very complete and has some great features. It’s got a classy custom font, it was designed with incremental adoption in mind, it has both useful components as well as utilities, and was built atomically from design tokens. Perhaps the best feature is that it’s extremely accessible because it has to be by law.

The U.S. Web Design System is mostly public domain, so you totally can use it. But it’s not designed with you in mind; it’s designed to help people who make website for the government.

(By the way, The U.S. Web Design System is open to contribution, which is pretty cool because it’s a way you could make a significant impact on websites that are very important to people’s lives.)

Here’s another kicker: There is a spectrum of customizability to design systems, on purpose.

Even if you technically can use a public design system you’ve found and like, you might consider the customizability angle. There is a whole spectrum to this, but let’s consider the extreme edges and middle:

  • Zero Customizability: We built this to strongly enforce consistency for ourselves.
  • Pre-Selected Variations: We’ve got accordions in three different colors.
  • BYO Theme: We’ll give you a skeleton that loosely achieves the pattern and you apply the styles to your liking.

There are design systems at all points on this spectrum. Bootstrap might be in between the last two, where you get a fully styled theme, but customizability largely comes via setting Sass variables and that creates infinite variations.

Polaris, Shopify’s design system, is open source, but definitely for Shopify stuff. They are intentionally not trying to do what Bootstrap does (they tell me). It’s far more about enforced consistency and adhering to a cohesive brand than it is slapping together and customizing a page.

Material Design is definitely Google’s thing. The story of Material Design is that Google has an absolute crapload of products across all sorts of platforms. This could so easily become a mess of inconsistent design and branding. Instead, Google develops Material Design and successfully ships it across what seems like their entire empire. An incredible success story in design systems. So I don’t think it’s off base to say that Material Design is by-Google for-Google.

But these days, they definitely encourage other developers to use it too. By default, that makes your thing look like a Google thing.

But they are actively trying to make Material Design more customizable so you can bring your own brand. So far, it looks like there is a Sketch plugin that helps with that. For us coders, their Material Components repo looks like it is built with Sass and many things are set up with variables you can override. See this tutorial about customizing.

There are lots of success stories with customizing Material Design. Companies like Lyft, Zappos, and NPR, who all have strong brand identities of their own, all use customized Material Design.

That makes the messaging for Material Design all the more tricky and interesting. It’s very definitely for Google, but clearly it’s also very definitely intended for anyone else who wants to use it. That messaging just might work as Google has the resources and perception to pull that off in a way that I would think it’s harder for other company-branded design systems to do.


In case this isn’t obvious (and I very much fear that it isn’t), design systems aren’t a commodity. We don’t get to simply pick the one that has the nicest accordion and use it on the next project. We might not even be allowed to use it. It might be intentionally branded for a specific company. There are all kinds of factors to consider here.

My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.

I’d also like to note that everyone who I’ve brought this up to in the last few weeks has had different opinions about all this target audience messaging stuff in design systems. Of course, I’d love to read your comments about how you feel about it.

The post Who Are Design Systems For? appeared first on CSS-Tricks.

Revisiting the Rendering Tier

Have you ever created a well-intentioned, thoughtful design system only to watch it grow into an ever-increasing and scary codebase? I’ve been working in sort of the opposite direction, inheriting the scary codebase and trying to create a thoughtful system from it.

Here’s Alex Sanders on the topic, explaining how his team at The Guardian has tackled the task of creating design systems while combating complexity:

Systems that try to contain complexity over long periods of time by convention will inevitably tend toward entropy, because one significant characteristic of convention is that it is trivially simple to break one.

You do not even need to be malicious. A convention is not a line in the sand. You can have a very good case for breaking or stretching one, but once a convention is no longer fully observed, subsequent cases for breaking or stretching it are automatically stronger, because the convention is already weakened. The more this happens, the weaker it gets.

Complexity and entropy can be two outcomes in the same situation, but need not be mutually exclusive. Interesting to think that our best intentions to guard against complexity can be somewhat destructive.

I also love how Alex explains why it’s not possible for their team to use a Tachyons-esque approach to writing styles because of the way that their development environment is kinda slow. It would be painful for the team to make that switch, despite how it could solve some other problems. This reminded me that measuring problems in this way is why there can never be a single way to write CSS. We need that inherent flexibility, even at the expense of introducing inconsistencies. Hence, conventions being less of a line in the sand and more of a guide post.

On a separate note, I really like how Alex describes styles and attributes as the reasons why his team is writing those styles. It’s about aligning with business objectives:

…tens of thousands of rules that are intended to describe a maintainable set of responses to business and design problems.

That’s interesting since I don’t think we spend much time here talking specifically about the business side of CSS and the functional requirements that a styled user interface needs to accomplish.

And perhaps thinking about that can help us write better styles in the long term. Is this line of CSS solving a problem? Does this new class resolve an issue that will help our customers? These are good questions to keep in mind as we work, yet I know I don’t spend enough time thinking about them. I often see the design I’m turning into code as a problem to be solved instead.

Perhaps we should expand the way we styling a webpage because maybe, just maybe, it will help us write more maintainable code that’s built to solve a real business objective.

Direct Link to ArticlePermalink

The post Revisiting the Rendering Tier appeared first on CSS-Tricks.

Design Systems and Portfolios

In my experience working with design systems, I’ve found that I have to sacrifice my portfolio to do it well. Unlike a lot of other design work where it’s relatively easy to present Dribbble-worthy interfaces and designs, I fear that systems are quite a bit trickier than that.

You could make things beautiful, but the best work that happens on a design systems team often isn’t beautiful. In fact, a lot of the best work isn’t even visible.

For example, most days I’m pairing up with folks on my team to help them understand how our system works; from the CSS architecture, to the font stack, to the UI Kit to how a component can be manipulated to solve a specific problem, to many things in between. I’m trying as best as I can to help other designers understand what would be hard to build and what would be easy, as well as when to change their designs based on technical or other design constraints.

Further, there’s a lot of hard and diligent work that goes into projects that have no visible impact on the system at all. Last week, I noticed a weird thing with our checkboxes. Our Checkbox React component would output HTML like this:

<div class="checkbox"> <label for="ch-1"> <input id="ch-1" type="checkbox" class="checkbox" /> </label>
</div>

We needed to wrap the checkbox with a <div> for styling purposes and, from a quick glance, there’s nothing wrong with this markup. However, the <div> and the <input> both have a class of .checkbox and there were confusing styles in the CSS file that styled the <div> first and then un-did those styles to fix the <input> itself.

The fix for this is a pretty simple one: all we need to do is make sure that the class names are specific so that we can safely refactor any confusing CSS:

<div class="checkbox-wrapper"> <label for="ch-1"> <input id="ch-1" type="checkbox" class="checkbox" /> </label>
</div>

The thing is that this work took more than a week to ship because we had to refactor a ton of checkboxes in our app to behave in the same way and make sure that they were all using the same component. These checkboxes are one of those things that are now significantly better and less confusing, but it’s difficult to make it look sexy in a portfolio. I can’t simply drop them into a big iPhone mockup and rotate it as part of a fancy portfolio post if I wanted to write about my work or show it to someone else.

Take another example: I spent an entire day making an audit of our illustrations to help our team get an understanding of how we use them in our application. I opened up Figma and took dozens of screenshots:

It’s sort of hard to take credit for this work because the heavy lifting is really moderating a discussion and helping the team plan. It’s important work! But I feel like it’s hard to show that this work is valuable and to show the effects of it in a large org. “Things are now less confusing,” isn’t exactly a great accomplishment – but it really should be. These boring, methodical changes are vital for the health of a good design system.

Also… it’s kind of weird to putm “I wrote documentation” in a portfolio as much as it is to say, “I paired with designers and engineers for three years.” It’s certainly less satisfying than a big, glossy JPEG of a cool interface you designed. And I’m not sure if this is the same everywhere, but only about 10% of the work I do is visual and worthy of showing off.

My point is that building new components like this RadioCard I designed a while back is extraordinarily rare and accounts for a tiny amount of the useful work that I do:

See the Pen
Gusto App – RadioCard Prototype
by Robin Rendle (@robinrendle)
on CodePen.

I’d love to see how you’re dealing with this problem though. How do you show off your front-end and design systems work? How do you make it visible and valuable in your organization? Let me know in the comments!

The post Design Systems and Portfolios appeared first on CSS-Tricks.

The Elements of UI Engineering

I really enjoyed this post by Dan Abramov. He defines his work as a UI engineer and I especially like what he writes about his learning experience:

My biggest learning breakthroughs weren’t about a particular technology. Rather, I learned the most when I struggled to solve a particular UI problem. Sometimes, I would later discover libraries or patterns that helped me. In other cases, I’d come up with my own solutions (both good and bad ones).

It’s this combination of understanding the problems, experimenting with the solutions, and applying different strategies that led to the most rewarding learning experiences in my life. This post focuses on just the problems.

He then breaks those problems down into a dozen different areas: consistency, responsiveness, latency, navigation, staleness, entropy, priority, accessibility, internationalization, delivery, resilience, and abstraction. This is a pretty good list of what a front-end developer has to be concerned about on a day-to-day basis, but I also feel like this is perhaps the best description of what I believe my own skills are besides being “the person who cares about component design and CSS.”

I also love what Dan has to say about accessibility:

Inaccessible websites are not a niche problem. For example, in UK disability affects 1 in 5 people. (Here’s a nice infographic.) I’ve felt this personally too. Though I’m only 26, I struggle to read websites with thin fonts and low contrast. I try to use the trackpad less often, and I dread the day I’ll have to navigate poorly implemented websites by keyboard. We need to make our apps not horrible to people with difficulties — and the good news is that there’s a lot of low-hanging fruit. It starts with education and tooling. But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought?

This is a good reminder that front-end development is not a problem to be solved, except I reckon Dan’s post is more helpful and less snarky than my take on it.

Anywho, we all want accessible interfaces so that every browser can access our work making use of beautiful and consistent mobile interactions, instantaneous performance, and a design system teams can utilize to click-clack components together with little-to-no effort. But these things are only possible if others recognize that UI and front-end development are a worthy fields.

Direct Link to ArticlePermalink

The post The Elements of UI Engineering appeared first on CSS-Tricks.

Creating the “Perfect” CSS System

My pal Lindsay Grizzard wrote about creating a CSS system that works across an organization and all of the things to keep in mind when starting a new project:

Getting other developers and designers to use the standardized rules is essential. When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM. You can explore working around this with linters, but forcing people to use a naming convention they hate isn’t going to make your job any easier. Hopefully, you will be able to convince them why the extra underscores are useful, but finding a middle ground where everyone will participate in some type of system is the priority.

I totally agree and the important point I noted here is that all of this work is a collaborative process and compromise is vital when making a system of styles that are scalable and cohesive. In my experience, at least, it’s real easy to walk into a room with all the rules written down and new guidelines ready to be enforced, but that never works out in the end.

Ethan Marcotte riffed on Lindsay’s post in an article called Weft and described why that’s not always a successful approach:

Broad strokes here, but I feel our industry tends to invert Lindsay’s model: we often start by identifying a technical solution to a problem, before understanding its broader context. Put another way, I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Direct Link to Article — Permalink

The post Creating the “Perfect” CSS System appeared first on CSS-Tricks.

Developing a design environment

Jules Forrest discusses some of the work that her team at Credit Karma has been up to when it comes to design systems. Jules writes:

…in most engineering organizations, you spend your whole first day setting up your development environment so you can actually ship code. It’s generally pretty tedious and no one likes doing it, but it’s this thing you do to contribute meaningful work to production. Which got me thinking, what would it look like to make it easier for designers to design for production?

That’s what Jules calls a “design environment” and she’s even written a whole bunch of documentation in Thread, Credit Karma’s design system, for designers on their team to get that design environment up and running. That’s stuff like fonts, Sketch plugins, and other useful assets:

These problems have certainly been tackled by other teams in the past but this is the first time I’ve heard the phrase “design environment” before and I sort of love the heck out of it. Oh, and this post reminds me of a piece by Jon Gold where he wrote about Painting with Code.

Direct Link to Article — Permalink

The post Developing a design environment appeared first on CSS-Tricks.

designsystems.com

The team at Figma has created a new resource for “learning, creating and evangelizing design systems” called Design Systems that already has a good collection of interviews and articles by some folks thinking about these things.

I particularly liked Jeroen Ransijn’s post on how to convince your company it’s ready for a design system, where he writes:

Building a design system is not about reaching a single point in time. It’s an ongoing process of learning, building, evangelizing and driving adoption in your organization.

Design systems are a popular topic. Ethan Marcotte recently looked at instances where patterns get weird, Lucan Lemonnier shared a process for creating a consistent design system in Sketch, and Brad Frost debunked the perception that design systems are rigid. Seems like Figma’s new site will be a nice curated repository of this ongoing discussion.

Direct Link to Article — Permalink

The post designsystems.com appeared first on CSS-Tricks.

Creating Themeable Design Systems

Brad frost picks up the ongoing conversation about design systems. Where many posts seem to center on how to create one and how to enforce it, the big takeaway here is that design systems are not synonymous with constraints. They’re only as strict as we make them and new CSS features like custom properties actually open up new creative possibilities—something Andres Galante and Cliff Pyles recently pitched right here on CSS-Tricks.

Brad:

The aesthetic layer is often the most malleable layer of the frontend stack, which means that we can create systems that allow for a lot of aesthetic flexibility while still retaining a solid underlying structural foundation.

This not only sounds right, but puts a strong punctuation on why we love CSS: it’s a set of styles that can be applied an infinite number of ways to the same HTML markup. A new layer of paint can be slapped on at any time, but the beams, walls and ceiling of the building can remain constant. Dave Rupert’s personal site is a prime example of this and he details his approach to theming.

Ah, CSS Zen Garden…

Direct Link to Article — Permalink

The post Creating Themeable Design Systems appeared first on CSS-Tricks.

Vue Design System

We talk a lot about Vue around here, including some practical applications of it, but haven’t gotten deep into designing for it. In this post, Viljami Salminen describes his Vue design process and the thinking that led him to build the Vue Design System:

A design system can help establish a common vocabulary between everyone in an organization and ease the collabo­ration between different disciplines. I’ve seen it go the other way around too when important decisions have been made in a rush. To avoid that, Vue Design System introduces the following framework for naming that I’ve found working well in the past…

Viljami lists Design Principles, Tokens, Elements, Patterns, and Templates as the way in which he structures a system and I think it’s a pretty interesting approach and a parallel to Lucas Lemonnier’s post on creating design systems in Sketch, using Atomic Design as the structure. I particularly like how Viljami fits everything together in the example style guide that’s provided.

Direct Link to Article — Permalink

The post Vue Design System appeared first on CSS-Tricks.