Earlier this week, I watched this fantastic talk by Ethan Marcotte about the current state of design systems and I haven’t been able to stop thinking about it. The part that really stuck out to me though was this bit:
Creating modular components isn’t the primary goal or even the primary benefit of creating a design system. And what’s more, a focus on process and people always leads to more sustainable systems.
I love this talk but I find that a lot of the writing about design systems work out there focuses on how to make good docs, how to make things accessible, building marketing sites for your system, or focusing on color contrast. But I think the big weird problem about design systems that no one really talks about is that it can become extremely political.
I tend to forget this because I get so bogged down in the details of a design system, like caring about typography or refactoring CSS, etc. But as much as those details should be sweated, they can sometimes get in the way of bigger improvements that need to be made when it comes to the culture of your organization.
Design systems isn’t just about components, but as Ethan mentions in that talk, it’s about people and process. (I’m repeating this for myself because I keep forgetting that.) What does that really mean? Well, sometimes it’s a better use of your time to try and hire a team instead of fixing this one tiny problem with your docs. Or maybe not a team but just making the case to hire a dedicated front-end/UI engineer, as I’ve been doing this week.
A few weeks ago I realized that I had to snap myself out of trying to fix problems with our components or with accessibility or color and instead try to change the process of our organization and how we build things. Progress can often be made 1% at a time, but sometimes you need to confront the biggest hurdle of working on design systems…
…tackling the politics. Ugh.
Hiring, managing, making the case for a new team. All of that is design systems work just as much as the writing of code or auditing of components. And it can be pretty scary if you’ve never done that before.
My advice is to try and phrase the problem in a way that management will understand. Don’t say “our components are bad and should be better” — focus instead on the business arguments. Why would hiring a UI engineer help the company? How is a design systems team going to improve the bottom line? Making a case for a dedicated person or even a full team is the design systems work at its very hardest; trying to improve the people and the process at the same time. It’s what really differentiates a junior design systems person to someone who’s more senior.
And if I could give myself advice for a second I’d say: be patient, make your case, and then repeat it until it becomes so boring and obvious to everyone else that hiring a team is the right thing to do. It’s tough and can be demoralizing but sometimes is the only way to tackle design systems problems at scale: moaning loudly in a British accent.
Well, at least that works for me.
ooooops I guess we’re* full-stack developers now
Chris republished his talk from Summer 2019 right onto CSS-Tricks. It gets into all the responsibilities that us front-end developers have now. I found one part of the essay especially interesting, where Chris maps those responsibilities and describes them as each being a node on a tree like this:
This metaphor probably doesn’t hold up quite perfectly, but the divide looks a little something like this. We still share some fundamentals, and we still branch out and know lots of different stuff, but one side is heavily focused on JavaScript and “Back of the Front” type work and the other is not.
I definitely find myself in the front-of-the-front-end when it comes to web design. I’m excited about UI and component design, but when it comes down to the specifics of how a specific framework or API works… not so much. That’s, to me, not as exciting as digging into some new CSS property or learning about how to make visual design super impactful.
And that’s not to criticize the folks who don’t care about the things that I do! I guess just riffing off of Chris’ post here, I find it super interesting that even though I think of myself as a front-end engineer, my day job looks way different to other front-end engineers out there.
webpack? Never heard of it, mate.
A Complete Guide to CSS Media Queries
Media queries are one of the most important tricks in our toolbelt and we’ve just published our complete guide. This is one of those resources that I know I’ll come back to time and time again because somehow the media query syntax is one that never really sticks in my noggin.
I particularly like this bit:
I know that talking about universal design on the web is hard and almost sound utopian, but think about it, there are around 150 different browsers, around 50 different combinations of user preferences, and as we mentioned before more than 24000 different and unique Android devices alone. This means that there are at least 18 million possible cases in which your content might be displayed. In the words of the fantastic Miriam Suzanne “CSS out here trying to do graphic design of unknown content on an infinite and unknown canvas, across operating systems, interfaces, & languages. There’s no possible way for any of us to know what we’re doing.”
The quote from Miriam here reminds me of a post that Tim Brown wrote a while ago about CSS locks that I think about often whenever I’m designing something new:
As a designed experience moves along a particular axis, it grows uncomfortable for any number of reasons: paragraphs feel too narrow or wide; font size feels too large or too small; elements touch or become awkwardly distant from one another. To cope with this discomfort, we use breakpoints. Breakpoints are moments of change. They allow us to make design adjustments that are only possible by changing the value or presence of CSS properties. We should invoke breakpoints as they are needed by our designs.
To break this down a bit: there are these BIG changes that need to happen for various reasons and then there are these parts of a design that need to stretch or stay the same across a range. Anyway, I’ve found it helpful to think about media queries as these moments of big change where the UI has to shift dramatically. But having too many of those can definitely make the CSS become bloated and fragile.
Some new icon sets
Changing gears quite a bit here, Chris has been busy collecting some new icon sets that might come in handy:
I particularly like the cute and bubbly design of Tabler Icons above, which is a collection of more than 800 free-to-use SVGs. Just scrolling through all these icons makes me feel like I need to start a weird icon-heavy side project soon to use all these lovely things.
The Empty Box
Sarah Drasner wrote a post about how to feel less overwhelmed when starting out building something brand new:
If you look at an apps like Notion, Airbnb, or Etsy as newcomers to the industry, the yes, it might seem impossible how you might get from learning basic CRUD operations to working on an application at the same scale, state and complexity as those apps. But what happens if we flip the script? Instead of thinking about building the entire universe from scratch, maybe we start with an empty box, one that only holds the core use case or problem that’s being solved. We can decide what we’re going to create with this small bit of space we have in the world.
I love this advice and I think I tend to forget this often. I make a list of all the features this new side project could have until it all spirals out of control and I feel overwhelmed. But Sarah says not to fear! Focus on the smallest possible bit of that project:
Forget about all the production and complexity you could build. What’s the purpose you want to convey at the core? What are you most excited about? What’s the solution to the problem right in front of you?
This is good advice for everyone that works within that spectrum of front-end development work, from designers and UI engineers to back-of-the-back-end folks, too.
Sponsor
SnykCon
Register today for SnykCon, a free virtual event for DevSecOps practitioners and leaders. Participate in hands-on technical sessions. 100% of proceeds will benefit the Bill & Melinda Gates Foundation.
Sponsor
Jamstack Conf
Can you believe it? We’re just one short day away from kicking off Jamstack Conf Vitual. There are tons of sessions happening on October 6 — that are absolutely free! — while October 7 is filled with paid workshops that are well worth the money.
[Chris]: I enjoyed this essay from Brandon Dorn about websites in the Brutalist style:
Things animate that shouldn’t, things don’t animate that should, things animate in ways that they shouldn’t. Navigation elements are either in your face or purposefully obscured. 3D art, italics, plain, neo grotesk fonts, monstrous hover states, jewel tones, thick dividing lines, harsh contrasts are some of the hallmarks. The trend is decidedly hip, and popular enough to show up in The New York Times articles and Bloomberg design conference sites. You know it when you see it.
Brandon, by way of looking at Brutalist architecture, reveals some connection to digital design:
Yet what if we can achieve a clearer understanding by intentionally revealing how a system works? Proponents of seamfulness argue that revealing an object’s complexity and operation can aid usability.
If not for the title of the article, Web Brutalism, Seamfulness, and Notion, I would have never guessed he was going to swing this into talking about one of my favorite websites of this dang decade: Notion. (If you’ll recall, I did some screencasts about it.) Aesthetically, to me, Notion isn’t Brutalist at all. It’s very confined to a small set of design choices you can make on any particular document and block within that document. You can get a little creative, but the constraints are too tight for real expression through aesthetics alone.
But this fundamental idea of Brutalism, seamfulness (i.e. being able to see the seams, see how things work), is very present in Notion.
Notion doesn’t show us how it’s literally working — the background processes constantly running to enable editing, collaboration, and the like. We don’t need to see our car’s engine to know it’s running. But it shows users how their understanding is working, how our ideas are structured, connected, and evolving.
