Culture impacts how icons are interpreted, understood, and used, just like all other content.
I was big into icons in my younger years. Through the years I’ve found them to be an increasing pain in the ass. Icons are a notorious crutch within interface design that are frequently misunderstood and, as the author mentions, subject to cultural misinterpretation. Words on a website can be translated, but them icons? They stay the same.
Be weary of icons. Sometimes they create many more problems than they solve. If anything, this article makes a strong case for icon usage to be strongly tied to a system that takes localization into account. And if I’m working on a design system that supports a product used across regions, I’m thinking really seriously about adding a locale attribute to any Icon component…
Here’s where the migration usually fails. That last 20% is a massive chunk of effort to remove, and it’s too much for 1 or 2 engineers to remove, especially if it exists in niche product areas that the design systems engineers aren’t familiar with.
I have a few thoughts on how to handle design system component migrations. As you’d expect, automation should be the first line of defense. Codemods and linting tools can take a huge chunk out of this work. As the author mentioned, there will likely be a decent amount remaining that automation can’t handle. One thing that worked really well at Pinterest was to hire contractors to take on manual migrations. I find this to be a great fit for contract work as it’s focused and finite in nature.
The other thing I’ve always wanted to try is a company-wide fix-a-thon. Similar to company hack-a-thons, teams would be given a chunk of time to burn down debt, including the effort to replace custom UI with design system components. This is the kind of work a lot of people want to do, but never seem to have the time to do so.
When a measure becomes a target, it ceases to be a good measure
Design systems continue to careen towards being an industry norm. This transition will make metrics and measurement a more central part of the design systems practice. That would be A-OK in my book–I’m a big fan of quanititative data when paired with an equal helping of qualitative. And even while I’m a big fan of metrics, I view it through a very aggressive bullshit filter.
So, as design systems increasingly become metrics-driven, it’s going to be important to remember Goodhart’s law. It doesn’t take much digging to see the impacts of quantitative-lombitification. Remember that numbers alone are meaningless. Don’t let them think for you or decide on your behalf.
At some point, we solidified the layout of a calculator. If we change it too much, we diminish value rather than add to it. It might be time to recognize that we have solved some software problems, and the reason why all this stuff gets redesigned repeatedly is simply because companies don’t know what to do if these things have been solved already.
Some of my favorite products don’t pretend they need changing. Instead, all focus is poured into refinement. There’s plenty of examples of interface elements that don’t need “innovation”. They just need to be well executed. If this isn’t the wheelhouse for design systems, I don’t know what is. The challenge is convincing an industry drunk on performative innovation to cool it just a bit.
There hasn’t been a significant shakeup in interfaces since the mobile phone. Things like virtual reality could be a new horizon, but they’re still relatively fringe. There isn’t much need for novel solutions, but there’s certainly a need for better ones.
In technical communication, we don’t talk much about decision support; we talk about task support… In many cases, the information people need to complete their tasks is not information on how to operate machines, but information to support their decision making… simply documenting the procedures is never enough… What I am talking about is documenting the context, letting users know what decisions they must make, making them aware of the consequences, and, as far as possible, leading them to resources and references that will assist them in deciding what to do.
I acknowledge this link is odd as it simply quotes the above from a separate book. It’s nonetheless a valuable thought, so I added anyway.
Documentation and guidance can so easily stop at, “do this, but not that” without providing any rationale for why. But the thinking behind the rules is far, far more valuable than the rules themselves. Because that’s the thinking which helps improve existing rules and/or form new rules altogether.
Yes, it’s important for design systems to provide concrete do/don’t guidance. But don’t stop there–give them all the reasoning behind what formed the guidance.
Your role as a software engineer is to play the plumber to product. The reality of the world is that product holds the money and software development is seen as a cost center to be minimized towards zero. You are selling to them.
If software development is seen as a cost center, then design systems must be seen as a cost center in support of a cost center. Eek.
So, as most design system practitioners know, learning to sell becomes a core skill to remain funded and/or employed. This article does a great job providing some nice tips for this kind of work–specifically trying to avoid zero-sum outcomes. I love the idea of proposing design system “packages” where each “tier” provides different levels of quality–at a different cost. If give folks options and it creates an inroad for what teams get for each level of investment.
Also, the author makes this case all through the lens of being a plumber. And it’s my dream to have a second career as a plumber.
Ultimately, Design Tokens can be more than storing values. They can be a way to create a cohesive, adaptable, future-proof design framework that grows with your project.
I agree with half of this statement. Yes, design tokens can be a way to create a cohesive, adaptable, future-proof design framework that grows with your project… But exactly because they are simply store values. But that’s a good thing. A JSON file full of design tokens is like a design system’s configuration file. It’s not novel, it’s not fancy, but that doesn’t make it any less powerful.
Design tokens are variables. I’ll die on that hill. That doesn’t diminish their value. In fact, quite the contrary. And the reason why this gets me all hot and bothered is that if we just named these damned things variables, it would have created an inroad for designers to more effectively engage with engineers. We’d have one less made-up name and one less way for designers and engineers to think they’re working on different things.
In The Unaccountability Machine, Dan Davies argues that organizations form “accountability sinks,” structures that absorb or obscure the consequences of a decision such that no one can be held directly accountable for it.
Accountability sinks are all over the place in the software industry. Many Silicon Valley companies are the perfect recipe of moving at a breakneck speed, fragmented or non-existent records of decisions, a revolving door of personnel along with hilarious amounts of crippling complexity.
Yet, somehow, someway, many design system teams tend of be an accountability magnet. In prior roles all manner of blame was hefted onto the system. Was it justified? No. Was it fair? No. Was it ultimately good for the team? Absolutely. See, it doesn’t take too many of those situations to get really good at record keeping, documenting and generally keeping books on everything. That meant any finger pointed at the team was met with transcripts, metrics, archived communications and all manner of facts that set the record straight.
It also gave the added benefit of building a culture of accountability on the team. Ironically, the best way to counter unwarranted blame is to simply lean into accountability.
You do not have to follow these rules every time. If you have a good reason to break any of them, do. But they are safe to follow every time.
It’s funny because to my knowledge the author does not work on design systems, but they sure write like one. Rules like these are the wheelhouse of a design system. Unfortunately they’re often never added given most systems’ sheer scope and the pressure to deliver “measurable value”. The kind of rules this post has is exactly where I would start with a design system if I had my druthers and nothing breathing down my neck. Because design systems depend on clear and well-defined rules. They need those rules to maintain system-wide consistency. They also need them to reinforce proper usage.
Here’s to more rules, ideally safe ones.
Warm Handoffs address both of these issues by moving questions to the right team and channel while supporting the requester throughout the process. The basic rule is: “If someone asks you a question you can’t answer, take them to someone who can answer it. If you don’t know who that is, help find someone who can.”
This isn’t just courteous, it’s efficient. You’d be shocked how much time is lost–especially at large companies–from people just trying to find information. Warm handoffs are a great way to make sure people aren’t swinging in the breeze.
This behavior is incredibly helpful within design systems in regards to documentation. People commonly ask questions that are covered by documentation. There are a few ways to handle that. There’s the old “RTFM” approach where no help is provided other than a link to the docs. On the other extreme, questions can be fully answered over Slack–effectively rendering documentation useless. Neither are ideal in my mind.
Instead, my ideal approach is to answer with a direct, if not brief answer summarized from documentation, along with a link to the docs to read more. This “warm handoff” to documentation seems like the best of all worlds. The person asking the question is unblocked both from getting their answer as well as access to additional information if needed. It helps build visibility of documentation (which is typically a challenge). Lastly, it means less support effort for design system team members.
Every change breaks someone’s workflow
The more people that use a design system, the more edge cases there will be. It’s a good habit to assume change–any change–will ruin someone’s day. It doesn’t mean that change should be avoided at all cost. It just means there needs to be treated with incredible amount of respect.
If a piece of tech debt is well-contained, the cost to fix it later compared to now is basically identical. You can weigh how much impact it has today when determining when a fix makes sense. If, on the other hand, a piece of tech debt is highly contagious, it will steadily become harder and harder to fix. What’s particularly gross about contagious tech debt is that its impact tends to increase as more and more systems become infected by the technical compromise at its core.
I’ve never thought of debt as a contagion, reading this article made it clear how much it can be. When I think of contagious debt, I can’t think of a better example than how Figma debt can explode. A single detached or custom element can go from a one-off to copy/pasted everywhere in a blink of an eye.
And just like any contagion, it’s critical to catch these things early and focus on containment. Because once they’re out, it’s going to be one hell of a job to get it under control.
I typically post three links with a small observation. This week I’m posting one with an essay in response.
But somewhere along the way, we got lost in the weeds of components, tokens and documentation. Design systems became rigid rulebooks + glorified Figma sticker sheets — stifling creativity and burying designers in endless updates. And so adoption becomes the main challenge. Any design system professional will tell you that they spend more time trying to convince people to adopt their design system than actually designing it. Could it be that we have not quit reached Product Market Fit for design systems?
I’m not shy about critiquing design systems. They’re far from perfect. But this article is flawed at best, disingenuous at worst (more on that last point later).
This article seems to half lost sight on two things. First, design systems are not a panacea. They don’t magically poop rainbows for free—they’re just a tool. Second, like all tools, they need people to use them properly. The argument expects too much from the tool and not enough from people using it. The writeup defines five problems:
They’re unread novels.
Starting off any argument with the “no one reads” case is problematic—especially given it’s delivered in a written argument that requires people to read it. People read. They don’t read novels, but they read all day. Do design systems need to improve how concepts are relayed? Absolutely. But throwing up the arms saying that the world refuses to read is hyperbolic and false.
They crush innovation.
The innovation argument is getting old. “Design innovation” is an incredibly squishy subject that, in my experience, it typically a dog whistle for “I want to do what I want to do” rather than putting in the work to develop novel solutions. Irregardless of all of that, tools don’t crush innovation. Policies on using tools are to blame.
My stance regarding deviating from a design system is typically, “Go for it, but prove it”. If teams feel strongly that they have a better solution, then they need the space to try. But that feeling has to be backed with evidence. Without evidence, I begin to ask questions. So, by all means, try new things, but that can’t be without accountability. Otherwise, that’s not innovation. That’s just doing whatever because whatever. And in the case of design systems, “doing whatever” typically means spending much more time/money to develop.
If teams have put in the work and have a novel solution that’s better than what the system provides—that should win. Better yet, it should be added to the system. If that’s not happening, that’s the fault of the people making bad decisions. It has nothing to do with design systems.
They’re a black hole of maintenance.
Black hole? This one is a head-scratcher. The worst maintenance challenges I’ve seen in my career came from individual teams trying to maintain their individual designs/code-bases while also trying to pump out features. Most design system teams represent a hilariously small fraction of personnel compared to the consumers they support. And that small fraction of personnel cover disproportionally large amounts of the codebase. So to hear design systems are maintenance black holes… My sixteen years of experience in this space point to the exact opposite. Is it zero maintenance? Of course not. But that’s just not how reality works.
They’re dinosaurs in the age of AI
Everything is apparently a dinosaur in the “age of AI”. I’m not dumb enough to say that AI has no merit, but I’d love to see one sizable, concrete example of this actually working consistently before we start building the pyre. We keep hearing this, and yet we have case, after case, after case where the messiah AI solution doesn’t live up to the hype. So if you’re going to put a bullet in design systems, I’d love to see its replacement actually work before pulling the trigger.
They don’t scale.
Infinitely? No, design systems do not scale infinitely. Nothing scales infinitely. So yes, we can put that in the column of downsides—along with everything else ever. Google’s design system may not be scaling for its ~180k employees and its hundreds of products. As mentioned, a design system isn’t a miracle. But let’s flip this—how in the hell does Google actually support its near countless properties without a design system? And if you’re thinking AI, that’s not a solution, that’s a buzzword acronym.
So, yes, while I am innately biased, I disagree. I consider the post a collection of opinions that have numerous, numerous holes. But, hey, we all have different world views and that’s what makes the world go `round. If it ended there, I’d just go on my merry way and leave this be. But…
So why do we continue to push design systems as the solution for design at scale? Should we consider that while they might be part of a solution, there are other tools and ideas that we need to develop?
So, what’s the next chapter? How do we harness the power of AI to create designs that are consistent when they need to be but also truly dynamic, intelligent, and adaptable?
For me, those last two paragraphs change the entire tone of this writeup. It goes from a critique to (what I’m sensing to be) an infomercial to sell some “solution to all our ‘problems’”. To be clear, this is my interpretation, but I can’t shake it. My nose tells me this reeks as the first half of a soon-to-be-disclosed “fix” for design. And just like tech “fixed” journalism and “fixed” transportation and “fixed” social interaction and “fixed” currency and “fixed” education, I’m sensing a looming “fix” for design.
Yes, design can/must improve, but it doesn’t need to be “fixed”.
A lot of people in the systems practice pretend like they invented all this. They didn’t. Design systems aren’t novel, which is why they’re so powerful. What’s great about design systems is they’re an adaptation of time-tested methods of defining patterns and establishing best practices. It’s a process that has been used forever. It works. Applying this approach to software is obvious.
There’s so much in design that needs to be improved. Of all the things to improve, why try to replace the time-tested concept of building from standard, ready-to-use parts? Tech is neck-deep in a phase of making solutions in search of problems. Please, move on.
…managers decided that we were spending far too long investigating users’ problems and not long enough building the new features the business wanted. Developers needed to be more productive, and more productive meant developers developing more new features. To get developers to develop they need to be ‘in the zone’. They need headphones and big screens to glue their eyes to. They did not need petty interruptions like stupid users ringing up because they got a pop up saying their details will be resent when they tried to refresh.
Anyone who’s spent time in design systems knows how much time/attention support can take. We know how much it eats into “active development” of the system. I’ve spent considerable effort devising ways to reduce how much of the pie support takes. But I am not a supporter of zero support being the goal. Rather, I think the goal should be to maximize its worth.
Support is the connective tissue between the design systems team and its customers. It’s an important touch-point for not only understanding what’s not working, but getting first-hand experience on why it isn’t. The challenge is how do you abstain that hyper valuable information without it disrupting everything else.
Some things that stand out are setting up a rotating on-call cadence and building up non-human resources to solve the basic support cases (e.g., “Do we have a Button component?” or, “Do links need to be underlined?”). This can be done with documentation, or AI, or both. But those questions don’t typically yield the same insights as deeper, more ambiguous ones do. Those questions typically spawn bigger, broader conversations about the system. And those conversations can have a profoundly impact on making the system better.
This “drift into failure” tends to be a slow process, with multiple steps which occur over an extended period. Each step is usually small so can go unnoticed, and no significant problems are noticed until it’s too late.
This article is focused more on traditional safety procedures, but I think it can clearly design to software development. Software has its own “safety” procedures to ensure inaccessible and/or unreliable software is not shipped. Many of the patterns that leads to traditional safety risks apply to software safety risks.
Unsurprisingly, the concept of complexity comes up. If a system is too complex, it will either be accidentally applied incorrectly or explicitly ignored. Simplicity isn’t just a philosophical pursuit for elegance, it’s a pragmatic requirement to ensure the systems we put in place are used and applied correctly.
Another interesting concept is the notion of natural “drift”. People just inherently loosen up on rigor. That’s why I’m a strong believer in making components and patterns that simply do not allow improper usage. Yes, this may mean the system is a little rigid, but it’s critical in holding the line on avoiding avoidable failure. “Freedom to fail” may sound like from a best-seller book targeted at Silicon Valley execs… But I’d say flexibility that “empowers” dangerous use is just dangerous.
This is a design system to keep track of. There’s a ton of details in this codebase to apply to the nitty gritty execution of web components. I’m excited to dig into this in the weeks to come. I’m not going to say this design system is perfect–especially without a thorough assessment, but I think a lot of corporate-built design systems are not necessarily concerned about web standards. I bet a design system built by a standards consortium may take that a little more seriously.
If the thing that is being made more efficient is socially harmful, then the consequences of greater efficiency are scary or depressing (think mass surveillance, or robotic weapons). What about the most common case though — where the thing we are making more efficient is related, but not identical, to beneficial outcomes? What happens when we get better at something which is merely correlated with outcomes we care about?
This article hits home because it so clearly relates to design systems. Maybe not yet for many organizations, but eventually. Efficiency is one of the key drivers for design systems. Many design system teams are understandably expected to track their impact on organizational efficiency. That’s great on the surface, but it’ll no doubt backfire eventually. As the article suggests, design system efficiency is correlated with beneficial outcomes, but isn’t beneficial in and of itself.
Increasing team efficiency doesn’t mean better work, it just means work is getting done faster. What’s worse is if teams blindly follow efficiency as the goal—that’s typically when things go sideways. We all know there’s countless ways to pump numbers. If efficiency is juiced at the cost of quality or satisfaction, it’ll likely result in poor business outcomes. But who cares when all you’re being judged on is efficiency? Welcome to the madness that is corporate America.
Tracking efficiency isn’t bad, but it isn’t the solution. Additionally, there’s likely a “enough is enough” level of design system efficiency where either the cost/benefit is upside-down or it’s causing issues elsewhere.
In short, there’s no replacement for good old fashioned critical thinking.
This interview was a great listen as it speaks to how universal many design system challenges are. I’d say there’s a lot of conceptual overlap between microservices and custom designs. Both allow teams to remain independent and unblocked. Both allow the freedom of bespoke implementation. Both enable teams to jump out the gate with much more initial speed. And… both end up causing incredibly complexity and productivity-drag in the long term.
I’m continually amazed at how common many organizational challenges are. Which makes me disappointed that we’re not working more closely together on common solutions.
Consumer products have had growth hackers for many years optimizing every part of the onboarding funnel. Dev tools should do the same. Getting started shouldn’t be an afterthought after you built the product. Getting started is the product!
When people think of design systems, they typically think of tokens, components, and patterns. Those things are the “easy” part of making a design system. When I say easy, I mean easy relative to all the other incredibly harder stuff. Helping people understand how to use the system. Helping them understand why it’s important to use the system. Helping them understand that the system exist in the first place. All that stuff is what’s existentially hard.
And that I think is what separates the folks who are interested in design systems from afar and the grizzled veterans. Most design system work paradoxically isn’t spent on what’s considered a “design system”.
With software, the fact is that sometimes there are just too many variables to know and test and smooth out. So I click around, using the UI over and over, until I finally cannot give myself any more splinters.
There’s all sorts of things that go into building out a design system. It’s no small feat to create a component from nothing to available in production. That feat only takes a distinct skill set. In addition, there’s a skill set that takes existing components/patterns and fusses over the details of details. All the little drips of water that go unnoticed when wrestling with the firehose of work to make something from scratch.
This could be a process, or it could be a role in and of itself. Either way, it’s a concerted, highly beneficial effort. Unfortunately, this kind of work is typically difficult to persistently fund because the outcomes are hard to measure. That’s why I think it’s best to focus “sanding” in the context of design systems because the outcomes are so magnified. Polishing one button may yield negligible results, but polishing one thousand? That’ll probably leave a mark.
When archiving an email in Gmail, a toast appears showing confirmation. But by archiving the email, the email disappears from the list, which already implies the action was successful.
I think there’s a place for Toasts—but the author brings up some good points here. It does seem like software in general has become allergic Occam’s Razor and sometimes we can just let the thing doing the thing tell people about the thing. How is this related to design systems? Well, I’d argue this is a prime example where design principles and clear, focused usage guidelines can go a long way to avoid not-so-great usage.
I also don’t think design system documentation should shy away from content like this. To be frank, I think this level of specificity and directness would prove highly beneficial.
I’ve spent the past 6 years working in this space, and I’m often struck with a sense of attempting an impossible task. No matter how hard we work to foster these socialist ideals, like community, collaboration, and contribution, it feels as though we’re always being dragged to a default culture of individualism.
There’s some useful nuggets in this article, but I haven’t come to the same conclusions as the author. I’m not saying they’re right or wrong, but I haven’t personally seen it.
I don’t think the challenges associated with contributions are incredibly complicated. In my experience it’s a mix of a lack of understanding and lack of interest. That lack of interest may be incentive-based or just plain-ol’ no allure to working on systems. I think understanding and interest are related—meaning I could see people being more interested if they better understood systems and/or would better understand systems if they were more interested. But, don’t mistake uncomplicated for easy.
I’ve in no way cracked this nut, but I have had some success at times leaving big dents. And those dents have come from generating understanding and/or interest.
I’ve come to believe that one of the best ways to address the centrality of stupidity is to take on two opposing efforts at once: you need to assure students that they are not stupid, while at the same time communicating that feeling like they are stupid is totally natural. The message isn’t that they shouldn’t be feeling stupid – that denies their honest feeling to learning the subject. The message is that of course they’re feeling stupid… that’s how everyone has to feel in order to learn math!
I’m not about to say that design systems require the same mental acuity as advanced mathematics. If they did, I’d be a plummer. But, design systems have a penchant for making relatively smart people feel really stupid. Half the job of a design system manager is exactly what the author writes about teaching mathematics. It’s convincing folks they’re not
And here’s where I gripe about “thought leaders”. Many self-described thought leaders insinuate that they’ve got things pretty damned figured out—which is why everyone should buy their book or attend their workshop or insert action that triggers transaction. And either intentionally or unintentionally, it’s preying on the outbreak of self-assessed stupidity.
Sometimes these folks have real insight to share. But 99% of the time there is little material gap between them and the people they’re selling to.
It’s still early days for design systems and content design and strategy. Practitioners in both areas can learn from and support one another. Together they can improve stakeholder alignment, workflow planning, and system adoption — and magnify the impact of their respective work. When system-wide design and system-wide content support each other, a design system can be more effective, teams can work more efficiently, and most crucially, users can have a better experience.
It’s no surprise that I deeply value content design—mainly because I don’t stop talking about it. This article does a good job articulating the clear value content design can bring. I sometimes think that content designers cover the broadest surface area of design system needs. That doesn’t mean engineers or interface designers aren’t essential; you simply can’t have a design system without those practitioners. But just in terms of jobs to be done, content designers could very likely cover the most bases.
This is an interesting little CSS framework to check out. I could see this being a quick way to prototype a rough visual system without heavy lifting or overhead. I’m pretty firmly against leaning on these kinds of solutions as the cornerstone for a mature design system. But for vetting ideas come to life fast and cheap? Things like this are hard to beat.
Uniqueness bias is different in that it involves a judgment about the degree to which something is perceived to be singular and, therefore, of little or no relevance to anything else, and vice versa.
Design system teams often hear the, “Our use case is different” argument for not using an existing system component/pattern. And yes, nearly every use case is different. But rarely are use cases different enough to justify a unique solution. This study is interesting because it shows just how people are hard wired to think this way—and how it’s not typically beneficial for outcomes.
What I’ve sort of realized slowly, painfully, over the years is that great design can only thrive with a dictator/director—a single person who can say yes, go, ship ship ship.
I don’t think great design comes from democracy. I also don’t think it comes from a dictatorship. I’d argue the model to follow is a republic—where representatives convene to “legislate” by balancing the needs of their constituency with the greatest benefit for the whole. This is how we’ve tried to model design system teams I’ve been a part of. It’s not perfect, but it’s the most effective model we’ve used to date.
Dictatorships live and die by the person at the top. It’s too risky to be considered a viable option and too dependent on the whims of an individual. My philosophy is for principles and rules to be what makes decisions. This process takes more work in the short term, but unlocks the ability for large groups to have a shared set of expectations and direction.
And I have more bad news: users will avoid interface elements they cannot understand. It’s in our nature to distrust the unknown. When Google decided to hide other apps behind an unclear icon in the Gmail UI, they apparently got a stream of support requests, like “Where is my Google Calendar?”
A good label will beat out an icon any day of the week. This has been backed by industry research. We yielded the same results when running our own usability tests. This isn’t typically as much of an issue with well-established icons, but erodes quickly once an ounce of unfamiliarity is injected.
And that’s the problem with designing interface patterns that are dependent on icons. Those patterns will likely work just fine with known icons, but those patterns need to work no matter what. And often times more complicated subjects must be conveyed.
Stick to words people.
Consistent experiences build trust and set clear expectations for customers; flawless design and excellence delight them. (This is why we return to the same restaurant for that glorious meal that never disappoints. And this is why we brag about it to our friends).
Here’s the thing I’ll never understand: Consistency is such an obvious win-win-win. It’s a proven win for the people who use the product because they’re not having to re-learn what’s effectively the same thing rendered differently for who-knows-why. It’s a win for individual product teams because they don’t need to invent and develop new ways of rendering the same thing and it’s a win for all product teams when that one consistent execution is refined and the benefits show up everywhere.
Yes, know—context, yada, yada, yada. Of course too much of a good thing can be a problem. But I’d wager my life savings that the problems associated with an excess of inconsistency far outweighs problems from excesses of consistency.
And that’s why design systems adoption is so important. Higher adoption (depending on how it’s measured) is one indicator of consistency. Higher adoption also assumes less custom development, meaning greater efficiency. And more usage in the codebase means system updates benefit more areas of the product. It’s a triple-whammy of beneficial outcomes!
If you start off saying ‘we’re going to make a big serious contribution no one’s ever done before,’ that sets up high stakes and invites harsh critique from the start.
I’ve frequently critiqued design system teams that carbon-copy other systems in the spirit of following best practices. My critique of that practice stands. “Other systems do it”, is not a solid rationale. Conversely however, being different for the sake of being different is just as dumb. Innovation for the sake of innovation is missing the point.
It took me some time to learn to be proud of simple-mindedness. If the simple/obvious thing works, just do that. Don’t overthink it or let insecurity force you down a rathole. This lesson is all the more important given the criticality of simplicity in design systems. When you’re handed a win, just take it—because they don’t come that often.
If there’s one law in the systems practice, it’s this: Given enough time, every design system conversation eventually devolves into a naming altercation.
I’ve been a fan of Nord’s design system for quite some time—in large part because of their documentation. Off the top of my head, I’d say it’s the gold standard. And that’s due in large part to its breadth. How many design systems document naming guidelines? If there’s more than one, I haven’t seen it.
I’d like to say that the Nord team is damned smart for publishing guidelines like these. But I think this is more a case that the rest of us are dumbasses.
If it takes too long to explain or grasp an idea, then its implementation will be complex, and it will take too long to fix when something inevitably breaks.
I’d bet a decent sum of money this isn’t a universal law, but it’s close enough in my book. One of my self-defined axioms for design systems is that if you can’t descibe what a component is in one simple sentence, it probably should be broken up into simpler components. I think it’s difficult to understand the fragility of complexity until you’ve actually lived it. Meaning you’ve built some abomination that’s impossible to understand, debug and evolve.
I think that’s when all of this really starts to hit home…
If there’s a huge company goal your colleagues are already rallying around, try to communicate how adopting the design system will help achieve it.
Charging head-first into every “use the design system” battle is going to lead to a lot of bloodshed. It’s incredibly important to sniff out times where the design system adoption will be welcome with open arms—for a couple reasons. First, it means you can be a little more chill with your governance approach. You don’t need to turn every misuse into a wrestling match. Second, those big goals are typically windfall events where adoption can increase by orders of magnitude.
If their art dies out, maybe nobody will know how bad all the pianos are. And then we’ll all have slightly worse pianos than we would otherwise have. And I mean if that’s the way things are going to go, then let’s just steer the Earth into the Sun, because what’s the point of any of this.
For what it’s worth, I do think we’re losing some of the deep skills of design. The industry is valuing other attributes in a designer and thus some of that critical expertise is beginning to atrophy. But I think design systems can preserve and re-educate those aptitudes. So much of design systems are about the foundations—color, typography, spacing, contrast, etc. I think it’s the responsibility to not only lay out token values, but to describe how to employ each with deftness. Hell, if only to conserve some incredibly valuable wisdom and knowledge.
The shift to remote work has elevated documentation to a critical priority in our process. In general, documentation is the backbone of design systems. But it becomes especially crucial with our design and development teams distributed across various locations. Our approach goes beyond merely creating components; we’re making a substantial investment in comprehensive documentation.
Documentation was essential pre-Covid, a necessity in the post-Covid remote environment and now it somehow has the potential to mean even more with the growth of AI. The importance of documentation may be one of the more misunderstood elements of design systems. I don’t know how a design system can thrive at scale without top-notch documentation.
This site has a bunch of great resources on how to better integrate documentation into the software development process. I haven’t explored all of their resources, but I’m always going to be a fan of creating processes that bring different disciplines closer together. This will be something I continue to research.
The best things in life often aren’t miracles, but well-thought out approaches that are sustainable. The same thing is true with businesses, marriages, and just about anything with repeatable elements. If you invest time into solving for what leads to success continuously, you will reap those benefits for years to come. So even in the least quantifiable situations, reflect back on what could’ve made a previous loss a future win.
There’s so much to like from this article. And if you buy into what the author is selling, it’s quite an admonishment for how a lot of tech works. Consistency, persistence and a focus on incremental, continual improvement is the path towards greatness. I’d argue that mantra is even more important in the context of design systems.
A design system is an exercise in stamina and discpline. Steady wins the race. Folks who get too high and too low get chewed up. I’m lucky I started this effort further on in my career because it would have been a disaster if I started in my twenties.
Think small, think gradual and think deliberately. Don’t get too up, don’t get too down and don’t get off the ride. You’ll be shocked at how far you can get with that approach.
What apps, stores, devices and websites do you really love? What sort of experiences do they provide? In addition to the products, information or services they supply, they are also visually appealing. You enjoy using them because you enjoy seeing them on your screen.
This is an example how I would not make the case for visual design. To start, I wouldn’t title it in a way that falls for Betteridge’s law of headlines. Secondly, there needs to be much more empirical evidence to support this case. It starts relatively well, but trails off quickly. And last, the quote above degrades the argument because it’s meaningless and likely wrong for many people.
Design systems are often looked to be the custodian of visual design. I truly do believe that visual design matters. How much? I don’t know. To be honest, I don’t think anyone knows. There are plenty of loved products that have been panned for visual design. Craigslist is commonly cited. Wikipedia comes to mind. I have plenty of products and brands I like with mediocre visual design. Would I like them more with better visual design? Probably. How much? I have no idea.
I want to write more about quality because it’s such a loaded and important topic. I love how this talk works to dissect the anatomy of quality. There isn’t a universal definition of quality. Which is good and bad. It’s bad because people fling that word around amongst each other, often assuming they’re saying the same thing when they very much aren’t. It’s also good because it means we all have the chance to develop our own definition and point of view on the subject. In my experience, very few people take advantage of this to its fullest.
If there’s one team that should be able to clearly and thoroughly define quality, it’s a design system team. It’s not easy, but it’s vital. And I’m convinced it’ll ultimately act as a rally point for an organization.
Friction compounds with itself: two setbacks are more than twice as bad as one setback. This is because most systems are at least somewhat resilient and can adjust itself around some problem, but that makes the next issue harder to deal with.
I think our industry likes to think big—often at their own peril. I think about design system friction all the time and I’m often thinking about all the little things making things harder to use it. Those boring, mundane, tiny-but-measurable issues that add up to being a colossal pain in the ass. Why? Because as mentioned, friction is compounding—but the effort to fix them typically isn’t. So, in theory, you reduce friction exponentially with linear effort.
Obviously the big, huge, horrible points of friction need to be addressed. But sometimes you can have equal impact by solving a bunch of small issues.
The problem with focusing relentlessly on understanding is that math and science students can often grasp essentials of an important idea, but this understanding can quickly slip away without consolidation through practice and repetition.
There’s something to this article that I think can be applied to design systems. Intuitive is the cliché goal in software, but I think we’ve over indexed on that. More and more I think memorable is a better goal. Intuitive often limits us to familiar concepts—meaning we’re pigeon-holing ourselves to follow past conventions to remain intuitive.
Please tell me what’s intuitive about the alphabet. What makes the letter A intuitively A? The whole basis of modern communication is based on memorization. We don’t even bat an eye at the fact that children will be expected to memorize these concepts. Why then can’t we expect consumers of a design system to memorize its foundational concepts?
But that doesn’t take design systems off the hook—it simply redistributes the difficulty. Now instead of intuitive rules/guidelines, they’d need to be memorable. I’d take that trade in a heartbeat though as it theoretically opens new doors for new thinking and approaches.
Now, I want to challenge the notion that essential complexity is irreducible. The fact that we can’t remove it by changing software alone doesn’t mean that there’s nothing we can do about it. What if we were to attack the essence? What if the problem definition wasn’t outside of our purview? What if we could get the world to conform to the software, and not just the other way around?
I live by this ethos. Some of my most cherished belongings follow this formula. They force me to work with its “limitations” and in doing so, I get something beautiful in return. I also acknowledge that this is not a normal way of thinking.
Yes, of course design systems would be simpler and more elegant if they were designed under the assumption that its consumers would gleefully adapt to its idea form. But that’s a road to an ugly destination if you drive down it too far…
However it’s only now as a product designer that I realize just how much I want the design system to carefully guide me instead of brute-forcing its decisions onto my work.
And this article serves to explain much of why design systems often become complicated. I’m a disciple of simplicity and will push more ardently than most towards that goal. No, I do not think a design system should placate its consumers. I also don’t think system should expect consumers to strictly conform. I think it’s neither because it’s both. System and consumer need to meet in the middle for that happy sweet spot where the system can be elegant and the people using it do so unfettered.
If thousands of design assets don’t follow a certain naming logic it makes it difficult for design, product, and marketing teams to use them consistently. Streamline access to assets in a way that two teams can apply the same icon metaphor to their specific brand voice, and still maintain visual consistency. Incorporate a naming logic so assets can be referenced correctly and used consistently.
Iconography represents a whole system of its own within a design system. I was an icon designer in a past life and I used a lot of the design system principles I still use today. One thing I learned was to design icons with “tokens”—such as stroke width, corner radius and spa ing. And don’t sleep on the importance of naming logic. A clear and intuitive icon naming formula will go a long way to make your pretty little icons findable and usable.
Headless design systems differ from traditional designs in that there is no central user interface or frontend. Instead, the system consists of multiple components which can be tailored according to the project needs, allowing developers to craft customized user experiences without needing to build out an entire UI from scratch.
I’m all for the idea behind this—notably in code. I’m still weary to go all-in on this within Figma given its limitations related to variables. That said, it’s exciting to see folks exploring this space.
These tips in and of itself aren’t why I’m linking this. Rather I see these kinds of micro optimizations ideal to bake directly into a design system. Refinements like using small caps for acronyms are exactly the kind of things that rarely get implemented uniformly in a product. But a well-adopted design system can go a long way to making sure they do.
Embodying a service-oriented mindset, proactively reaching out to teams, and being genuinely kind and curious are critical muscles for design system teams to devleop [sic].
It’s frightening that this far in the growth of this practice that people need a reminder to talk to the people using the system. Our job isn’t rocket science. Talk to your consumers. Ask for their feedback. Address the feedback. Yes, there are cases where reality is more nuanced. No, it’s not a 100%, slam-dunk approach. But in my experience, it’s the way to go for the vast majority of cases.
Don’t overthink things. Talk to people. Ask them what they need. Then do that.
After a few decades of watching this kind of knowledge slip from organizations’ grasp, I’m getting a little discouraged. Ever since I discovered Doug Engelbart’s proposals for collaborative knowledge work in the mid-1990s and the existence of the field of knowledge management shortly thereafter, I’ve been waiting for (and doing my best to model) better knowledge-capture and -sharing systems.
I’d give my left pinky finger for a dedicated content designer on my team. Content design is so undervalued in the industry. But I consider them a powerhouse on design system teams. This article points out something I’d never thought of—that they’re also oh-so-great at forming the internal narrative and information flow. Now I think they’re even bigger powerhouses!
Copying is fundamental to design, just as it is to software. The rise of permissive licenses and version control tools makes it seem like copying is a new idea, an innovative approach in an industry that thrives on novelty. But the truth is, copying has informed art and industry for thousands of years.
I have an ambivalent relationship with copying because so much of my point of view is wrapped around the intent behind it. I copy, you copy, we all copy. But one can copy to derive something new, whereas another can just brain-dead, mouth-breathing, carbon copy. And that’s a problem because it’s propagated/perpetuated so much crap.
Copying is rampant in design systems. One could argue its benefit to further standardize interface patterns. I say pfft. I’d argue it’s done more harm than good by, among other things, adding fuel to the fire that design systems aren’t “innovative”. Honestly, I don’t know what that means, but I know it’s not meant as a compliment.
…generally taking the following simple steps will suffice.
- Take the cheaper faster option.
- Take the cheaper faster option.
- Goto 1.
No one is ever going to curse your name for whipping up a quick fix. You’ll be the star of the show by making the latest problem disappear with your slapdash hack. It’s all unicorns and rainbows and love-fests… Until it’s not.
Our current generation of software is, to put it lightly, not great. There’s a lot that goes into why that’s the case, but a substantial portion comes down to chronic myopic decision making. Quality does not come from choosing the cheaper/faster option. But it often makes you popular in the corporate setting. And that’s why it’s so prevalent.
I think a lot of it comes down to simply not understanding how a few short term decisions can snowball into a Death Star. Which is a perfect segue to the next article…
One of the biggest challenges to recognizing an exponential trend when you see one is that they always seem to be underperforming compared to the more incremental, linear trends that more traditional businesses rely on.
That’s the problem about just adding one more thing… In a system, it’s not one thing. That one thing connects with all the other things and gets incredibly complex incredibly fast. Much of the disconnect between design system teams and consumers of design systems is this disconnect. Consumers see a simple linear request for a minor addition. System designers (often implicitly) see an exponential explosion in the making.
Writing docs first can help you iron out implementation details ahead of time before making tough calls about implementing a design. Even reference APIs can help you make a lot of designs.
API design is design. I’d go as far as saying it’s some of the most critical design in a design system. I don’t think this is a prevailing opinion in the design systems community, but I hold it nonetheless.
This is yet another opportunity for me to soapbox on the importance of documentation. If you don’t buy into the value of documentation for those reading it, then perhaps this article will shine a light on the value it brings just from the act of writing it.
The reason the persistent and the obstinate seem similar is that they’re both hard to stop. But they’re hard to stop in different senses. The persistent are like boats whose engines can’t be throttled back. The obstinate are like boats whose rudders can’t be turned.
Design systems require persistence. It’s typically not the well-worn, easily-trodded path within companies. Funding will be lost, secured and lost again. People will not understand the value, no matter how much you evangelize. Folks won’t want to use it for a myriad of reasons—some good, some maddeningly not.
Persistence is crucial. But obstinance—or to be fair, too much of it—is a death-sentence. The author does a good job delineating between the two.
These models we construct out of intuition and habitus allow us to mentally simulate situations. And out of these simulations, understanding. From understanding, empathy.
I see design systems as a tool, but a unique one. It’s not just a functional tool, it’s also paired with human knowledge (best practices, usage guidelines, etc.). I’d go as far to say that it’s the human knowledge which makes a design system—otherwise the tool is just a UI component library.
This article isn’t about design systems, but it does speak to the value of human understanding. Ultimately that’s what attracts me to this field. Sure, a lot of the work is about cranking out UI components, but the important work is defining a human point of view on how to best use them.
Outcome-driven strategy is about defining a desired state for your target market (vision) and the actions needed to realize that state. Unlike results-driven strategy that optimizes for extracting value from the an existing state, outcome-driven strategy is about creating a demonstrable change to the way people think and behave to manifest that desired state.
Design systems are a long game. While many in software think in quarters, design system teams need to be thinking in years. I understand and value OKRs, but the author does a great job articulating their weakness. Yes, it’s valuable to have short-term goals, but they need an ultimate destination out in the horizon to be pointing towards. Without that, you’re just myopically bean counting.
A decent amount of this talk, while interesting, isn’t necessarily relevant to design systems. But the heart of the talk does a great job articulating just how much of a mess we’ve made in the world of software. Unfortunately it doesn’t provide a ton of detail on how to fix that mess, but that may be asking for too much.
It is to our benefit, and to the benefit of our industry and society at large, to advance mental models that reflect the reality of our work and honor its essential creativity.
Much to my confusion, I’ve heard that developer experience has recently become a four letter word. Which is strange because it’s two words and has much more than four letters. People are pitting DX against UX, which is also strange because developers are users. So, if you care about UX, it seems like you’d care about DX. But I digress…
There’s a lot to glean from this article and one could quite easily replace “Developer” with “Designer” and collect the same value. I know speed and efficiency are all the rage nowadays. I’m just as guilty, if not more, of fanning those flames. This article touches on a subject I’m beginning to noodle on in my head—that yes, reusable code speeds things up, but a huge drag on productivity and quality of work is the constant distraction of today’s work culture.
I’m not planning to abandon design systems, but I could see myself dabbling in ops to tinker in that headspace.
The details are not the details. They make the design.
First off, that quote isn’t from the article, it’s from Charles Eames. But it’s a damned good quote and on topic.
This article also has almost nothing to do with design systems. But, I think it’s a great example of the level of detail design systems should strive for. No, most feature teams nowadays don’t have the time to ruminate on the nuances of a progress bar. But design systems can. They can sweat these details and subtly, yet profoundly improve an experience.
Sweat them details. They matter.
I think there are whole categories in business like this, where some of the world’s greatest geniuses have solved extraordinary engineering problems but have completely failed to take the psychological component into account.
Design systems are 20% design, 20% writing, 20% engineering, 40% sales and 100% psychology. That adds up, right? Jokes aside, this is such a worthwhile article to read as it articulates that all the academics of system design don’t matter if you can get people to use it. And getting people to use a design system has everything to do with understanding human behavior.
I have no doubt the Figma 2024 preview reveal was great for many people. What I saw was loss of focus. I see more attention and talent spread across more features that have increasingly less to do with the core experience.
I’ve used this metaphor a million times, but I want my hammer to be the best tool possible for driving nails. I don’t want it to cut wood. Figma continues to sprawl while there’s still so much room for improvement in its original purpose.
I also want to acknowledge that I’m weird. I frequently spend more money on things that offer less. I am not representative of Figma’s consumer base and they are, after all, running a business. It may just not be the tool I reach for on my own time.
System designers require more tools like this. I don’t think this is the ideal form, but it shows hints. How do you design a system without seeing how a decision propagates and impacts the entire system? This is the space I hope to see more peeps exploring. I think we should be designing less individual doodads in a silo and more overarching rules/models at a higher vantage point.
There’s a “stability vs innovation” dynamic that can sometimes feel like competing tension, but what we’ve found is that is that stability and innovation are more complementary than competitive.
You can innovate without a stable foundation, but not over a sustained period. Not continually. That instability will stifle progress harder and faster than you can imagine. I’ve seen it too many times first hand. A culture of innovation depends on a strong foundation.
I like this video because I think it’s a great example of lauding flexibility in a clearly constraint-based system. Their dashboard typography has infinite options…all using one typeface. And don’t get me wrong—constraints are totally my jam. Sometimes I think system designers try to overcompensate in their communications around constraint. Instead of hemming-and-hawing about what they system doesn’t allow, I’d take a cue from this video and focus on what it can do.
Let’s say you were employed as a CTO behind the front lines and you wanted to destroy productivity for as long as you can without getting caught. You can of course make a series of obviously bad decisions, but you’d get fired quickly. The real goal here is to sap the company of its productivity slowly, while maintaining a facade of plausibility and normalcy. What are some things you can do?
This is another one of those not-design-systems articles that could easily be discussing design systems. I think the real value of a design system is the behavioral change they typically create once fully operational. And a lot of the points for tanking productivity are typically addressed once that behavioral switch is flipped.
Content is one of, if not the most undervalued element in a design system. This video is a bit of an oldie (in Figma years) but a great case study for how content standards can be integrated into not just a design system, but a Figma library.
The implementation details may be slightly out of date, but the core idea remains just as valuable. It’s a must-watch.
Even though writing styled-components with bespoke CSS over and over was really slow and led to literally thousands of unnecessary lines of styling, it had one major benefit: people could easily try stuff.
I think some people forget that actual people need to be able to use your design system. Many of those people are not Figma/CSS savants. It’s incredibly important to remember that a system that isn’t approachable isn’t used. I’ve seen some design system wizardry in my day and a lot of it was too damned clever for its own good. Fancy is fun and it’s great to nerd out on theory, but bias towards simplicity and approachability.
Today, color modes like dark mode and high-contrast accessibility mode are table stakes in design systems. So, if you’re picking colors manually, you have to pick an additional 50 colors for each mode, carefully balancing the unique perception of color against each different background.
However, with the functions-and-formulas approach to picking colors, we can abstract a color palette to respond to any background color we might want to apply. Let’s go back to the lightness formula we used in the previous palettes:
Find a comfortable place to sit before you open this link because you’re going to be reading for a while. I’m not a fan of color—there, I said it. Working with color is increasingly demanding a PhD in mathematics. And while I’ve written a line of code (or 90,000) related to color manipulation, it’s just getting increasingly complicated for diminishing, if not questionable, upside.
However, unpopular opinions aside, Matthew does a great job in this article outlining the state of color in today’s practice. My biggest takeaway from this is that our practice is firmly in the “messy middle”.
Consider the overlaid promotions, tips, or call-outs typically found in an interface. To get these elements noticed, designers will apply contrasting colors, shapes, fonts, and more. All in an attempt to make things pop. But if a pop-up or any element of a user interface for that matter looks too different from the rest of the design, people will often perceive it as something that doesn’t belong (like an ad) and dismiss it.
Imagine if this is accurate and all that additional work people do to diverge from a design system actually performs worse… Imagine how much of a lose/lose scenario that would be… I’m all for going outside the bounds of a design system, but at the very least have some evidence that it’s worth it.
A final use case for leaning towards novelty over familiarity could be when exploration or surprise is the desired outcome. This might involve leveraging novel interaction patterns that will stand out and make the experience more memorable. Non-conventional techniques such as scroll-based interactions are a way to create immersion and engage users through richer engagement with content.
There’s a direct corelation between the first article and this article. Yes, novelty is helpful when trying to generate surprise or a memorable experience. But here’s the question that’s often unasked, “Would the person experiencing this consider it worth being memorable?” Of course the people making the experience want it to stand out so people take notice. But when everything is novel, nothing is.
Having an established process allows heterogeneous teams to work in tandem. From a business perspective, it also helps mitigate risk—since decisions tend to be more thoughtfully documented and consistent. Even when something goes wrong, having a set process allows teams to understand where things derailed so they can course-correct faster.
Design systems and process go hand-in-hand. Both work towards the goal of standardization so that large organization don’t devolve into a puddle of goo. I have a hypothesis that you can predict how an organization will respond to design systems by how they respond to process. If every team has their own bespoke way of working, there’s a good chance that design systems will be met with skepticism.
But just like design systems, process doesn’t need to be stifling. If wielded deftly, it can become a common language for people to rally around.
When implementing components from a design system, consider developers’ familiarity with plain HTML. By adhering to the principle of least astonishment, ensure components behave like native HTML elements, making them intuitive and easy to use.
First off, today I learned about the Principle of Least Astonishment—which is awesome. I quoted this sentence because it encapsulates part of what makes design system so hard. I think we all agree in theory about the principle of least astonishment and naming things to be intuitive. But what happens when different platforms all have different names for the same thing? Do we have separate names for each platform? OK, then what about Design? Do we give that another name altogether?
Design systems get stuck trying to make order out of an incredibly chaotic and fragmented landscape. Astonishment is a frequent occurrence.
Like so many performance indicators, adoption has been a popular metric because it is easy to measure and easy to understand, making it ideal for reports to executives whose buy-in we need. Adoption is also an easy-to-impact metric because it can be pushed as a mandate, making it an even less reliable indicator of a tool’s ability to drive bottom-line value.
Easy to measure? Now I just feel inadequate. I’ll be the first to say adoption measurements will be an eventual pain in our collective butts. That it’ll be the thing that a very nuanced subject gets dumbed down to. And then I’ll still be the guy that advocates measuring it. Because it’s incredibly useful.
I agree that a design system’s impact on efficiency is a much better indicator of value. But adoption is also really important—because it’s going to help you understand how much the company can leverage the system to make widespread adjustments/improvements. Want to redesign your app? The level of effort could differ by orders of magnitude based on the level of adoption.
Adoption as a metric is flawed, but so are plenty of valuable things. I don’t think we should throw the baby out with the bath water.
I am not linking to this article because I believe this particular study is valuable in relation to design systems. Instead, I think it’s something we should see more in design system documentation. We need more science!
Why would we ever need more science you ask? Surely, the vast majority of people will not read through the study. To which, I would agree. The reason why I think it’s valuable to have research findings in documentation is to validate beyond as many decisions as possible with objective, unbiased research.
It’s incredibly hard to get large groups of people to swim in the same direction. Especially when it’s one opinion versus the other. If we’re expecting people to follow our best practices and use our patterns, the least we can do is offer proof that they work.
…a concrete definition of UI density: UI density is the value a user gets from the interface divided by the time and space the interface occupies.
I’m not sure I’m fully bought in to what where this article landed, but I like the idea behind it. I do like two specific things however: 1. I like the attempt. While I’m not so sure about the final definition, I think having something like this could be valuable. 2. I definitely like the idea of pumping as much meaning into an element as possible. Think of a nutrient-dense vegetable versus a cracker. Design system components should aim to be the vegetables of UI modules.
Reading in the classroom has moved away from encouraging students to dive into a whole book and moved toward students reading excerpts and responding to them. ‘Even in elementary school, you read, you take a quiz, you get the points. You do a reading log, and you have to read so many minutes a day. It’s really taking a lot of the joy out of reading.’
You may think this article is completely unrelated to design systems, but you’d be wrong. Experts hypothesize that kiddos aren’t reading as much nowadays because the reading they’re assigned is joyless. It would be lovely to verify this hypothesis, but I’d say there’s serious merit to this conclusion.
How many times have we heard people don’t read documentation? A lot. But guess what, documentation is often written as though it’s intended to be a sleep aid. Yes, documentation needs to be clear and concise, but it doesn’t need to actively avoid being fun. People like fun—so add some fun into your documentation.
But once you view debt as narrowing what you can endure in a volatile world, you start to see it as a constraint on the asset that matters most: having options and flexibility.
I’m allergic to debt. All debt. Debt takes your hands off the steering wheel. We all hear tech leaders talk about the importance of velocity. However, I’d wager to say what they really want is agility. And debt absolutely obliterates agility.
Yes, design systems help teams move with greater velocity, but more importantly, they enable agility in two ways. 1. They reduce UI tech/design debt. It’s hard to overstate just how much tech debt can limit options. 2. Design systems enable macro-level changes in hilariously/frighteningly little effort. A color palette change or icon redesign can be a herculean effort without a design system. With a design system, rollout can take less than a day. Minutes at best.
Moving fast is great, but changing directions (without the gLoc) is perhaps the least understood value systems bring.
What you don’t see is what people in the past were more able to see. When you are in groups, you can be very powerful. You can change things. You have confidence when things go wrong that you don’t when you’re on your own. That’s why the whole concept of power has dwindled. We’re encouraged just to talk about ourselves and our feelings towards others. We’re not encouraged to see ourselves as part of anything.
There’s a lot in this article that’s tangentially related to design systems. I think the crux of why folks buck the idea of design systems is that it’s disincentivizing individual expression. Design systems think of people in groups which is in direct conflict with the world view of design system consumers.
I’ve come to the conclusion that 80% of design systems are about getting people to work as a group—whether or not they’re aware of it. And, boy is that hard.
So you see that there’s a good reason why many typefaces are not as legible as others. It’s simply not what they were meant to be – and that’s a good thing. We should have many more typefaces that are playful at the cost of being harder to read. But not in user interfaces. There, we certainly don’t need typefaces that are harder to read than they have to be and that have no personality on top.
This is a great post to read if you are one of the lucky few who have a say in what typeface is used in your design system. There’s plenty of chatter about stylistic choices of typefaces, but not enough about how to impact legibility.
It’s time to embrace wearing the marketing hat. By proactively raising awareness, building advocacy, and proving impact, you’ll transform your design system from a helpful utility into an indispensable centerpiece of how your organization crafts amazing digital experiences. The work won’t always be easy, but the payoff of an enthusiastically embraced design system will be well worth the effort.
I’ve spent the last eight or so years selling design systems. There isn’t a person around who’s more understanding of the importance of marketing. But… Marketing can quickly morph from a means to an end to the end-all. Yes, promoting a design system’s value is critical, but don’t forget that you ultimately need to deliver something worthy of promotion. It’s just too damned easy to get a taste of what good marketing can do and lose sight of the actual job.
Complexity signals effort. Papers with difficult ideas and technical details suggest blood, sweat, and tears. Systems with more components and features hint at more effort than systems with less. Because complex artifacts are viewed as requiring more effort, they’re also deemed as more challenging to create and thus more worthy. And because of the perceived effort involved, they’re often judged to be higher quality.
Man, this is a good writeup and it does a great job encapsulating how organizational dynamics make simplicity hilariously difficult. Complexity often looks impressive at first glance. Given many organizations don’t have time to devote towards a topic more than first glance, things all start to make more sense.
Simple looks easy. And easy doesn’t make people look smart.
…polish is something only the person who creates it will notice. It’s a paradox; polishing something makes it invisible. Which also means that pointing out examples of polish almost defeats the purpose.
This article is covering an important topic, but I just wish it was less highfalutin in how it discusses it. I’m not so certain all polish is invisible. I think polish is often easy to detect, but hard to isolate. But you know what’s really visible? Something that ain’t got no polish.
I’d argue that polish is not as invisible as it’s amorphous. Right up there with “craft”.
For us, writing equals thinking. And it’s a big part of how our team has worked. What was different about it this time was that we were sharing our work (what we wrote) much earlier. Because we found so much value in it, we’re now writing documentation earlier in our design process.
I don’t have any direct knowledge or experience with the Spectrum Design System, but I’ve been truly impressed with everything I’ve seen and read from the outside. The scale of Spectrum is bonkers—some of stats I’ve heard thrown around sound like video game numbers. I’d expect that scale to weigh the quality down, but that doesn’t seem to be the case here.
And I wonder if this article provides a small window in why that may be the case. It ticks a lot of boxes for things I have seen work—customer-focused thinking, documentation-driven design, sharing early and often. Kudos to team Spectrum, they seem to have a good things going.
Recipes serve as an important pressure release valve for the natural tension that arises between a design system and the products it serves. A recipe layer gives product teams the autonomy they need in order to make the best products possible while still working with the grain of the core design system.
I am a big fan of recipes, especially the “Compositions of design system components” variety. I’m such a fan, that I think all recipes should be collected/socialized within design system documentation. And if not directly in the documentation, directly adjacent to documentation. This is something I plan to noodle on in the future.
And on the subject of recipes, this is a lovely example of just that. I see no reason why a design system couldn’t have an equivalent bank of ready-to-use compositions that aren’t components (yet). Throw in a code view for engineers to yoink from and you have a really helpful resource.
Juice can add soul to software but is mostly absent. Because we underestimate how much feelings influence our lives. Even the definition of Juice states it’s non-essential. It is non-essential to functional requirements, but not to emotional. Emotion is essential to being human. It’s why music exists in every culture in the World. It’s why some of the great works of humanity are artworks. Not because of their function, but because how they make us feel.
If there was ever an ideal location for Juice, it would be a design system. The author makes a strong case for the value of adding juice to enhance experience, but it can go off the rails extremely fast. The magic about juice is that a little goes a long way. And that little amount needs to be the same flavor. Pineapple juice mixed with tomato juice ain’t going to delight anyone.
A design system can help direct, focus and regulate how much juice gets dispensed. And that’s a very good thing.
Big, flashy things get noticed. Quiet, boring things don’t. A lot of design system work is the exact opposite of glamorous, and this effort is no exception.
Boring things make the world work. Bridges, sewers, and design systems. The world would look significantly different if human psychology could maintain the awe of running water. But we don’t. This article has some interesting ideas on how to quantify the unnoticed value of design systems. But ultimately, the author lands in the same domain of fuzzy math that so many of us reside.
Design teams often follow these isolating practices despite strong indicators that successful digital products are made by teams that are deeply integrated with engineering. Not to mention, this waterfall approach to design slows down the work immensely. This is quite the paradox — one might wonder what design teams are spending so much time on that justifies being so detached from the technology they’re designing for.
There’s a lot to pull from this article, but the above quote is an important one. I marvel at the fact that it’s 2024 and the gap between design and engineering remains. I don’t think it’s going away anytime soon. However, I don’t see that same gap in design system teams. Which is why, among a slew of other reasons, that I think design systems are going to come out of this market correction stronger and with more influence. Even if we make boring things.
And no, it didn’t get past me that this article directly links to a super interesting critique on the harmful effects of design systems. I’ll probably write about that in a future week.
We’re pitching the value of a design system as a time-saving, plug n’ play collection of LEGO bricks when we really should be pitching the Building Instructions instead. You know, that little booklet that comes with all the cool sets that shows you how to build the thing step by step?
I once said that design systems are like legos, after you connect the pieces appropriately and then super-glue them together. Yeah, that’s definitely on one end of the spectrum of views, but I still believe in it. Yes, it’s nice to have some stray pieces in the box to deal with what comes up. But the core pieces were put together for a purpose. And that purpose was not to disassemble and make something else altogether. Why include building instructions for something already built?
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
It’s worth understanding the thinking behind Conway’s law because there’s a good chance it’s going to influence how your team works and what you end up producing. When I was younger, I resisted unstoppable forces like these. I’ve learned better as I’ve gotten older.
By having a real, dedicated team it means the design system can flourish. Bugs can be addressed in a timely manner rather than being thrown into an abyss that never gets looked at. New features can be added to the design system, which further improves the lives of the people using it.
I think the real value of “productizing” a design system is not that it’s treated like a product. Sure, that’s helpful, but I think the overwhelming value comes from what that mindset change represents. Once something is a product, you need folks who own it. You need people who are accountable. You need to define success.
I think it’s the structure of productizing that’s important. Maybe that’s just obvious and I’m deluding myself that it’s worth bringing up…
I vacillate on the value articles like these provide to the community. On one hand, it would be nice if there was a general understanding of what a design system is. Having to roll that boulder up the hill isn’t fun. On the other hand, I question if there is a common definition. Hell, we still can’t align on what Design is or what it encompasses. Articles like these that attempt to “answer” often just create more questions.
I think things like Design and Design Systems are less something you universally define but rather develop a localized point of view on. An organization can absolutely decide on a what a design system is to them. But getting that universal “answer”? I’m not so sure.
Building UIs has a very long tail: it’s fairly easy to get the basics for a given component working, but there are many details to consider, and these add up to a majority of the work.
Read this article and tell me front-end skills aren’t a vital part of creating software. There’s so much detail that goes into component development. As the author says, it’s easy and fast to get something. But not so much to get something good.
Modern design languages offer a lot of flexibility with their focus on fundamentals like typography, white space and simplistic icons. But sometimes, using an old school real world metaphor adds a lot of delight to an experience.
See: Pendulum swing. I see the flat design movement akin to manufacturing decisions for mass production. Flat design enabled a much more streamlined and reproducible interfaces. But… Maybe some of those interfaces felt a little.. mass produced. I don’t think that’s due to the flat design aesthetic, but rather the lower barrier of entry.
Don’t weigh other design system’s decisions too heavily. You have no idea the constraints they were working under to arrive at their decisions.
There’s tons of good tidbits of advice in this article. The article doesn’t go too deep into any, and that’s OK. I could quote a ton of the bulletpoints from the article, but instead I’ll just suggest you read them yourself.
We all have to force ourselves to see the truth, because the truth hurts. The truth is that our ideas weren’t right, our insight isn’t shared by customers, our awesome design is confusing, our potential customers love that competitor we’ve been calling ‘dumb,’ that thing we say is ‘broken’ is not in fact broken, the pain we insist our customers are experiencing, they’re not experiencing. Did you even ask? If you asked, were you listening? If you haven’t made major changes to your strategy and product and positioning, then you’re blundering. Seek the truth, then face the truth.
In many ways, design systems are like mini startups within a company. You’re often bootstrapping your “product”, being scrappy to find consumers within your company—all with the hope of gaining investment to grow and scale. This article is super helpful to contextualize how to avoid the kind of mistakes that can tank your precious startup.
Craft isn’t glamorous. In fact, it can be pretty boring. Craft doesn’t require innovation or a big show, but the curiosity to consistently study your materials and practice your techniques. It’s knowing that big moments are made of tiny ones. That every second counts. For a chef, it might be peeling the mushroom skin even if clients will barely notice. For a designer, it might be organizing files even if that work is not going to be celebrated. Everything we do informs how we approach our lives.
Craft and quality continue to be in the current spotlight. What’s been missing (for me at least) is a dissection of how we ended up in our current position. That’s a whole subject altogether, but I do think what’s been forgotten or glossed over is that craft takes work. Like, a lot of it. And it’s often hard, menial, unappreciated labor. Things like organization, creation of detailed specifications, file hygiene, precision in execution. Design system teams know that because it’s typically a huge part of the day-to-day. I’ll be interested to see how this conversation evolves, but it’s interesting how the unsung ‘grunt work’ many systems teams have taken on for years is now coming back into fashion by the broader design industry.
I like to put it this way. Of the people who see your math paper, 90% will only read the title. Of those who read on, 90% will only read the abstract. Of those who go still further, 90% will read only the introduction, and then quit. Thus, it pays to put a huge amount of energy into making the front end of your paper clear and enticing. This can reduce those 90% figures (which I made up) to about 80%, leading ultimately to an eightfold increase in the number of people who read beyond your paper’s introduction.
There’s a ton of nuggets of wisdom in this article related to making something typically dry (math papers) into a more engaging ring. There are numerous lessons from this that can be applied to design system documentation. Give people a reason to read.
I will go to my grave holding the belief that documentation does not need to be “we’re so serious because this is serious business”. We’re writing about how doodads should show up on gadgets. Let’s have some fun people. I’d bet the farm more people would read “fun” documentation. Seems like a win-win.
So, what have we learned so far? Good typography can make your documents more influential and easier to consume. It can change people’s impression of your ideas and induce creative thinking. These benefits alone are enough to see that good design is scientifically proven to be impactful.
This is an absolute must-read—there are tons of great tactical learnings that can be applied to typographic systems. Additionally, it proves that aspects of design can be scientifically proven. There’s been a recent recoil from designers on the pressure to prove the value of design. I understand the frustration, especially given design can be harder to objectively measure than other aspects of software development. I don’t agree with the mindset that design is off the hook to appraise its impact. This work from Microsoft is proof that design’s worth can be measured/defined. I’m convinced more research like this will clear a path for greater understanding and valuation of design in the industry.
This blog post is the poster child for why design systems are feature teams’ best friend. Sure, a feature team could make their own avatar (or whatever) component, but are they really interested in the amount of depth/detail necessary to make it work across all use cases and scenarios? I think more blog posts like this which expose the iceberg of component design can be a great wake up call for teams who’d rather, “just make their own”.
But when it comes to design systems work you often have to explain to folks why your job is worth doing in the first place. As a product designer or engineer you might have to argue for a feature or even fight for the existence of a team if you’re unlucky, but you rarely have to deal with the existential threat that your whole career shouldn’t exist.
Relatedly, in my experience the number one psychological drain on design system team members is a lack of external understanding/recognition/valuing for what they do. Nearly every pain point comes back to this issue.
If there’s one thing design system practitioners should know before starting is that “making the case” is part of the job. It may be leadership, it may be consumers, it may be external customers. It may be all of them. It’s something I’ve come to expect given how long I’ve worked in this space. Accepting that as part of the work has made it much easier and, dare I say, fun part of the job.
It’s also critical for design system managers to be keenly aware of this issue and have a continually evolving strategy to support your team through this. Not just as a shoulder to cry on, but to get the team to a better place so they no longer need a shoulder to cry on. Easy to say, hard to do.
While there is some truth to Meta’s (Facebook) famous slogan ‘Done is better than perfect’, we’ve slowly begun to believe that ‘done equals perfect’ or at least, perfect enough. Sure, shipping early may be necessary to live up to customer expectations and needs, but it’s not sustainable in the long run.
Quality is all up in the current zeitgeist. I’m not confident that this pendulum swing is going to result in any true, sustained change. But that’s another topic for another day. I believe Anton calls out the obvious, but important fact that the iterative and “fix-it-later” nature of software development has atrophied teams’ ability to ship high quality experiences. What was the strength of software has become a hinderance.
This article isn’t directly tied to design systems, but the topic of quality is. If I was a betting man, I think these next couple years will see design systems playing a central role in raising the quality bar of software. Which is incredibly interesting as it’ll signal a change in focus from efficiency to refinement. That is, if this push towards quality doesn’t fizzle out beforehand.
A micro-interaction is a small, task-based interaction in digital products. It provides feedback or visual responses to user actions. These interactions guide users as they offer subtle cues about how to use a product.
This article is exhaustive and a great place to start for any system designer interested in learning the subject matter. Micro-interactions are a super interesting space to play in and the prototypical wheelhouse of design systems. These are the fine details that can raise the bar of quality so many companies are talking about. However, without restraint and continuity, they can do more harm than good.
I haven’t used this plugin and this is in no way an endorsement. I link to this because I think it represents a great way to educate designers on how to use a Figma features, components, libraries, etc. Written documentation is ideal for some use cases while video tutorials are ideal for others. Why not use both in their ideal fit?
Vercel consistently delivers easy-on-the-eyes interfaces and their new Geist documentation site follows suit. I’m less sold on its content and some interaction decisions, but it’s undoubtedly handsome. Which is why I added it to the list this week. I notice a lot of design systems teams—including ones I’ve been responsible for—put emphasis on the meat-and-potatoes at the detriment of visual appeal. We know for a fact those meat-and-potatoes are critical to a design system’s usefulness, but they can also fall under the radar for many folks.
I admittedly have a love/hate relationship with “veneer” as it is often misused to mask foundational gaps/failings. But it’s damned near impossible to ignore the impact it has on an unfamiliar and/or skeptical audience.
There’s something inspiring, yet demystifying, about watching a lump of clay turn into a final vessel, or a plate of ingredients into a delicious meal, or a series of pull requests into an elegant piece of software. When we can observe the process, we naturally pick up little habits, tricks, and techniques that strengthen our own work.
I enjoyed the premise of this post, although I’m not sold on the conclusion (e.g., buy our product). There are many things that I think add up to a team producing great work. One of the more critical things is what this post describes due to how it influences the work. If literally everyone will see your work, things like clarity of communication, attention to detail and strong organization skyrocket in importance. It’s far easier, and dare I say worth it, to cut some corners when the audience for your work can be counted on one hand. That’s not the case when the audience is everyone.
Where I diverge is that I don’t think we need another tool to do this. We can do this today—it’s a mindset shift, not a solution gap.
Edit: It’s worth noting this post was inspired by Robin Sloan’s preceding thoughts on the subject.
We often talk about ‘stability’ in software engineering, but in my work, I’ve found it more helpful to talk about ‘resiliency.’ Design is a frequent subject of iteration, whether via aesthetics, function, or code. Brand language evolves or is reinvented, products grow or fragment, interfaces are refined and reorganized. In all of these situations, the nature of a given design is changing in terms of both ‘what’ and ‘how’ — therefore, the code responsible for design needs to be more resilient than stable. That is, our code should be amenable to substantial changes in requirements such that implementing the desired modifications is possible with a minimum of friction while still achieving the desired outcome.
There’s a lot to this post (which is a great read), but this section stood out the most. Yes, resiliency in design systems is critical as they are often the most effective way to usher in those changes in requirements. A redesign with a design system is hard enough as it is, but without one, it can be an existential challenge for teams lacking serious operational and organizational horsepower.
You’ll rarely discover ‘what’s next’ by standing still. Start working on something. Start tinkering. That will put you in motion to figure out what ‘the thing’ is.
Is this advice specific to design systems? Nope. But it’s especially helpful for our practice given how systems can so frequently feel overwhelming and everything-all-at-once. Often times the best advice is to take a deep breath and put a foot forward. Do anything. Then learn. Then repeat.
…AI tools can supercharge many facets of design system work. Of course it’s critical to stress that all of this is emerging technology, has the potential to do a lot of harm, and should be handled with care. A human-centric mindset along with a healthy level of skepticism (especially in these early days!) should be employed when wielding these new tools.
I’m thankful for teams like this doing the homework around how AI can be employed within the context of a design system. This is going to be increasingly a part of our lives, whether we like it or not. I agree that it could be a major help, if used responsibly. And, as Brad mentioned, skepticism is going to play a major role in whether that happens—or not.
Bold elements demand your attention. When too many elements demand attention it can make an interface worse. Good design is partly about how attention is directed. That becomes harder when lots of things look important. They distract people from whatever is actually important.
I’ve been thinking more and more about how to employ an “emphasis” ramp within design systems. I think design systems can get a bad rap because they frequently have to play on the safe side. So visual styles tend to get muted so they’ll work in whatever circumstance. I would be interesting use have an emphasis dial (beyond size or primary/secondary) where elements can be amped up or chilled down based on need.
I’m admittedly shooting from the hip with this idea, but this great article (which you should totally read) immediately made me think of it.
That’s it, no duplicative versions to showcase changes across breakpoints, no time-consuming red lining necessary in order to communicate how the style should change as the screen does. The fluid and atomic foundation built in to our atomic content components handles those repetitive design decisions for you.
Folks in the design system space take something like this for granted. It’s simply a given. I don’t think that’s necessarily the case outside of the practice. In my experience, teams are typically time starved. What’s one of the (many) things suffers? Yup, documentation. Lack of time means less documentation means engineers aren’t up for success means a lower quality end product. A mature design system is a major win as it removes gobs of functional requirements that would need to be documented. The bigger win is not needing to have everyone understand the nuances of those functional requirements. THe bigger, bigger win is not dealing with inevitable lost-in-translation deviations at scale if they were expected to.
The GOV.UK Design System makes it [shipping a redesigned crown] possible to do this in a consistent way through its centralised open-source codebase, GOV.UK Frontend. The Design System team updated the crown in versions 5.1, 4.8 and 3.15, to make sure that services using older versions of GOV.UK Frontend can update it as easily as possible.
Yes, design systems speed up workflows. But that’s really just the start. The increased speed/efficiency enables new ways of working altogether. This is something I discussed often at Pinterest. The speed a design system brings allows for greater agility, and thus a more nimble product development process. Want to redesign your icons every 6 months? I wouldn’t suggest that, but with a mature and well adopted design system, it’s entirely feasible. One person can redesign icons, swap out the assets of your system’s Icon component and voilà you’re done. That’s just not something that would even be up for consideration without a design system.
I would really like to have the chance to work on an email design system. It seems super challenging, it can be a huge time-sink for teams to work on (which amplifies the value of systemizing) and it’s typically a “needs improvement” area for companies in terms of design. Looking through Stack Overflow’s design system gets me even more eager to play in this space. Big props to them for opening it up.
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.