? 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!
? From the Blog
Adaptive Photo Layout with Flexbox
Tim Van Damme built a really nifty and yet rather simple masonry layout that aligns photos in the same style as Photos.app, Flickr, and Google Photos. It happens to look like this:
The fascinating thing about this is that Tim managed to make this with only 17 lines of CSS using
flexbox and one of my very own favorite properties
object-fit. Several years ago we wrote a post that digs into this CSS property and explains all the nifty ways in which it can alter the dimensions of an image.
There are so many useful applications for
object-fit and Tim certainly shows us what’s possible if we’re sure to experiment a little. Oh and make sure to check out how his demo works when you change the size of the browser, because that’s super nifty too.
Demonstrating Reusable React Components in a Form
Kingsley Silas takes a look at his preferred method for making a consistent, reusable, and developer-friendly system of React components where he writes:
If we want to make any changes to how the input functions, we can make those changes inside the FormInput component file we created and they will be applied to every instance where the input component is used. That’s the fundamental upside to having reusable components: you don’t have to repeat yourself.
The nifty thing about this approach to building React components is that you can then upgrade the user experience of your entire application with just a little bit of typing. In Kingsley’s example that he shows, you could easily update the accessibility of all forms, buttons, or inputs, just by updating a couple of files.
The Many Ways to Link Up Shapes and Images with HTML and CSS
Bailey Jones has a ton of advice here about how to best make certain parts of an image or SVG linkable without having to lose out on accessibility best practices. She writes:
Different website designs often call for a shape other than a square or rectangle to respond to a click event. Perhaps your site has some kind of tilted or curved banner where the click area would be awkwardly large as a straight rectangle. Or you have a large uniquely shaped logo where you only want that unique shape to be clickable. Or you have an interactive image that responds differently when different regions of it are clicked.
Here’s one example of that where you might only want to make one part of a shape the link:
Random notes from a JAMstack Roundtable
Chris hosted a conversation all about JAMstack at the Web Unleashed a couple of weeks ago and made a ton of interesting notes:
- There is no denying that Static Site Generators and JAMstack are BFF. But JAMstack wants you to think bigger. What if you can’t render everything because you have 50,000 product pages and generation is too slow or otherwise impractical? No problem, you can prerender other pages but just a shell for the product pages and hit an API for product page data as needed. What if some pages just absolutely can’t be statically hosted? No problem, you can proxy the ones that can to a static server and leave the rest alone. Want to go all-in on the static hosting, but need servers for certain functionality? Consider serverless functions, which are sort of like the backend spiritual partner to static hosting.
Ultimately Chris asks why should we care about this whole JAMstack approach to building websites (which you can learn more about over on the JAMstack website). Well, Chris argues that:
perhaps the most compelling answers to why come down to speed, security, and resiliency, all of which come along for the ride immediately when you go JAMstack. It provides a hell of a foundation to build on.
Automate manual QA to catch visual UI bugs and get continuous visual coverage. With Percy’s all-in-one visual testing and review platform, it’s easy to test your UI across browsers and screens on every pull request.