🔗 Notes from around the web

Responsive tables are a tricky thing to get right, but Bradley Taunt shows a few quick ways to make tables responsive with minimal CSS. Bradley shows how we can let folks scroll around the table with overflows, or how we can use CSS to make each table row into a card like this:

It’s a nifty trick similar to the one that Chris shared back in 2011 and it shows just how difficult it can be to get these tables working right for everyone and on every device.

👁 The Fates of Design Systems

[Robin]: I learned a very important lesson this week when it comes to design systems. It all began several months ago when I was pairing with a designer from a separate team, helping them work on a project, and trying to figure out which components from our React library can be used for their project and which would have to be entirely built from scratch.

The design looked something like this:

A user would type in their selection in the search box and items would appear beneath it. These items acted as radio buttons (so you could only select one at a time).

The problem with this design is that, as far as I knew, we didn’t have anything that supported this; no components existed in our library that could help with this search box and these elements underneath. My recommendation was simple: unfortunately, we don’t have any components that can support this pattern so that team’s engineers would have to build them. Simple enough.

A few weeks pass and a front-end engineer on my team spots how that team had been building their feature. “This is just an AutoComplete component!” he cried. And so after a grand total of twenty seconds, I realized I had given terrible advice to that team – we had a component that they could use today and avoid the future cost of the design systems team having to maintain this string of new components. Sure, the design had to change but this wasn’t a particularly big deal when it came to the user experience.

Why did this happen? I’ve been working on design systems for years now, I’ve worked on and built many of the components in our library and to some degree or another, I’ve refactored all of them.

How could I screw this up?

Well, after several sleepless nights I realized something: there’s just far too much ground to cover when it comes to our system. We have way too many components and I only understand a fraction of the whole system. In other words, even though I’ve worked at Gusto for three years there’s a limit to my understanding of how everything ties together.

What should we do about this? Well, everyone on the design systems team should be involved, or at least aware of, every proposal and bit of advice we give out.

This is because perhaps someone on my team has just spent three weeks refactoring our checkbox component and they know for a fact that it can’t be used in a certain way. Or perhaps someone else spots a Card component being implemented in a way that would require extending that component’s styles. Whereas little old me would have no knowledge of this because I cannot keep all the code and all the variability of the system in my head.

No wonder designers and other engineers who don’t work on the design system struggle with this stuff!

I realized that together us three front-end engineers on the design systems team are like the mythological Fates in the 1997 Disney film Hercules. We’re all-powerful and brilliant, sure yes, and we can see problems of the system in the future – but! – each of us can only understand a fraction of the whole system at a time.

We’re trading our knowledge of the system, a single eyeball, between the three of us.

Separate us in a meeting with a designer or an engineer and we become mostly useless, or at least not as informed as we ought to be. And I think we’re always going to give bad advice that way.

But throw us all on the same problem at the same time? Well, together we can then act as a single voice and maintain the integrity of our design system for years to come. Plus, no-one can then blame me for bad decisions!

🔗 Links from around the web

Here’s a neat CSS trick by Tobias Ahlin where he shows us how to make boxes with smoother box-shadows:

On the left is the box with a regular box-shadow, and on the right is the one that Tobias prefers which is made with multiple box-shadows stacked on top of one another. Pretty nifty stuff.