I love that we’re beginning to see toolchains like this and I expect to see much more of this in the months/years ahead. One caveat that concerns me however is the use of Figma as the source of truth. If I was responsible for a large design system with hundreds of consumers, I’d want 100% full ownership over the core data source with all third-party tools pulling from it. Call me old fashioned, but I’m not comfortable with Figma being the driver for something as critical as design tokens.
Once you publish something, the convention is that whatever you wrote was what you thought before you wrote it. These were your ideas, and now you’ve expressed them. But you know this isn’t true. You know that putting your ideas into words changed them.
System design is, far and away, the most challenging form of design I’ve ever worked on. That’s due to many reasons, but a significant portion of that is due to the continual process of articulating rationale and intent. Designing an elegant solution is challenging at baseline. Designing that solution and then documenting it to be comprehensible and repeatable by a whole org of varying skillsets and experience is just another level altogether.
But it’s that requirement of writing that makes system design such a formative practice for an individual. Because through writing, we end up improving our initial ideas. It makes our thinking and our work better because of it.
Watch out for people using ‘good taste’ and ‘bad taste’ as exclusionary terms. When someone says “you need to have good taste” but doesn’t break down what taste means in an objective manner, they might be using it as an excuse to exclude people. Historically, taste has been an elitist concept and intentionally kept blurry and subjective to prevent people from accessing certain places, groups, or opportunities.
I’ve come to loathe “taste” being thrown around in design conversations because it’s so rarely followed up with any objective definition. Much of the real work in corporate America is not the actual work, but rather managing how that work actually gets done with an army of people with different opinions, agendas, incentives, etc. Aligning seems impossible at baseline, so injecting squishy, indeterminate variables into the equation is simply unproductive.
What is productive however is for large organizations to clearly articulate their collective definition of things like taste and quality—along with a commitment to adhering to them. Unfortunately, that has been exceptionally rare in my experience.
As the U.S. defense community loved to point out in the 1980s, quantity has a quality all of its own. The reverse applies to software—the more you have of it, the more risks you run.
This article is well worth the read. While its subject is security-related, the underlying reason why bloat leads to security risk also leads to risks to stability, performance and general comprehension. For far too long, our industry has taken shortcuts to ship “good enough”. And I understand the appeal, but “good enough” continually heaped upon more “good enough” eventually leads to crap.
Another great quote:
To some, complexity equals power. (…) Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration.
This is another topic altogether—it’s something I’d like to write about down the road. I completely agree with this quote—we should have an immediate skepticism to complexity. Far too may nefarious things hide in the tall grass of complexity. We know this to be the case in fine-print, why don’t we hold the same suspicion for overly-complicated experiences.
Why do I bring this up in the context of design systems? Because design systems can be the driver or the firewall of bloat. I think it’s critical for our practice to take the harder road and hold the line.
Let’s say there is an icon of a lightbulb. Lightbulbs can be a symbol for an idea, so you name the icon “idea”. A couple of years later, your team wants to use the lightbulb for an electrical component and changes the name to “electricity”. This requires your team to devote time and resources to make the change as well as your team now must use the mental effort of remembering a new name for the icon. If the icon had been named “lightbulb” from the beginning, teams wouldn’t have to learn the name of the icon because they already have a mental model of that symbol. And there wouldn’t be a need to change the icon in the future.
This is one of the many, many reasons why design systems should include content design into the core practice. So much of a design system’s success or failure comes down to comprehension, yet we so often don’t give it the attention it needs.
And please, for the love of all that is holy. Do not name icons after features. There are few things in the practice that are just objectively right/wrong, but this approach just doesn’t ever end well.
I want to do anything and everything I possibly to promote the growth of Web Components. The current state of web development is overly complicated (see my issues with that in the previous article) and reliant on third-party libraries that I am not necessarily in love with. I want a web that doesn’t require firing up a terminal and installing lord-knows-how-many lines of someone else’s code before you can even get started. It doesn’t need to be like this. It shouldn’t be like this.
And frankly, it dilutes the focus of design systems from creating a codified experiential point of view to wrangling dependencies. It’s time to move on.
There’s no particular “hair on fire” problem that design systems solve that instantly sells to management. This can be frustrating to design system practitioners because we understand the intrinsic benefits of consistent UI over one-off solutions and maintenance nightmares. We trade immediacy in the short term for predictability over the long tail.
There are times in this line of work where I just need to sit the corner and breathe into a paper bag… My paper-bag-breathing is not directed towards the author, but rather to the hyper-myopic mindset that would drive someone towards such a conclusion. Design systems are a zero-interest rate phenomenon as much as roads are. Sure, they don’t directly make money, but at a some point in a company’s growth, it becomes harder and harder to make money without it.
I keep thinking that building infrastructure to ensure efficiency is just obvious, common sense. But here I am, still breathing into paper bags.
Critics of my position may point to what they believe is some sort of sentimentalism for old user interfaces on my part. It’s true that the problems I point to in this piece are of the kind that I consider solved in many of the older user interfaces. That has nothing to do with being sentimental however. Products have to work properly. If a button is the right choice, use a button. If it’s not, don’t. But if you are going to implement a design element that works like a button, it should look like one too.
I jokingly say that design systems aren’t about buttons, but they aren’t not about buttons either…
The author makes a strong case for the inherent usability of properly-leveraged skeuomorphism. At some point, the design practice veered into skeuoMOARphism where the practice jumped the shark with leather stitching and numerous other poor choices. Then, because any extreme movement needs to be countered with an opposite-yet-equally-extreme movement, we landed in flat design. I’ll be honest, I prefer flat design over leather stitching…
But the author is not wrong. A lot of the natural affordances from skeuomorphism do not really have an equivalent in flat design. I’m beginning to fall in the camp of skeuenoughism—where we have harken back to physical metaphors when it makes sense and just enough to get its point across.
When I decided that I didn’t want to be normal. I didn’t do it intentionally. I didn’t wake up one day declaring, ‘I’m an idiot surrounded by other idiots!’ No, I started with identifying behaviors that were corrupting my life and then made a conscious decision to replace them with alternative activities. Activities that were meant to contribute to my life progression, instead of persisting in current endeavors that have confined me in a wretched abyss of mediocrity.
This post isn’t about design systems, but it has a life lesson that I think is essential for a healthy design system. It’s a common trap to follow normal standards that other design systems follow. I think that’s a nasty habit that can often end in solutions backed by “everybody’s doing it”. Yes, I understand the irony given how design systems often ask teams to follow its “normal” components/patterns. I nonetheless stand by the statement.
I love exciting, and popular, and new software, but installing Arch showed me that popular isn’t as important as understandable.
The new hotness is exciting and, well, new. And if it’s well-supported, great! But nearly without fail, the old reliable solutions have more mature support and collective understanding. Which, also nearly without fail, will lead to better outcomes. We undervalue longevity and comprehension. It’s worth giving them serious weight.
Brad recommends a frontend workshop like Storybook for building design systems. Frontend workshops help you isolate UI components from applications and render their variants by mocking props, data and context. This way can verify UI appearance and behavior without needing to spin up the app.
Design systems do not implode because they don’t use Storybook. However, my brain imploded when Storybook decided it was a good idea to write this.
Akin to excess—absence, or minimalism, and the idea of “clean design” can sometimes make me not think or feel anything special when interfacing with said art, software, or device. It often fails to surprise or force a moment of pause to ponder—why does this feel great? Rightfully so, I do not need to be intellectually stimulated when making breakfast—it is conveniently acceptable for the design of the toaster not to be influenced by contrasting aesthetics.
The author goes into detail of mixing styles/aesthetics to create unique experiences. I think this post was supposed to lead me to a different conclusion, but instead I gravitate towards the line, “it is conveniently acceptable for the design of the toaster not to be influenced by contrasting aesthetics”. See, here’s the thing, there are a lot of products on the market that, despite their wishes, are toasters. And the people using them don’t want to some bespoke experience to invite curiosity, they just want toast.
Sometimes—hell, I’d say many times—we serve people best by squelching our desire to make something different, special or the envy of our peers. Instead, we just make an effin’ toaster that makes toast.
Most institutions, companies, and groups suffer from at least a partial lack of solid knowledge management. Fortunately, this is fixable by acknowledging the problem, understanding its sources, and addressing them in planned phases. Open source organizations can implement via iterative sprints, traditional companies via top-down project management.
I’ve battled for greater investment in knowledge management for the past 7 years. I can’t think of a phase in the corporate lifecycle where it isn’t useful. Are you endlessly hiring in a hyper growth stage? Knowledge management helps onboard and orient new hires so they can align faster. Cutting headcount? Hey, who isn’t nowadays? Well, a mature knowledge management process would ensure the expertise and domain understanding was maintained.
The most important investment you can make is in yourself. And that’s one of the hardest things for people or corporations to do.
While this may not technically be an example of design system documentation, it’s nonetheless handsome as hell. There’s a lot to learn from this wonderful set of guidelines. I know it’ll be something I refer back to numerous times.
The hub and spoke (also called “core + federated”) model is not the only solution, but it’s enabled Carbon to evolve an ecosystem that maintains design system compliance while driving innovation and evolution at the business unit and team level. All of which drives further growth of the design system and its community.
I like the idea behind hub and spoke, I really do. But I also think it’s important for folks to know just how much work it takes from all parties to make this model successful. It would represent a tectonic shift in how many companies work—where the system is at the core of nearly everyone’s job. And like I said, I’m totally down for that. But similar to the discussion of contributions, the sheer magnitude of commitment and effort is often brushed aside. Managing a system is hard. Managing a system of systems is like, really hard. There’s absolutely nothing wrong with things that are hard, I just think we need to be aware before jumping in.
We can’t predict the future, but we both know that there will be new frameworks with significant developer share AND there will be a ton of apps running React and jQuery and … for some time. Both are true, so why not support both?
This is exactly how I would build a design system if I was starting from scratch. There is no way that I want to be fully invested in any framework. They come and go and can fall out of favor faster than you can imagine. Don’t let a framework dictate the future of your design system. Create something that allows you to control your own destiny.
Have you ever had a zipper that gets stuck or the lining gets misaligned? When they fail, it can take the most beautiful designer jacket and make it feel completely worthless.
Designers, please do not take stability for granted. There is not a bigger hit to a person’s app experience than running into any bug—let alone a blocking bug. Quality means a lot of different things to different people. But don’t discount the importance of having something just do what it’s intended to do. Start there and build from that.
Impact testing is something that typically fell through the cracks on teams I worked with—to the detriment of everyone. This is one of those things I wish I could have taken back. It’s never someone’s highlight of the day to have their design break after updating a library. This is especially problematic if you’re working in an environment where it’s tough to get folks to update frequently. Don’t make the same mistake I’ve made. Have a test plan for component updates.
One of the primary elements of ensuring these promises come to fruition is consideration of the future. The decisions a design systems team makes have wider reach than a typical product team’s decisions, and as such require ensuring that the decisions the systems team makes will work for the company today, in 6 months, in 2 years, or beyond.
At the risk of being a human broken record, I strongly believe that the tech industry sorely underestimates the value of stability and continuity. You won’t find a more ardent supporter of iteration—but within the appropriate context. No, I do not believe it’s helpful to continually upend the foundations of a company or culture. Yes, we need to improve what’s not working, but we also don’t need to continually fix what isn’t broken. And that is especially true within the realm of design systems. Stability and familiarity is golden. So be careful with what you decide to change. Some change is good, but too often or too much at once can be risky.
I’m still forming about my opinion the use of AI that encompasses broad swaths of subject matter and information. However, I’m pretty sold on more targeted applications. I haven’t used this particular solution, but I’m bought into the idea. It’ll be interesting to see how this space continues to evolve.
Not that it matters what I think, but Nathan Curtis is one smart dude. I was truly impressed with Nathan’s thoughts in a recent Design Systems Podcast episode. I don’t think I’m breaking new ground by saying Nathan knows what he’s talking about, but I’m saying it nonetheless. There’s a ton of great nuggets of smart thinking in this conversation—it’s well worth a listen.
It’s a new year and that means a blank slate for this site. This page will be continually updated with 2024 posts. And if you’re feeling nostalgic, you can go back to the 2023 archive.
We want to include pictograms in our design system package to make it easy for other engineers to use throughout the product, but there are some problems. To include every option, we’d have to store a different SVG file for each color combination, which means a 1kb SVG file will now require (number of combinations) * 1kb of package space. If we add a new brand color or skin color, that number grows immensely. So we need to make this dynamic.
I wouldn’t be surprised if we see more work in this space moving forward. Illustrations are traditionally such a big operational lift, so any automation can go a long way. This work is a great first step, and I think so much more can be done. I’d love to see SVG leveraged for dynamic composition and configuration of modular “illustration parts”. While it likely can’t work for every illustration style, there’s nothing stopping select styles from being as modular as any other UI convention.
In the world of user experience, if everything is deemed important, then effectively nothing is. Carousels, while seemingly convenient, often compromise the clarity and effectiveness of your website. Prioritizing purposeful clarity and intentional user engagement over flashy features significantly enhances the overall effectiveness of the digital experience.
If there’s one thing I could accomplish in my professional career, I wouldn’t necessarily want it to be the extinction of carousels, but I’d nonetheless be quite proud of the accomplishment. As the article title suggests, carousels don’t work. Unfortunately this post doesn’t provide any hard evidence towards it’s assertion, but don’t worry, it exists.
I understand that carousels are the UI manifestation of corporate compromise. And for that reason alone, much to my chagrin, they’ll exist in perpetuity. But a boy can dream.
If you’re making something weird, you need to have a very good reason why.
I’m all for weird, believe me. There’s just a time and a place for it. I’m a big believer in personal projects as they’re ideal for weird. In fact, I’d go as far as to say a personal project should be a little weird. But weird becomes a little less desirable once we’re talking about products with a large user base who are relying on it to work. If you’re willing/able to do the upfront work to test/validate/iterate, then by all means, let the weird-flag fly. But otherwise, maybe follow existing conventions and save that idea for a personal project.