Tag: Systems

Sass !default and themeable design systems

This is a great blog post from Brad Frost where he walks us through an interesting example. Let’s say we’re making a theme and we have some Sass like this:

.c-text-input {   background-color: $  form-background-color;   padding: 10px }

If the $ form-background-color variable isn’t defined then we don’t want the background-color to be outputted in our CSS at all. In fact, we want our output to look like this instead:

.c-text-input {   padding: 10px; }

See? No background-color property. As Brad shows, that’s possible today with Sass’s !default flag. You can use it like this as you’re setting up the variable:

$  form-background-color: null !default;  .c-text-input {   background-color: $  form-background-color; /* this line won’t exist in the outputted CSS file */   padding: 10px; }  $  form-background-color: red;  .c-text-input-fancy {   background-color: $  form-background-color; /* this line will be “red” because we defined the variable */   padding: 10px; }

It’s a really useful thing to remember if you want to ensure your CSS is as small as it can be while you’re creating complex themes with Sass.

Direct Link to ArticlePermalink

The post Sass !default and themeable design systems appeared first on CSS-Tricks.

CSS-Tricks

, , , ,

Design Systems Blogathon

It was fun watching a bunch of back and forth blogging between a bunch of smart people quoting a bunch of smart people last week. If you missed it, you might wanna start at the end and work backward.

I only have one tidbit to add. I don’t do much with design systems as someone who works on pretty small teams, any of which have found a system that works for them that doesn’t involve what anyone would probably call a design system. When we have intentionally wandered in the direction of a design system, we found ourselves not as architects or gardeners, but as zookeepers. We were just documenting what we already had, which was fine as an exercise, but not particularly useful in practice. Again, just for us.

The post Design Systems Blogathon appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Systems, Mistakes, and the Sea

Our own Robin Rendle:

[…] folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them. But hiding those mistakes and shortcomings by glossing over everything doesn’t just make it harder for us personally, it hinders progress within the field itself.

I’ve always tried to be super open about the things I do, good and bad. However, even the outlets I have, like CodePen Radio where we talk about the rollercoaster of running a software business, there are still things I’ve held back because they just aren’t a good look. Often, the trick is to let some time pass so that it can be a retrospective later if there’s hesitance to post about the bad today.

Direct Link to ArticlePermalink

The post Systems, Mistakes, and the Sea appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

Design APIs: The Evolution of Design Systems

A clever idea from Matthew Ström:

[…] design APIs don’t seem like a stretch of the imagination. An API-driven approach is the natural extension of the work currently being done on design systems, including tokens and standardization projects.

If you buy into the idea of design tokens, that expresses itself as a chunk of JSON with things like colors and spacing values. No reason an API couldn’t deliver that, potentially empowering a build process that pulls the most recent decisions from a central location.

Direct Link to ArticlePermalink

The post Design APIs: The Evolution of Design Systems appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Smarter Design Systems Tools

What has me really excited about building websites is largely around design systems and the design tools we use to build them. Though, design systems are certainly not limited to websites.

Closing the Gap

In the ever-so-hot-right-now world of design systems, one of the most common phrases people use is “bridging the gap” (between designers and engineers). This was on several résumés I reviewed during my time at Salesforce when we were hiring for the Lightning Design System team. It’s a fair endeavor to strive for, as we want to bring alignment, coherence, and unity to our product design and engineering — all with the goal of having a quality-consistent experience for the people using our products and services.

However, “bridging the gap” still implies there is a gap. Why is that gap there in the first place? Is it due to many years of legacy process and workflows that still seep into our day to day work? I could see legacy being a real-world scenario need to work through. But what about newer, smaller startups? Why do many of them have a gap, too?

As a design systems practitioner, advocate, and enthusiast, I am always seeking ways to improve the people side of our work: how we meet and communicate, how we prioritize our roadmap, and how we can iterate on our process and way of working. However, another piece of this are the tools we use.

Some of our tools have come quite a long way, and it certainly seems that a new one is announced pretty frequently these days. But the ones that really get me excited are where I see them do more than “bridge the gap”.

A while back, when Modulz arrived at the scene, I noticed they used the hashtag, #closethegap. I couldn’t help but love that.

I’m very keen to see our design tools move away from simply bridging gaps and more toward closing them. For example, a feature I see as only bridging the gap is a “developer handoff” (which tends to rely on pixel dimensions and hex codes delivered as a spec). In my experience, delivering specs like this can promote duplication in code, inconsistencies, and are prone to errors. An example of closing the gap, however, are tools that work with actual, real, quality code instead of vector boxes.

Some tools achieve this by exposing design tokens — you can see that in InVision DSM which has tokens built-in as a feature. Another tool, Diez, is an open-source developer toolkit using tokens to turn your design language into scalable code. There are other tools like the previously mentioned Modulz, along with Interplay, that work with coded components but in a visual way. This is much better than the earlier WYSIWYG editors of the past because their generated code can be accessible and production-quality. And that’s not to leave out the other players in this space like Adobe, Figma, Framer, Sketch, UXPin, and many, many more that are also doing a lot to move this forward.

The Invisible Design System

Something I’ve been thinking a lot about is how much time we spend on making beautiful design system websites. I love looking at them. They’re great. But as our design and engineering tools get closer and closer together, will we come to a point where we don’t need the website? Can our tools surface suggestions for better accessibility, localization, performance, and usability, because our design system is baked into the tools? Just a thought.

The No-Code Movement

Webflow, which empowers people to build websites (complete with business and e-commerce features) without writing code, recently had a conference called No Code Conf. According to their website, the conference celebrates the future of visual development.

This is a movement that, while not new, is growing rapidly. In addition to building a full-featured website using Webflow, visual, declarative app-building has been explored for years at larger tech giants like Salesforce (with their Lightning App Builder) to smaller companies like Glide which let you generate an entire app from a spreadsheet. And with all of the task-based automation services such as Zapier and IFTTT, there is much you can do without writing code at all.

Now don’t get me wrong. I still love writing code, and I love seeing other designers code. I enjoy working closely with engineers as well. I’m not saying we shouldn’t code at all. But I’m excited to see us move away from a slower “throw designs over a wall” process. I want to see people able to make things without the requirement to write code. It will also be nice to move away from the tired argument on whether designers should code — and we all move toward what can we make together?

And if we can get to a point where we don’t need to bridge or close any gaps because the gap never existed at all — well that’s a pretty exciting world I want to be in.

The post Smarter Design Systems Tools appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Designing accessible color systems

The team at Stripe explores how they’re refining their color palette to make it more accessible and legible for users across all their products and interfaces. Not only that but the team built a wonderful and yet entirely bonkers app for figuring out the ideal range of colors that they needed.

We built a web interface to allow us to visualize and manipulate our color system using perceptually uniform color models. The tool gave us an immediate feedback loop while we were iterating on our colors—we could see the effect of every change.

This tool is…whoa! I would love to learn a bit more about why they built this though as it looks like it wouldn’t have been a particularly quick and easy thing to put together. I wonder if that team has to support a wide-range of colors for their charts or data-visualization UI (as complex charts can often require a much larger range of colors for comparing bits of data effectively). Either way, this is pretty inspiring work.

This somewhat harkens to a couple of techniques for enforcing accessible colors, including one that uses custom properties with calc() and rgb by Josh Bader, and another by Facundo Corradini that also uses custom properties but with hsl with conditional statements.

Direct Link to ArticlePermalink

The post Designing accessible color systems appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Drop caps & design systems

Ethan Marcotte has written up his process for how to make drop caps accessible for screen readers and browsers alike. All of that is very interesting and I’m sure I’ll use a technique like this in the near future, but the part that made me hop out of my seat is where Ethan notes his experience with design systems at Vox:

Since rolling out our new and improved drop caps, we’ve continued to iterate on them. (Including fixing a number of bugs that I, a professional web designer, introduced.) We’ve also discussed potential changes to the custom styles feature, in order to make it sustainable. But for my money, the real benefit of the work wasn’t the drop caps themselves, but the process that emerged from it.

This is something I’ve been thinking about a lot. The tricky thing to understanding design systems is that the process of creating and maintaining them is just as important than the code it uses. Sure, yes, fixing small things is very important, but the long-lasting improvements to a design system will always be around process. Why is this thing breaking? How long has it been broken for? How do we setup a way to make sure that this problem never pops up again?

Questions about process will always be the most useful questions to ask. The system will reward you for asking.

Direct Link to ArticlePermalink

The post Drop caps & design systems appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

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.

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. 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. In its early days, I feel like the messaging was that this is Google’s cohesive design work. But these days, they definitely encourage other developers to use it too. If you do, your thing will look a lot like a Google thing. Maybe that’s what you want, maybe it’s not. Either way, you should know what you’re getting into.

Google’s take on customizability so far is a Sketch plugin. They have no incentive to allow for a level of customization to make things not look like Google, because that would be antithetical to the whole thing.


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.

CSS-Tricks

,
[Top]

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.

CSS-Tricks

, ,
[Top]

A Quick CSS Audit and General Notes About Design Systems

I’ve been auditing a ton of CSS lately and thought it would be neat to jot down how I’m going about doing that. I’m sure there are a million different ways to do this depending on the size and scale of your app and how your CSS works under the hood, so please take all this with a grain of salt.

First a few disclaimers: at Gusto, the company I work for today, our engineers and designers all write in Sass and use webpack to compile those files into CSS. Our production environment minifies all that code into a single CSS file. However, our CSS is made up of three separate domains. so I downloaded them all to my desktop because I wanted to test them individually.

Here’s are those files and what they do:

  • manifest.css: a file that’s generated from all our Sass functions, mixins and contains all of our default HTML styles and utility classes.
  • components.css: a file that consists of our React components such as Button.scss, Card.scss, etc. This and manifest.css both come from our Component Library repo and are imported into our main app.
  • app.css: a collection of styles that override our components and manifest. Today, it exists in our main application repo.

After I downloaded everything, I threw them into an S3 bucket and ran them through CSS Stats. (I couldn’t find a command line tool that I liked, so I decided stuck with this tool.) The coolest thing about CSS Stats is that it provides a ton of clarity about the health and quality of a site’s CSS, and in turn, a design system. It does this by showing the number of unique font-size and unique background-color CSS declarations there are, as well as a specificity graph for that particular CSS file.

I wanted to better understand our manifest.css file first. As I mentioned, this file contains all our utility classes (such as padding-top-10px and c-salt-500) as well as our normalize and reset CSS files, so it’s pretty foundational for everything else. I started digging through the results:

There are some obvious issues here, like the fact that there are 101 unique colors and 115 unique background colors. Why is this a big deal? Well, it’s a little striking to me because our team had already made a collection of Sass functions to output a very specific number of colors. In our Figma UI Kit and variables_color.scss (which gets compiled into our manifest file, we declare a total of 68 unique colors:

So, where are all these extra colors coming from? Well, I assume that they’re coming from Bootstrap. Back when we started building the application, we hastily built on top of Bootstrap’s styles without refactoring things as we went. There was a certain moment when this started to hurt as we found visual inconsistencies across our application and hundreds of lines of code being written that simply overrode Bootstrap. In a rather gallant CSS refactor, I removed Bootstrap’s CSS from our main application and archived it inside manifest.css, waiting for the day when we could return to it and refactor it all.

These extra colors are likely come from that old Bootstrap file, but it’s probably worth investigating some more. Anyway, the real issue with this for me is that my understanding of the design system is different from what’s in the front-end. That’s a big problem! If my understanding of the design system is different from how the CSS works, then there’s enormous potential for engineers and designers to pick up on the wrong patterns and for confusion to disseminate across our organization. Think about the extra bloat and lack of maintainability, not to mention other implications.

I was reading Who Are Design Systems For? by Matthew Ström and perked up when he quotes a talk by Julie Ann-Horvath where she’s noted as saying, “a design system doesn’t exist until it’s in production.” Following the logic, it’s clear the design system I thought we had didn’t actually exist.

Going back to manifest.css though: the specificity graph for this file should be perfectly gradual and yet there are some clear spikes that show there’s probably a bit more CSS that needs to be refactored in there:

Anyway, next up is our components.css. Remember that’s the file that our styles for our components come from so I thought beforehand that it’s bound to be a little messier than our manifest file. Throwing it into CSS Stats returns the following:

CSS-Stats shows some of the same problems — like too many font sizes (what the heck is going on with that giant font size anyway?) — but there are also way too many custom colors and background-colors. I already had a hunch about what the biggest issue with this CSS file was before I started and I don’t think the problem is not shown in this data here at all.

Let me explain.

A large number of our components used to be Bootstrap files of one kind or another. Take our Accordion.jsx React component, for instance. That imports an accordion.css file which is then compiled with all the other component’s CSS into a components.css file. The problem with this is that some Accordion styles affect a lot more than just that component. CSS from this this file bleeds into other patterns and classes that aren’t tied to just one component. It’s sort of like a poison in our system and that impacts our team because it makes it difficult to reliably make changes to a single component. It also leads to a very fragile codebase.

So I guess what I’m saying here is that tools like CSS Stats are wondrous things to help us check core vital signs for CSS health, but I don’t think they’ll ever really capture the full picture.

Anyway, next up is the app.css file:

This is the “monolith” — the codebase that our design systems team is currently trying to better understand and hopefully refactor into a series of flexible and maintainable React components that others can reuse again and again.

What worries me about this codebase is the specificity of it all what happens when something changes in the manifest.css or in our components.css? Will those styles be overridden in the monolith? What will happen to the nice and tidy component styles that we import into a new project?

Subsequently, I don’t know where I stole this, but I’ve been saying it an awful lot lately — you should always be able to predict what your CSS is going to do, whether that’s a single line of code or a giant codebase of intermingled styles. That’s what design systems are all about — designing and building predictable interfaces for the future. And if our compiled CSS has all these unpredictable and unknowable parts to it, then we need to gather everyone together to fix it.

Anywho, I threw some of the data into a Dropbox Paper doc after all this to make sure we start tackling these issues and see gradual improvements over time. That looks something like this today:

How have you gone about auditing your CSS? Does your team code review CSS? Are there any tricks and tips you’d recommend? Leave a comment below!

The post A Quick CSS Audit and General Notes About Design Systems appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]