I found this resource helpful, especially as it pairs tools with associated educational material. I’m as big of a tool-head as anyone, but I also intimately understand that tools without skill aren’t going to be helpful. I’d recommend spending most of your time reading the articles linked on this site and then looping back to the tools afterward.
This case study is a nice introductory primer to paying off design debt. If you’re still new to the subject, this will be helpful.
I dislike debt as much as I dislike complexity. Probably because they’re usually one in the same. Payoff of debt typically happens when the pain just becomes too immense. In super proactive teams, it’s a recurring process—maybe on a quarterly or bi-annual process. However, I’d love to find ways to have debt payoff weaved into the daily design process. That’s admittedly easier said than done. However, just like documentation has been weaved into many design system teams’ processes, I think the same can be done for debt reduction.
We know that design systems are multipliers. A single design choice that we make can quickly get scaled across multiple products, affecting hundreds, thousands, or even millions of product users.
I think it’s hard for folks outside of design systems to fully understand the immensity of some challenges within the practice. The scale, breadth and complexity of challenges within systems are unlike anything I’ve ever encountered elsewhere within software design. Simply trying to wrap one’s head around a problem can by itself become overwhelming. So, yeah, doing that for too long is going to leave a mark.
I wish there was a guaranteed solution for this. I don’t think there is. However, I do think the simple act of genuinely caring for the wellbeing of our peers is a great place to start.
Full disclosure, I know Josh Harwood who helped make this site. I typically don’t post links from people who are direct friends/colleagues, but I was planning to post this prior to knowing he helped make it. So, take that for what it’s worth.
That being said, this looks like a great resource for folks who are interested in joining design system community events. It even has an RSS feed to subscribe to (thank you).
Half of working-age adults in the UK have low numeracy. Around 1 in 20 people have dyscalculia, which is a specific and persistent difficulty in understanding numbers.
There are some extremely helpful nuggets of information in here that I’m absolutely going to be pulling from whenever the subject of number standards come up. These details make a huge difference and it can be incredibly difficult. Of particular interest was their recommendation to not use numeric times for midnight or noon/midday—I didn’t see that coming. Keep in mind, these guidelines are in the context of health information, so some suggestions may not apply.
What is a design system if not a collection of rules? And what is a rule if not a law? With that out of the way, I think there’s a lot to pull from the format of this site in relation to design systems. This is one of the (many) omissions to Gestalt that I wish could have been addressed long ago. Establishing strong, direct and highly visible “laws” that drive its direction can have a major impact in helping folks connect the dots as to why XYZ component works a certain way or ABC pattern is designed as such. Making something like this isn’t necessarily the easiest thing to do, but lordy is it helpful.
Apple and Google get it wrong just as often as the rest of us. Their tendril-like presence in our everyday lives does not make them any better, and their people no worse. What ‘standards’ they have defined have been through brute force — Apple brought down Flash but wants phones with no physical affordances, Google built the most powerful search engine of the day but pushes half-baked features to its browser.
This is how poor work propagates. And that’s no snipe at any company or any individual—we all create poor work. But some poor work gets the proverbial pass using the argument of ethos. There are just far too many examples of that not holding water. And the real problem is that this work spreads like wildfire—which makes it even harder to push back against when it’s become a de facto standard (see: TikTok’s video interface).
Good work is good work because it’s proven to work. Who did what/where has no place in the assessment.
This Wikipedia page is a good segue from the previous article as it lists out the many, many logical fallacies that have been defined. I find this resource useful as so much of working in design systems is about forming and debating concepts. I believe the absence of a strong logical foundation will ultimately sink a design system. Being able to understand and articulate logical arguments is critical. Exposing illogical arguments is even more important.
A design token is a glorified variable
Pretty much. Now we have yet another term for folks to learn, but I digress…
This article is a helpful window into where our practice is headed in regard to variabl—ahem—design tokens. Defining a standard is going to be critical to enable smoother transfer of information between touchpoints. My two cents is to not rely on a tool like Figma to manage tokens, but rather have it be yet another tool that ingests from a standard data source. But that’s just me.
What I’m most excited about is what can come after this. The ceiling is so high for design tokens and I’d love to see it cover topics like color combinations, type pairings and motion treatments.
If you stick with your constraints long enough, your style becomes a cohesive and recognizable point of view.
I don’t know Steph, I’ve never met him, and I didn’t know he existed until I came across this post. That said, I get the sense he and I view the world through a similar lens. I’m a little envious (that’s a lie, I’m tremendously envious) of this post because it encapsulates so much of what I’ve tried to say for years in one effin’ blog post. The post may not be directly written in the context of design, but to be honest, that makes it even better.
Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behavior, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.
I appreciate that this site exists—it’s important given the current state of digital products. To me this is simply good design. I think I’m splitting hairs to be honest. I think the big takeaway from this is that consistency is also a major benefit in terms of accessibility. Consistent placement and interaction patterns are even more important for people using screen readers and navigating through keyboards as it enables repetitive manual tasks to be performed more efficiently.
Instead, the right question is, ‘Will the user’s current knowledge help them understand how to use what I’m designing?’ Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs.
I was generally agreeing with this article until the quote above because I think it opens the door to some pretty wrong-headed thinking. The article starts with a criticism of defaulting to patterns from other products—which I wholeheartedly agree with. The proposed alternative is to focus on “current knowledge” of the user. I have problems with this because I don’t think it’s practical.
The “user” for many products can be one of millions of people, living anywhere in the world, ages 5 to 90 with 10 seconds to years of experience with your product. Common knowledge for one group of your user base can be diametrically opposed to another group. Additionally, common knowledge can vary dramatically just between features in a product. Taking this thinking to its extreme means we develop different solutions to similar problems in a product based on variances in common knowledge. Maybe I’m reading this article wrong—I want to acknowledge that, but this seems like a simplistic take to a pretty damned complex issue.
Yes, it’s essential to take a user-centered approach towards design. No, we should not simply copy/paste solutions from other products without understanding context and impact. However, the larger and more diverse your userbase is, the less likely there’s common knowledge between them.
That’s it, that’s the post.
To be fair, the post didn’t really need to add anything more. If you’re working on a design system and it’s not being used as much as it should, I highly recommend developing an incentivization plan. The whole “if you build it, they will come” approach is a recipe for disappointment.
If I could do this whole design systems career over again, I would have put much more emphasis on content than on doodads and widgets. I say this for a couple reasons:
Words really do matter. More than we (continue to) give them credit.
In 2019, when our leadership at Spotify unveiled their ambition to make audio content available and consistent to anyone on any device, our design team faced a significant challenge: Spotify would now be available across 45 unique platforms, and over 2,000 types of devices spread across 200 brands. This meant that someone could be jamming to their favorite tunes from their living room TV, continue the party in their car, and carry that into the work week with a “focus” playlist on their computer.
If this reads like a challenging problem, it’s because it is. Well, OK, I don’t want to speak for Spotify, but having worked for a company that had a similar level of platform coverage, it always made my head hurt. How much do you follow the nuances of each platform vs. maintaining a consistent cross-platform experience? There’s likely going to be complexity in whatever decision you make. I’m glad the Spotify team is bringing up this topic, because it’s one of the really challenging subjects with (in my opinion) no universally-right answer.
It takes a different mental framing to fix this situation: KPIs should be used in combination with human intuition to enable optimal decision-making. So not just intuition or data, but a constant back and forth of making (i.e. intuition) and testing (i.e. data) hypotheses.
I am a firm believer in design system teams defining KPIs. I am also a firm believer that KPIs will not provide a full picture of success/failure. For the past five or so years, I’ve been using the term “evidence-based decisions” as opposed to “data-driven decisions” because of my mixed relationship with metrics. Metrics are an absolutely essential part of understanding how a design system is used, but it is only a part. The McNamara fallacy is term coined for exclusive quantitative decision making—and its failings.
So while I agree with the general premise of the article and not betting the farm exclusively on KPIs, I disagree on intuition being the its counterpart. I’d suggest replacing intuition with qualitative research. Intuition is necessary at times—most notably when there’s a lack of evidence, but from my view that should be a last resort. I’ll take qual evidence over intuition (including my own) any day of the week.
As we navigate constraints, it’s critical to champion the time and space needed to uphold craftsmanship principles integral to our profession. We should prioritize quality over speed and ensure that a culture of speed doesn’t overshadow our work. When time constraints dictate work culture, haste precedes quality, and quick fixes supplant well-considered solutions.
I am all for slowing down to move fast. And no, I don’t think speed on its own is a leading indicator of success. However, I don’t think it’s accurate to see quality and speed as naturally diametrically opposed forces. There’s plenty of instances where something of immense quality is created in a fraction of the time expected. Sometimes work drags on and nothing of quality comes from it. Pitting these two concepts against each other infers something of higher quality always takes more time. That’s often true, but not always.
This is relevant to design systems as that’s the exact value that design systems can provide. Higher overall quality in less time. I’d argue the issue isn’t quality versus speed, but rather quality versus imprudence.
One thing I know is that it’s hard to convince fancy-pants designers to practice boring design. And I hear the same from other UXers all the time.
Want to be a good whatever? Nail the boring stuff. Practice the fundamentals, understand the basics like the back of your hand and execute well. Chances are that’ll get you 90% of the way there. The last 10% is fancy stuff. It’s not that fancy isn’t important, it’s just not as important as the “boring” basics. Good basics will make a lack of fancy acceptable. Fancy won’t fix poor basics.
Don’t overthink things, folks. Embrace Occam’s razor, nail the basics and move on to addressing the next “boring” thing.
Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.
I started reading this post thinking that this is a development-centric writeup that is extremely relevant to design systems—not knowing it would mention design systems at the end. Funny enough though, I think the first half of the post is the most interesting as it discusses the perils of building opinionated, prescriptive components and patterns with no “bare-metal” options. Funny enough in Gestalt, we have quite a few building-block components, such as Box that is, well a box (we get really creative with our naming). Box is our way for customers to opt out of Gestalt while simultaneous using Gestalt.
I both love and hate this component. I love it because Gestalt is built on Box. How could I not love the component that built our system? I also hate Box because it’s a hyper-effective opt out mechanism from using our more opinionated components—which flies against our goal to get people to opt in. This is an eternal balancing act—abstraction vs bare metal, standardization vs. innovation, efficiency vs. flexibility. There’s no right or wrong here but more of a state of balanced or imbalanced.
One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the ‘problem’ is that someone really wants to use the technology. If that is the case, you should immediately abort.
This is a worthwhile read even if you haven’t written a line of code in your life. There’s a lot to like in this article, but what I like the most is how universal the issue and solution is. This same line of thinking is absolutely essential in the design process. Aim for a boring-and-good solution that covers the greatest surface area. Then grab a refreshing drink and appreciate all the time and pain you saved your future self.
I love that this site exists and I wish more people would do the same. It’s still a little light on content as it just got started, but I wanted to link to it in the hope that it’ll be a small/humble encouragement to keep it up. Our community could use more independent resources of information.
In a perfect world, feature designers & engineers know, understand, and create with guidelines in mind. There is no need for guidelines checks throughout the product / feature creation process.
Unfortunately we don’t live in a perfect world and guidelines require a considerable amount of reading and comprehension in order to effectively put them into practice. When guidelines aren’t outlined as requirements to launch by leadership, it’s difficult for feature designers and engineers to prioritize the time it takes to learn. Especially if there are no consequences for not adhering to them.
Speaking of Medium… This article was just too good to not add and I don’t know how it took me ~2 years to read it. Linzi (the author) is a wealth of knowledge and I thoroughly enjoy her writing/thinking on design systems. This article outlines what I consider to be the central challenge (and fun part) of design systems. It’s easy-ish to make a system that works for a product, but it can be downright crushingly difficult to get people to use it and use it correctly. There are some interesting nuggets in this article about how the Lyft team is thinking about ensuring adherence.
Nathan agrees: ‘I see documentation websites diminishing, as more products like Figma that incorporate design systems provide that natively within the app. Over time, I anticipate more and more systems-oriented docs embedded within a tool like Figma so that people need not leave to go to a site to learn how to use things or make the right decision.’
I understand that Figma is going to be promoting content that promotes Figma, but this was perhaps a little too heavy handed. I also understand why Figma wants to become a source of truth for an organization, but I doubt that will be realized. Given that design systems, a) support people working outside of Design and, b) those people outside of Design far outnumber designers, I fail to understand why we would place our guidance in a tool used almost exclusively by designers. Secondly, if there’s one thing we’ve learned, it’s that design tools come and go. The last thing I would want is to lock a design system’s guidance to a tool that may no longer be the best in market.
I’m all for delivering guidance in tools like Figma, VSCode, etc. that are derived from a central source of documentation. But I would encourage folks to think really hard before taking the kind of leap Figma is insinuating.
This is why we believe that to scale a design system and get wide adoption, the ideal is to have a dedicated, multidisciplinary team, with dedicated time to work on it. It is also crucial to give this team the authority and power to make decisions, to make them as effective as possible.
I’ve had a hunch for some time that multidisciplinary people thrive on design systems. The Gestalt team is chock-full of T-shaped folks and those where tech is a second career. I think this is important to call out as one way to encourage a multidisciplinary team is to bring people on with no design systems experience. Now, I’m the first to say that this should be done within reason and that this doesn’t make sense for every role on a team. However, I cannot think of many better ways to inject new ideas into design systems than by hiring people are are new to design systems.
If you’re redesigning an existing website there are huge benefits in getting to know the content you’ll be working with. The earlier in the project the better. A little upfront investigation will help you make informed design decisions.
Do me a favor and just mentally replace any reference of “website” in this article with “design system”. The thinking still applies. One thing I’ve been discussing quite a bit frequently is how foundational research/information gathering is to design. That’s all the more the case within design systems. I good ol’ fashioned audit can be a critical step towards making an informed decision. And what better tool is there for a good ol’ fashioned audit than a good ol’ fashioned spreadsheet?
But when it comes to changing systems, our everyday cause and effect intuition fails us. Increasing dollars spent per child at schools doesn’t seem to improve educational outcomes. (Where does the money go?). Countries that impose travel restrictions a few days before their neighbors have exponentially lower fatalities from COVID-19. Teams whose members gel well outperform teams with more accomplished individuals, but lower team cohesion.
Linear changes produce nonlinear results. The whole is not its sum. Our intuition flies out the window.
This is a great read on general systems thinking. There’s no mention of design systems in particular, but I think it’s no less relevant. To clarify, no I don’t think this essay will help you design better components, but I think it can be very helpful if you’re trying to understand more complex human factors such as design system adoption. I won’t pretend I fully understand everything in articulated in the article, but I was left wanting to learn more.
For me, understanding and articulating why something feels right does not come as intuitively as designing something to feel right. But they are two sides of the same coin. There must be a reason. It can be as simple as a particular spring curve or something more innate, like metaphors. Analyzing and making sense of design details beyond just “it feels nice” helps nurture taste, amplify level of execution, and grow appreciation for how hard the pursuit of excellence is.
If there’s one word I would like removed from the design lexicon it’s “feel”. It’s not that feel isn’t a part of the process, but rather it isn’t productive means of critique and an even less productive means of justification/articulation. Feel without a breakdown of what make that feeling is often incredibly difficult for others to replicate/follow. You may see where I’m going here…
A design system can’t just deem what feels right. It needs to tear down the attributes which lead to that feeling and give people the tools to build reconstruct it on their own. Otherwise, feel can just seem like, your opinion man.
In this week’s installment, I don’t even try to hide my attempt to coax you into writing.
The best way to form a complete and balanced perspective on any topic is to attempt to write about it. If there are any angles that I got wrong, someone will let me know about it. Besides correcting errors, I’m astonished by the volume of useful articles, books, podcasts, and introductions that my writing has generated for me.
I consider writing to be a core competency within a design systems team. The articulation for how to apply a pattern/rule/concept and they “why” behind it can be just as critical as the patterns/rules/concepts themselves. I’ve found that the process of writing guidelines strengthens my thinking behind them. Meaning, if I can’t clearly communicate how to use a thing properly, there’s a good chance there’s a bigger problem at play.
What I especially liked about this article is that it shows just how much derivative value and influence the act of writing can have on individuals and teams. Not only that, but unique value compared to other mediums such as video or audio. And I could not agree more.
Of course, as designers, we take steps to ensure that our copy is concise and unambiguous, and if we’re decent designers, we’ll also consider how our tone and language matches our branding, how it will be received and interpreted by our users, and how actionable it ultimately is. However, this is often a post-hoc process, somewhat divorced from the rest of the product design cycle. None of this ever gets a chance to influence the Information Architecture for instance, nor the Visual Design.
This article treads some of the same ground as the previous post, but this writeup also delves into the importance of writing within interfaces. I could write about this topic for days. I first wrote on this topic roughly seven years ago and I am flabbergasted that writing continues to be an underutilized skill within design. Good writing is good interface—and thus can replace what we typically consider interface (e.g., buttons, inputs, etc.). In retrospect, maybe that’s exactly why writing still hasn’t been embraced by traditional design practices.
Writing within the design systems space is fairly appreciated, but not enough in my opinion. Given systems often peddle in components, it’s in the team’s interest for teams to use them as much as possible. But does that always lead to an ideal experience? Could a good sentence remove the need for that extra button? I think there are ample situations in the world where the answer is strongly, “Yes”.
If you want to learn a new topic–write about it. When I want to learn a new programming language, I write a short program using that programming language. When I want to understand how something works–I write an article on this blog about it.
Real writing, where you try to dig the truth, will require you to try and experiment. I’ve learned more by writing articles on this blog, than by reading programming books.
Reading is a great way to transfer information into one’s brain. But there’s a big difference between obtaining information and actually understanding it. And that’s what this author articulates so well—writing on a topic has been the most surefire way for me to wrap my head around a topic and develop a cogent point of view on it. And what are design systems if not a point of view on how to create an experience?
While it’s good to obtain information through reading, it’s just as important (dare I say more) to come to a personal understanding.
While we do not reject technology and innovation outright, we believe there is immense value in traditional design methods and techniques. We should not be so quick to abandon the wisdom of our past generations in our rush towards the future.
I’ve been on a big slow-down-to-move-fast kick lately—especially in the context of design systems. So this site was checking all the boxes for me. The quote above really stood out as it is so common to consider what is old as outdated or obsolete. Yet, so much of the fundamentals of design articulated nearly 100 years ago remain true to this day.
To make our color contrast checks more efficient, we automated the process using a script. Instead of manually testing individual color pairs in Figma, we changed the tokens in the code and created a script that could automatically perform contrast checks for all tokens across all themes.
Props to the Github team for taking accessibility seriously and driving towards a more usable product. And yeah, given the sheer amount of color pairs possible in most design systems, this screams out for the need of automation. I keep telling myself that I’m going to toy around with the idea of tokenized color pairings (ideally with my buddy Ayesha), but alas there’s never enough time.
I must say, the Cedar site is lovely. Just a wonderful balance between personality and practicality. Hats off to the team.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefitting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
As a person who is a smidge obsessive of developer experience in his day job, this was a great read. And if you too are in the business of design systems, you are in the business of developer experience. And I found this read compelling as a counter-argument towards some of the go-tos in the systems practice. Well worth the read.
The sooner you realize that there’s bullshit everywhere, the better. We all try to do our best, yet are all humans who make mistakes and years of experience, the number of blog posts or salary doesn’t account for the person’s knowledge. After all, we can all post on the internet whatever we want.
I cannot emphasize enough how often folks fall prey to this—especially within design systems. People, please do not take a blog post or writeup at face value. None of us (maybe not even the writer) know the efficacy of what’s being shared. What’s worse, some of what’s written is pure fabrication. Company blogs are notorious for sharing their “success stories” that, in reality, were anything but. And we fall for it, hook line and sinker.
Just be careful. Believe it or not, some of the stuff on the internet isn’t true.
Creativity thrives on constraints. Knowing how to cut with the grain makes getting the most out of the material much easier. While we’ve thankfully moved on from the pixel-perfect nonsense, with its spacer gifs and rounded corner images, the no-constraints thinking of today still exists in that mind space.
I am fully cognizant of the power native mobile platforms contain, but the web will always be where my heart is. And that’s because anyone with ample curiosity and patience can learn to build on the web. In retrospect, I think that quality of the web was a large reason why I moved into design systems. Because you could design the things directly in code that could act as the building blocks for everything. And in doing so, you render the abstraction of traditional design tools moot (at least for those comfortable enough to design directly in code). That approach has always made more sense to me.
The trouble is that while a certain brand or theme might have a few base values which give it personality, the final collection of tokens to define a theme will require slight variations of these base values for a properly curated presentation.
What if we could instead allow for a few values to be set in a theme to inform the rest of the values in some specified way?
This reminds me of this not-so-oldie-but-goodie writeup on utilizing functions in design systems. It’s this very issue which has leads to bloating color palettes and type ramps, which leads to high complexity. There’s absolutely, definitely something to this line of thinking and I keep wanting to explore this topic more.
Completing the cycle of the garbage-in-garbage-out principal will look like the future generation that grows up consuming ML generated content. What adverse effects will this have on human thought?
Yes, this is an AI article. No, it doesn’t cover the topic of design systems even a little. But given how much AI is impacting everything, including design systems, this is a good read.
Design systems undoubtedly offer valuable benefits, but they can unintentionally stifle creativity and drain the fun out of our digital experiences.
Man, this narrative needs to be put to bed. To this day, I’m still immensely flattered that people think that design system teams have the kind of sway and influence some think we do to have make every app look and feel the same. This viewpoint unfortunately lacks connection to reality.
Yes, many apps do seem to have features and aesthetics converging. Yes, that is potentially problematic. No, that has little to nothing to do with design systems. The root cause is much more rooted in an over-reliance on mimicry of what’s perceived as successful. Are design system teams guilty of this in blindly copy-catting other design systems? Absolutely. But they have plenty of company. This is a much, much bigger issue than design systems.
As people who have worked with ‘the content stuff’ in design systems, we’ve seen it play a critical role. Taking content seriously helps at every stage, from creating the system to documenting it and promoting its use.
If content design isn’t one of the most undervalued trades in the business, I don’t know what is. I’d give my left arm for a content designer as there’s just so many ways someone with that skillset would improve our system. Looking back, I wish I would have worked harder to hire a content designer for our team or found ways to uplevel our team’s collective capabilities in general content design. Lesson learned.
Systems mapping is a set of methods and tools to help us make sense of the ‘mess’ of complex problems, through maps of important relationships.
This topic is interesting to me as I’d wager a majority of systems designers would consider their system a ‘mess’ of complex problems. Part of why systems can become messy is exactly because it can be difficult to visualize its totality in a way that can be grokked. It’s for that very reason I want to begin taking some of these methods for a test drive.
If you ask me, we need more design tools like this. I frequently lament how modern design tools are still primarily a suped-up drawing tool. Which is fine if you’re primarily drawing, but not so hot if you’re working on interactive, state-based interfaces. There’s a lot to like with how this tool goes about developing behaviors. This tool uses Markdown to define flows/behaviors, which makes the data portable and readable. I will definitely be following this project.
We have a lot of customers who all have different use cases to fulfill with the design system. When trying to meet many different needs at once, a “this versus that” approach simply won’t do. We need aspects of both customization and configuration, working together.
I’m interested to see how maintainable this approach is in the long term. The idea is interesting, but it comes off as less design-systemy and more ui-frameworky. However, no matter where you sit on the spectrum of opinion, there’s some nice nuggets to glean from this article.
In 1994, Frank Duffy defined the idea six of ‘Shearing Layers’ for building. Stewart Brand expanded on this idea in 1999, with six ‘Pace Layers’ for civilization: “The fast layers innovate; the slow layers stabilize. The whole combines learning with continuity.”
Pace layering is my new fascination. I’m still new to the subject, but from what I’ve already gleaned, there’s just so much that can be applied to the subject of design systems. Stability (not related to bugs, but rather in the general sense) is an undervalued attribute in the software industry—at least in my experience. What I love about this topic is that it helps define the things that can/should change rapidly and the things that shouldn’t. This article does a pretty good job covering the topic, but I bet there’s a lot more where this came from.
Expect to see more tools like this as design systems become bigger and wider and more complex. Expecting a large group of people to read and accurately comprehend a mountain of documentation seems unrealistic. However, tools that guide you to appropriate usage seems much more doable.
Speaking of tools, Adobe’s token visualization tool is sure interesting. Upon immediate use, I would be interested in an inverted view - where one could select a design token and see what components inherit it. But maybe that’s just me.
Also speaking of tools and speaking of Adobe, Leonardo seems like a really slick toolchain for generating a color palette. There’s just so many ways one can paint oneself into a corner when constructing a palette. I wish I had access to a tool like this when I made my first few color ramps.
This notebook was created as a learning exercise to teach myself about color theory. I have interleaved some lightly altered prose from a variety of sources which I found informative, which I have made a best attempt to cite in the References section at the end of the notebook. I would like to extend my thanks to the cited authors for their work.
If you’re interested in a serious deep dive on color spaces and their application, then this is the article for you. I was already quite certain I was a color moron prior to reading this. Now I am very certain.
From a tech perspective, design systems can save up to 37% of development time and 30-35% of tech-reduced costs. As a result of improved design efficiency, design production time can be reduced by 27%, resulting in savings of 8,222 hours per year, while product quality can be improved by 18%. Further, design systems can increase consistency, leading to a higher level of user trust, resulting in a potential increase of up to 23% in revenue.
That 1/3 velocity improvement just keeps coming up… Funny enough, our internal interviews at Pinterest landed on the same general number. Estimated time savings are always tricky to measure, but I think I’ve seen enough smoke to believe there’s a fire.
With the capabilities of natural language processors, we can create a new approach to teaching UIs. User-driven UI. Instead of pushing features onto the user, the user pulls them in when needed. The software always presents a new user with the MVP. Regardless of how many features have been added since the initial release.
While this article is about reducing the learning curve and cognitive load of an interface, this thinking could potentially be applied to systems as well.
First, we conducted a quantitative study that investigated five variants of the carousel component. 202 participants answered questions as to whether they agreed with certain design characteristics, and to indicate their expectations for the number of items in each variant.
This is super interesting work and I love the rigor, but I can’t get past two thoughts:
I can’t speak to how Fluent is working for folks within Microsoft, but from the outside looking in, it sure seems like one hell of a design system. The polish detail and pure production value is incredible and maybe even a little jealousy-inducing as I can only imagine the budget and resources it took to make this a reality. Again, these are all uninformed observations, but it sure gives me the vibes.
So, big kudos to the team and to Microsoft for making this a reality. This seems to have set the bar even higher.
A design system’s primary purpose is to serve as a single source of truth. When a design system is compromised, it no longer serves as a trustworthy source for product consistency and coherence.
I added this article not because of the specific suggestions (they’re fine) or even the subject of the article (which is also fine). I added it because of the quote above and how important trust is for a design system. I’m beginning to come to the conclusion that the greatest success a design system can achieve is to be seen as an institution. And institutions are built on trust.
That conclusion is starting shape my view on how to go about making a design system. Instead of guidelines or components, the most important things a design system can build are relationships, confidence and belief that the system will eventually get to that ideal state. Sure, practically speaking, that’s achieved through building guidelines and components. But you can make those things in a way that creates or erodes trust. I’d make the case to take the extra time or have the extra conversation to always be building trust.
And yes, testing is important too - obviously. But to me, it’s less interesting how to test and more so about why it’s so damned important to begin with.
The design systems community is about as welcoming and generous as you’ll find. I’ve met countless people who I both respect and thoroughly enjoy talking with. If you’re in the bay area, I’d suggest checking out this Design Systems Community Chapter. I’ll bet the farm you’ll meet some great folks.
This is another system design tool from the same cut of Shaper that is starting to define what a full-fledged system design tool could be. I think dedicated tooling is the ideal next step for this skillset. Figma ain’t it, at least how it currently works. There’s a need for a tool which designs the thing that designs the things. Do I know what that would look like? Nope. Do these begin to tickle my imagination? They sure do.
My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them. But hiding those mistakes and shortcomings by glossing over everything doesn’t just make it harder for us personally, it hinders progress within the field itself.
Bingo—this drives me batty. Design systems are incredibly challenging at the best of times due to their sheer scale and complexity. Mistakes are commonplace and their magnitude can be crippling. No one has “figured this out”. There’s no 5-step process to a successful design system. It’s galactic arrogance at best, willful grifting at worst.
And the speaking circuit is especially packed with this dysfunction. Attendees are showered with talks about how some speaker figured it all out and are winning their way through life. I obviously can’t attest to every talk, but I do know that many are taking some excessive liberties in their storytelling. People have books to sell, courses to pack and personal brands to inflate.
But that results in many folks who come to the conclusion they’re woefully incapable and the only kid on the block and hasn’t figured this all out. The truth is, no one really knows what they’re doing. We’re all muddling through it. And it is incredibly hard.
But saying things like that doesn’t sell any books.
To be useful for you, a design pattern has to come out of and express some reusable part of your particular product experience — those parts of the design you find yourself making again and again.
First off, this article wins the longest-yet-clearest-synopsis-of-the-subject award. Secondly, I really like this idea because I think it allows system designers and product designers to rally around their venn-diagram overlap. System designer are hyper focused on understanding how a thing fits within the entirety of an ecosystem. This can get really serpentine when getting into the nitty-gritty details of how every facet of a UI element is compatible with the rules and models of the overall system. And the same goes for product designers—understanding the specifics of the business goals and customer needs is usually deeply entrenched knowledge for a specific team.
But a UI pattern? Hey, we both do that! That seems to be the best place to collaborate and then allow each team to apply their specific know-how to that common artifact. It just makes way too much sense.
…the tension between craft and scale in tech has much more to do with the size of the product you’re building and the speed at which you’re trying to build it.
I agree that craft at scale is incredibly challenging. Additionally, the more time I spend in this industry, the less I think craft isn’t the right goal to begin with. Craft is associated with quality—which I would argue is the ultimate goal. If that’s the case, there are other ways to achieve quality that are in fact scalable. If we set our goal short and focus on craft, it’s easy to get sucked into the mindset of craft for the sake of craft. And that’s of highly questionable value.
Concepts like relationships, contribution, and installation don’t just apply to components. They’re generic functions of documentation. With care, these can be defined for use across any documentation pages and any documentation projects. That’s where a functional approach to documentation is powerful.
We’re all shouting like maniacs about AI while there are much simpler and, I would argue, more effective way to streamline documentation by applying a functional approach to documentation. To be honest, I’m kicking myself that I hadn’t considered this a long time ago.
Good systems are hyperobjects that capture decisions, language, patterns, history, and all of the things that make and have made your organization’s design what it is. They resemble knowledge graphs far more than products, and I’d like to see some of the emerging patterns around software for managing a knowledge graph applied to design systems.
And I would as well, although with reservations. Knowledge graphs are intriguing yet seem like something that can become a tangled web if not well thought through - exactly like a design system. Nevertheless, this is a subject area that I would love to flirt with in the future.
Typically, headlines for a case study tend to follow both the conceptual structure of (1) Problem, (2) Solution, (3) Results and are literally written that way. But putting the headline Problem above a paragraph only labels it. It presumes that a scanner will read the text that follows. But since we know that the majority of scanners will not do this, re-writing the headline to summarize the paragraph’s content is the right thing to do. “Solution”, for instance, becomes “**Reduced Time to Market by 60%.**” This small copywriting effort serves 100% of your audience.
Who here thinks their customers thoroughly read documentation? Yeah, me neither. This article wasn’t written specifically for design system practitioners, but it might as well have been. The article (which I thoroughly read, by the way) outlines realities of content consumption and provides some useful/concrete suggestion on how to adjust your content accordingly. It seems like a no brainer to abandon the “generic headline” and instead use it as a set of TL;DR cliffnotes for guidance.
If you click on one link, from this week’s post, click this one. Pinda shares a damned smart way to systemize language in a way that I could actually see being used. I never thought of baking writing standards into Figma components. Kudos to this team for a damned clever solution.
As you develop your design system, ensure you strike a balance between expressive patterns and necessary constraints. When a design diverges from an expected pattern, it can offer valuable insight depending on the intention of the design.
I’d argue constraints are what makes a design system. This is a good thing. First of all, it (should) create healthy boundaries to guide folks to ideal paths. Secondly, it creates a healthy tension between status quo (what the system supports) and change (what’s divergent from the system).
Do you enjoy writing? And once you’re done writing, do you enjoy writing some more? Well then, dear reader, design systems may just be for you! This article is a helpful resource to call out some of the larger communication touch points for a design system team. And believe it or not, I’d argue the things listed in this article are just the tip of the iceberg.
So, kind design system practitioner, warm up them fingers, because you probably have some typing to do.
I’m intrigued to say the least. For teams who are just getting started in their own design system and/or don’t have the luxury of spinning up their own solution, this could be a huge starter resource. I’m still of the mind that things like this often make sense to eventually be built internally so you can get exactly what you need. But definitely not something to start with. At some point I’d love to toy around with this.
There are some pretty helpful tips in here. I learned about the HTML thin space entity (cool). Plenty of things that can be applied to a design system. However…
Don’t Use Helvetica, Inter, & Roboto
Mike lost me on that one. His argument is that those fonts are too commonly used. I’m may not die on the hill for those fonts in particular, but I’m firmly in Massimo Vignelli’s camp on this one.
This project interests/baffles me. I also have no idea how to make it work. This may just be due to the fact that I’m a dummy, but things just didn’t seem to work in a way where I could grok what was happening. Again, this could just be me, so take what I say with a pinch of salt. That said, the thing that clearly stood out is the potential for Figma widgets in relation to design system workflows. My mind is already racing.
This article argues that from film to fashion and architecture to advertising, creative fields have become dominated and defined by convention and cliché. Distinctiveness has died. In every field we look at, we find that everything looks the same.
This is a great article and I think the rise of the internet has only accelerated/exaggerated homogeny. Why do I bring this up in a design systems editorial? Because I see this happen all the time in design systems and I die a little inside in every instance. Don’t get me wrong, we shouldn’t ignore convention or deny its value, but I also don’t think it should necessarily be the default to follow what other systems do because, well, they’re other systems.
Yes, I know, this is hysterically ironic coming from someone working in design systems, but there you go. I’m a contradictory enigma.
There’s a lot to like with the thinking here. I don’t necessarily think this version of the idea will work for teams working on mid-stream design systems, but the concept behind it is lovely. I’d be so excited to quickly “prototype” how changes to core visual attributes would impact entire interfaces for the product I serve.
So yeah, this concept has legs. I would love to see it keep going.
Automated testing (will not catch most issues)
First off, I appreciate the Washington Post design system team for calling out that automated tests won’t “fix accessibility”.
Second, this is the kind of accessibility guidelines that we should all aspire too. It’s exhaustive, actionable and seems completely devoid of fluffy jargon like, “We care about blah blah blah.”
Third, from an entirely outside perspective, I’m damned impressed with the Washington Post design system’s documentation. It reads clearly, checks all the boxes and is damned handsome (in that classic journalism kind of way).
This article is in no way intended to be an ultimate guide.
If that’s the case, I’d hate to see what an ultimate guide looks like.
You can go really deep into iconography. I did once upon a time (link omitted to avoid any hint of self-promotion). The conclusion I eventually came to is that it’s (usually) not worth it. Here’s my advice: Make well-designed icons. Make them readable. Make them clearly articulate the subject. Make them simple to use within the system. And then move on.
The purpose functions as an entity of the solution, regardless of how it is shaped, its features, or how the code optimizations will evolve—the entity will always abide by its purpose.
The author makes a strong case for the importance of intentionally and doggedly defining each piece of a system, centered on purpose. This is hard work and often unpopular as it requires correcting and corralling. But those unsettled misalignments can set people up to fail and lead to poor outcomes.
Daniil on the Volvo team share how their team deals with the challenges so many design systems teams also face–namely fragmentation across system touchpoints and communication of status/updates. My two cents is that these are the problems I’d love to see tool makers focus on as opposed to yet another all-in-one design systems platform.
It’s hard to believe Storybook is seven years old now. While I’m not necessarily a fan of Storybook as the documentation solution for an established design system, I think absolutely has an important role in the market. If I was as a startup building a new design system from scratch tomorrow, Storybook would be on the shortlist for documentation.
A nice podcast episode primer on design systems which adds more proof that each and every design systems conversation devolves into a discussion about naming.
The most important lesson we learned after designing the new Wikimedia grid was to focus on what really worked for us, and not to worry about what is commonly used on other websites.
First off, it’s great to see the use of a grid by the Wikimedia design team. It’s astonishing how many modern software products don’t have a grid in use. Secondly, it’s nice to see folks putting some critical thought into the application of a grid as opposed to stubbornly sticking with what’s been used in the past.
A distributed design system could decrease an organization’s total cost of ownership as its development and maintenance can be shared by several product teams rather than one dedicated team.
Ah, the eternal promise of federated design systems. I for one have not seen this model play out as dreamingly – at least at larger scale. A federated model assumes a lot of things like equal contributions across all teams, agreement on how components/patterns should look and work and agreement on how all the pieces fit together. Those assumptions have often been in short supply in my experience.
When we say ‘design systems create a shared language’, a lot hinges on creating agreement on the specific names for things.
I’m just going to go out there and say if naming is the biggest challenge your design system is facing, you’re doing just fine.