A Zettelkasten is a personal tool for thinking and writing. It has hypertextual features to make a web of thought possible. The difference to other systems is that you create a web of thoughts instead of notes of arbitrary size and form, and emphasize connection, not a collection.
I won’t pretend like I’ve finished reading about the Zettelkasten Method. I haven’t. But color me intrigued. I have the feeling I’ll be going through it a a couple times to digest. I’m a big believer that design systems should emphasize connection over collection. So, a documentation model that mimics that philosophy seems like a perfect fit. I’m excited to read more about this.
I know I’m alone on this, but I’d love to see what things would look like if we had fully embraced the Unix philosophy (‘Make each program do one thing well’).
First off, the author is not alone. The current era monolithic applications/platforms are not viewed with adoration. I don’t see people massing on the streets to share how much they love all the software they’re forced to use on a daily basis. Too many are over-complicated, uninspired, and mediocre.
Those in the design system practice understand how important it is for each element do be narrowly scoped and well executed. Otherwise you’re building a house of cards. I’d love design tools to work similarly. I’d love small, simple, polished sub-tools that I can use independent of each other. Yes, the sub-tools can be combined/configured into more complex compound-tools. But, ideally people can choose how high up the food chain they wish to go.
Right now we’re stuck at one end of the spectrum. And it’s increasing in suckness.
The future of creativity won’t belong to those who generate the most, the fastest. It will belong to those who make things that matter. That’s still human work, and it always will be — only now, we have a new tool to wield.
I don’t make a big stink about it, but I firmly disagree that design systems aren’t a practice of creativity. Sure, it’s not the same type of creativity when we think of Hollywood-generalized design. But it’s there nonetheless. Design systems require a healthy dose of critical thinking in addition to creativity. Because systems are interconnected, every decision has major consequences. Every decision matters.
And I think this is why every attempt I’ve made at using AI within the context of design systems has not shown the promise others seem to be observing elsewhere. AI is fast–lordy is it fast. But it’s also hollow. And design systems are essentially meaning made actionable.
That’s not to say AI can’t help with the work around design systems. I’ve seen a ton of value there. But the core work is firmly in the wheelhouse of gray matter–and I don’t see that changing soon.
One of the rather tedious tasks of a developer is to generate changelogs. I cannot imagine that anybody enjoys going through the project history and try to reverse engineer what has happened since the last release. But the good news is that by keeping a clean history it is quite straightforward to generate those changelogs from your version control history.
Design system changelogs are another one of those boring-but-essential resources that are far too often glossed over. Essential as they may be, they’re sure tedious as hell to produce.
I love approach for many reasons. First off, it ensures that the team is providing a changelog–which, again, is essential. Secondly, it can dramatically reduce the overhead associated with producing them. Third, it acts as a forcing function to make commit messages actually useful. I’m already eager to see how our team can apply this approach towards our changelogs.
But beyond that, I think this can be expanded to design artifacts. And if you think design system code-based commit messages are useless, just take a minute to look through a Figma library’s version history… Give Figma as a version history REST API, I think there’s a real opportunity to leverage Figma’s saved versions to auto-gen a changelog. I can’t wait to give this a go.
This site acts as a cliffnotes for design systems. It doesn’t go deep into any topic, but that doesn’t seem to be the point. It provides bite-sized nuggets of information on all sorts of different subject matter. It’s a nice start.
I think it’ll ultimately require more information for the reader to sink their teeth into–either by providing it directly, or linking out to references that do. Nonetheless, this is a nice resource for someone to get a broad exposure to the practice.
The article outlines some clever ways to use Figma variables to accomplish things that aren’t necessarily common use cases for the feature. I say clever in complete neutral judgement as I think being too clever can end up biting you in the ass. Some of these examples (such as density) are what I’d consider good clever. Others, (like the state-based variables) stray into what I’d consider to be ass-biting clever.
However, the one I genuinely found the most intriguing was the wireframe mode. Now that is super interesting and one I think could change designers’ relationship with design systems. Pretty damned clever (in a good way).
But those folks in the middle are the ones that need to be able to translate from the strategic to the tactical and back again. They’re the ones who hear what leadership really wants and cast the vision for what the system needs to be. That vision casting is the beginning of cultural change. It’s the ideal future state you can only reach if everyone agrees to value the same things, to make really good decisions in the minutia of each day.
It’s no doubt that middle managers tend to play the bridge between executive leadership and ICs for design system teams. Which, makes sense given that’s the exact definition of middle management. But I’d argue a healthy team depends on a middle manager who’s devoted to making themselves useless. Being that bridge between team and execs is a exercise in the game of telephone. It’s far too easy for things to get lost in translation.
Rather, I think middle managers should help create infrastructure and practices so that ICs and execs can speak directly to each other effectively. Either directly (by actually talking) or indirectly, through having access to the same measurements of success. It’s too easy for middle managers to become a troll on the bridge instead of a bridge builder. Best to create a direct line of communication to ensure that doesn’t happen.
This situation was frustrating for me because of the amount of duplicate code I had to write and the added complexity of managing multiple testing environments. What I really wanted was a way to write component tests once and have them cover everything—without needing separate setups for different types of tests.
Testing in design systems is one the most important things the industry hardly ever discusses. Systems–especially mature ones–don’t have the luxury of crapping the bed. One button component bug can cause hundreds of thousands of bugs in production. Testing is what helps design system teams sleep moderately well at night. I love to see work and discussion in this space as we need a lot more chatter and sharing on this topic.
Properly used, color itself can convey information. It can reinforce typographic information, add to order and logic, indicate varying qualities and quanities, call attention and emphasize, establish tone or connotation, and clarify complex ideas. Generally speaking, use ‘neutral’ colors like black, white, and greys to just present the facts with no particular “spin”, and use other colors sparingly to reinforce or enhance a message.
If there was one thing I could convince design teams to adopt, it’s the mindset that color such be used primarily as an informational element of design as opposed to emotional. Gone are the days where color could be used willy-nilly in our basic little software applications. That lackadaisical approach just isn’t realistic given the complexity and deluge of information being presented in today’s software.
I’m not saying don’t use color (although, I’m close to believing that), but I am saying use with extreme care, caution and consideration.
I love Taylor Swift. I love dogs. I love music. I love swimming. I love Katie Ledeckey. I love film. I love cameras. I love math. I love school. I love Willow. I love pasta. I love water to swim in. I love water slides. I love my friends. I love ice skating. I love choreographing dances. I love science fairs. I love family. I love crafting. I love my doll, Kit.
My daughter Olivia wanted to make a guest contribution. How could I say no?
These are all relatively boring, unsexy ideas. But great software design is boring and unsexy. It’s easy to get excited about big ideas like CQRS or microservices or service meshes. Great software design doesn’t look like big exciting ideas. Most of the time it doesn’t look like anything at all.
I’ll say it until I’m blue in the face–the principles of effective software engineering design and effective software experience design are extremely aligned. My whole philosophy and point of view on design formed while working as a developer. Design systems require great engineering design and experience design to be effective. That seems like a lot until you begin to realize that they’re basically one in the same.
One definition of the good life is a perfect balance between useful work and contented rest. Michael Oakeshott, a thinker always worth considering, argues otherwise. He writes: ‘We spend our lives trying to discover how to live, a perfect way of life, sens de la vie. But we shall never find it. Life is the search for it; the successful life is that which is given up to this search; and when we think we have found it, we are farthest from it. Delude ourselves that we have found it, persuade ourselves that here at least there is a point at which we can rest—and life has become at once moribund. Just as to remain in love we must be continually falling in love, so to remain living we must be continually striving to live.’ Oakeshott is doubtless right. The perfect way of life is probably unattainable. Which doesn’t mean we are allowed to give up the search. The goal is elusive, the striving endless, and to carry it on through life requires—yes, you will have guessed it—lots of rest.
The article above has absolutely nothing to do with design systems. Frankly, most of it isn’t relevant to the topic at all. But this paragraph alone compelled me to link to it. I think it’s easy to get caught in the trap of trying to find the perfect solution in our work. After which we move on to the next problem to find the next perfect solution. And so on.
Part of me thinks we pursue this approach because, a) it feels good to feel done, b) it feels good to feel like we got it “right”, c) there’s a lot of money and status tied with being seen as “right”. But the truth is that perfection simply isn’t attainable. This is especially true in design systems. There’s no rest, there’s no “right”. Every decision has its tradeoffs. So, in a way, our work is just a series of failures with varying degrees of severity. Victory takes the form of infinitesimal failure.
The best folks I’ve worked with in design systems are keenly aware of this. They know that to play in this game is to constantly fail. You constantly let someone down. You constantly know you could have done better. And that’s OK. The goal isn’t to be perfect or “right”. The goal is to be just a little better tomorrow.
Maybe a smarter, more naturally gifted person can be sporadically brilliant, and solve a tough problem way faster than you. But you, with your staying power, can more capably and reliably solve the 100 problems that follow.
I couldn’t think of a better segue of constant improvement than describing the benefits of stamina with folks who work in design systems. Design systems work is all about stamina. It’s about not getting too low or too high, but setting a pace and keeping it steady. This is needed because the challenges are so broad and because the complexity is so high. A person needs to approach this kind of work knowing that the first, second, third, fourth, and nth attempt is going to be crap. The goal is to try again. Indefinitely.
A steady mindset and a long-term vision is critical for this kind of work. It puts the bumps in the road into perspective. What looks like a crater or a mountain at the ground level appears as a pot hole or mole hill at 50,000 feet. Getting too up or down about the latest situation is a recipe for getting chewed up and spit out.
I’ve said countless times that you can’t ever expect a developer to understand your design intention if you don’t understand the constraints of their platform. Typically, there are so many things at play within a production codebase that a lack of understanding can lead you down useless paths of exploration or prototyping that result in a huge waste of time and don’t actually translate to what gets shipped at all.
I do wonder if the industry is finally waking up to the superpower of design technologists. It’s only been a couple decades, but maybe it’s actually happening. A designer without an understanding of the materials of software is like a sculptor that doesn’t understand how to work with stone. You’re simply not going to get the most out of a medium that you haven’t directly worked with. And you haven’t worked with a medium until you’ve worked with it. Like gotten your hands dirty.
It’s important to state that design technologists have a unique skillset. The blend of design and development skill leads to capabilities that are greater than the sum of their parts. Maybe folks are starting to see this. Maybe, after decades of hamfisting our way to not-so-great outcomes, people will understand how valuable this role actually is.
And given how design systems innately work at the intersection of design and engineering, you’re not going to find a much better home for design technologists.
Companies that want to reduce the cost of their frontend tech becoming obsoleted so often should be looking to get back to fundamentals. Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.
There’s a lot to this article beyond this one quote, but I think it’s an important one. Front-end abstractions (like design systems) have been a way to make UI development more approachable to less front-end-capable engineers. They’re partially why front-end-only development jobs have been dwindling. I could see how folks think this is a strong case for specialists. And maybe it is. But I see this more as an argument for staying rooted in the basics. A design technologist can put all their time in learning React/Next.js/etc. Or they can focus on HTML/CSS/vanilla JS. While the former will appear more productive, that productivity is propped up on abstractions that will eventually become obsolete.
I’m all for specialists. While I’m biased towards generalist roles, I don’t think it’s an either or. Yes, a specialist will always have more specific knowledge/expertise in their area of focus. But generalists can make up for that lack of depth with an emphasis on the fundamentals. Generalists may have less depth of knowledge, but what they do know doesn’t go out of style.
We’re about to see a major shift in who can create, innovate, and compete in the market. The next big thing might not come from a giant company, but from a small team – or even an individual – using AI-powered tools. I expect an entrepreneurial surge driven by necessity and opportunity. How will you adapt?
I’m not big on trying to predict the future. But it’s just dumb to not look at what’s ahead and prepare accordingly. Design systems are naturally sensitive to external forces given their horizontal focus. As long as AI is impacting people making software (which it is) it’ll impact design systems.
I don’t know what the future holds. I don’t pretend otherwise. I don’t know what AI will do to our industry and, in turn, our jobs. I’m just trying to prepare. I have four different scenarios that have come to mind based on the current state of AI, the industry, and regulatory forces (or lack thereof). This is not an ethical analysis or some judgement on right or wrong. This is just how I could see this playing out.
AI doesn’t go away, but it also doesn’t turn the industry inside out. Businesses determine that AI-generated code results in greater debt and less resilient systems (assuming that’s the case–we don’t know yet). Companies may not hire as many folks, but their headcount doesn’t shrink by orders of magnitude. This scenario essentially means business as usual for our teams and our roles.
Let’s say AI lives up to the hype and companies need a fraction of designers and engineers to make software. Org charts stay the same, but there’s just less people. Well, that makes design systems a whole hell of a lot less valuable. Most system teams rely on scale to justify return on investment. The more warm bodies the system serves, the greater the impact of efficiency gains. When the people leave, the system’s return on investment dries up. This is the “uh oh” scenario for people working in design systems. The practice doesn’t go away, but the number of roles shrinks considerably.
AI still lives up to the hype. But rather than maintain the pre-AI way of working, companies further consolidate by running more work through systems. There’s no reason why design systems couldn’t work directly on features. Sure, processes would be different, but the fundamentals would remain the same. Instead of feature teams working with a separate design system team, the feature teams would be the design system team (and vice versa). Working with and on the system is innately how teams work. This scenario is a bit of a mixed bag. There are less roles due to further consolidation and those in the design system practice are now competing with traditional product designers/engineers for the same jobs. Although, I think folks on design system teams have a leg up due to an innate understanding of how to work on/through systems.
Let’s be honest, nobody knows what the hell is going to happen. I’m banking on scenario 4 having the highest likelihood of actually becoming a reality. But that doesn’t mean I’m not creating contingencies for the others as well.
I’ve noticed that many designers rely solely on intuition when it comes to spacing, and it’s not surprising. Correct spacing may appear simple, but it’s a skill that requires practice to master.
Developing a spacing system that’s effective and broadly applicable incredibly difficult. Doing that while also making the system easy to learn is even more difficult. The article above is a nice introduction to the topic, but it stays focused on the basics. I wish I could say I’ve seen a good example of spacing guidelines, but I’m still looking for just that.
Adoption is a double-edged sword—you need to migrate legacy designs and experiences while ensuring designers default to the new standard moving forward. This means tackling it from two angles: clean up the past and lock in the future.
Pro tip: Focusing on adoption in unfunded areas of the product can be a eas(ier) win. Trying to up adoption on features that are being actively worked on can be a recipe for pissing off a lot of people. Updating another team’s UI can break existing work, it can hurt key metrics, it can do all sorts of unexpected things. But modernizing unfunded areas of the product can make a design system team be seen as heroes.
One can argue whether adoption in areas of less focus isn’t as valuable. That’s a valid argument. But a lot of teams are simply trying to increase overall adoption as a way to show progress. And that’s also valid. If you fit in the latter camp, consider focusing on unfunded areas.
Dropbox’s brand site is fun. It’s visually interesting. It’s unusable.
There have been a wave of design system or design system adjacent sites that I’d call performative in nature. They look super polished and high production. They’re a blast to experience the first time. And likely intolerable the hundredth time. What separates the mediocre design system documentation from the good is how it feels after repetitive use.
Substance, people. Focus on the substance. That’s what is going to keep documentation useful and relevant.
Compounding complexity must be fought at every turn. Alternate between phases of expansion (new features) and consolidation.
I think the reason why so many “developer best practices” resonate with me so much in the realm of design systems is that design systems are software for making software. Some design work can remain separated from implementation details (to an extent). But design system are quite literally the implementation details. So the more design system teams operate with a developer mindset and with consideration for developer best practices, the better they’ll likely enable other developers’ best practices. Design systems aren’t going to help developers make good software if the system isn’t good software.
That’s not to say that designers don’t matter. They do. Which means design systems also have to operate with a designer mindset. Which, yes, is hard.
Building good software involves alternating cycles of expanding and reducing complexity. As new features are developed, disorder naturally accumulates in the system. When this messiness starts to cause problems, progress is suspended to spend time cleaning up. This two-step process is necessary because there is no such thing as platonically good engineering: it depends on your needs and the practical problems you encounter.
Yes, this site is from the previous entry’s quote. I’m adding this as its own entry for my own sake to make sure I know how to find it in the future. One process I began rolling into teams I’ve worked on was to spend the first half with a focus on expansion and the second half focused on refinement. I did this purely out of instinct and experience with how easy it is to collect debt while burning through the development of new components/patterns.
Debt isn’t a checkbox to clear once and be done. It’s a constant exercise to maintain. Seeing this called out be people far smarter and I is reassuring that this habit we’ve developed has merit.
We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels.
This week wasn’t intended to be so focused on software development, but I’m just going to keep rolling with it. This is less of an article as it is a series of statements. Many I agree with. The quote above is something for design systems folks to think about, because we’re sure as hell guilty of that.
But beyond that, I do think it’s time to take a minute to reflect on the utter horseshit mess “modern” development as become. Specifically for the web. Now, to a degree, I understand how we got here and I can see how each individual decision could have made sense in its specific context. But surely we acknowledge the current mess, right? The sheer level of complexity to create a website with today’s best practices is humorously obtuse.
On the bright side, the “not-modern” approach never went away. I encourage us to take the good from this era and aggressively eject the rest. Development, now more than ever, needs to be approachable. Let’s stop trying to be so damned fancy.
I understand the idea behind this and I’m all for good ol’ fashioned checklists… But I don’t think this is ultimately beneficial for the practice. Checklists can be help at the tactical/executional level–things like pre-flights for shipping a component or documentation checks. Check lists at that level are helpful because repetition in execution will help make outcomes more predictable.
That said, I’d argue that checklists at the level this resource provides are downright harmful. Half the challenge of design system work is shaping the system to fit a company’s culture/process/maturity/etc. Maybe design tokens are important–but maybe they aren’t. That kind of work demands not going through the motions to check off a box.
So, by all means, create checklists and get to checking boxes. But not when it comes to creating the foundation of a design system.
I may have found my new favorite word to use in relation to various tech topics. At least my favorite since ‘anagnorisis’.1 ‘Ultracrepidarian’, beyond being an awesome word, is defined as follows: someone who has no special knowledge of a subject but who expresses an opinion about it. I mean, how is this not the main word for the entire internet?
This article is a great read and acts as a cautionary tale for the design systems practice. Or really any practice. But design systems stand out as it’s such a new and broad topic. Design systems are not a new concept, but the official industry practice is still new. The first time I heard the term “design system” was in 2011. Let’s say the term is five years older than that. Based on that hilariously flawed method of estimation, that would put design systems as close to 20 years old.
It can’t even drink yet. Well, legally at least.
~20 years may seem like a long time relative to the internet, but it’s not close to enough time for ideas to shake out. Meaning all of us working on design systems, to varying degrees, are ultracrepidarians. Now, sure, we have more special knowledge than some random person walking down the street. But in the grand picture, not that much more.
So, a little humility people. When it comes to many design system topics, we just don’t know. We don’t even know what we don’t know.
Humankind has always fought death by using gimmicks to pursue immortality. In Antiquity, folks imagined that dying gloriously in battle would assure them eternal life. Today, people record videos, take pictures, and write books to keep their memories alive after they are gone. I connect the need to offer opinions on everything to that same aspiration. Like in broadcasting, as the act of spreading seeds, people feel they are disseminating themselves through life so they won’t pass.
Design systems don’t have the luxury of neutrality. I’d say a design system without an opinion is a UI framework. A clear, decisive point of view is a necessary part of a design system.
Which, paired with the previous observation makes for an extremely tenuous place to be. Design systems require strong direction, but those making working on them don’t 100% know what they’re doing. It seems paradoxical, and maybe it is a little bit. But I think that’s where humility starts to become pretty important.
Not every opinion is equal. There are informed opinions and there are out-one’s-ass opinions. There are opinions where the information used to form it are laid bare and there are the opinions followed by, “trust us”. Design systems need folks who are willing and able to make a call–while being equally open to shifting when it’s clear they’re wrong.
Sure, people who work on design systems need to be talented in the traditional sense. But I think humility plays a greater role in long-term success than anything else.
Generating your CSS variables from Figma variables ensures you’re always in sync with design. Once you have it in place, you can run it via a cron job, or as a manual script. It removes the manual, laborious process of poking around Figma’s UI and copy/pasting the variables into your CSS. Instead, run a script and let the computer do it! There’s definitely an open source opportunity here to do a lot of the “token processing” for you. But we’ll get into that another time.
I think it’s alluring to use Figma as the source of truth for visual attributes. I’m not for it. I think tokens ares too central to exist in something that isn’t 1,000,000% owned by you. That’s why I advocate for the source of truth being a file that can exist on your own hard drive.
Your file’s API doesn’t have downtime. Your file doesn’t have licenses. Your file doesn’t introduce a price increase because whatever. Your file is a file. And it’s yours. That is what should be the source of truth for your design tokens.
Before you create a design system, ask yourself: “Why?” What problem are you trying to solve? Designers wanting to build a design system because it’s trendy is not a good reason. That’s a solution in search of a problem.
Software was made for decades without design systems. I don’t think any company needs one to deliver a product. In many ways I see the rise of design systems as a direct response to growing disorganization within modern software companies. Either because of hilariously large org sizes or because ever-increasing pressures to move faster. Or both. People made software without them through good-ol-fashioned human coordination, reviews, and quality assurance.
There’s less of those now–at least in my experience. And my take is that design systems have rose in prominence as a replacement. But it’s not a replacement, because it’s a different thing. Not better, not worse, just different.
And so, no. You absolutely don’t need a design system. We got along without them for much longer than we’ve had them.
The value in writing documentation is usually derived from the process of actually writing it. More specifically, the best documentation is produced when a person has been actively questioning and thinking through the guidelines and guardrails they’re setting as they’re creating the documentation, as well as the language they’re using while doing it. A large part of this is because documentation is both contextual and opinionated.
In some regards, I kind of welcome the unrestrained adoption of AI because it gives me a strong sense of job security. I do think AI has a place, but it’s not at the driver’s seat. AI has shown tremendous ability to transcribe and summarize content. I’ve also seen it perform decently in editing writing. Each of those can save an immense amount of time for a design system team. Time, that could be used to write your own documentation.
The DIKW pyramid, also known variously as the knowledge pyramid, knowledge hierarchy, information hierarchy, DIKW hierarchy, wisdom hierarchy, data pyramid, and information pyramid, sometimes also stylized as a chain, refer to models of possible structural and functional relationships between a set of components—often four, data, information, knowledge, and wisdom—models that had antecedents prior to the 1980s.
I’ve said more than once that a design system is a point of view made actionable. I’d say another way to phrase that is wisdom made actionable. And this pyramid is a great way to visualize how to build up to developing that wisdom.
The software industry tends to stop at the information step. Just enough to made an “informed decision”. But I’d wager to say that the real, long-term value is in the formation of shared knowledge/wisdom. I’ve seen too many examples of information used to make incredibly unwise design decisions. And what better place to collect and communicate much of that wisdom than a design system?
Thanks to Bill Kurland for the reference.
This isn’t to say there isn’t room for innovation, or that staying put is a guaranteed recipe for success. What it does teach is that it pays to make informed decisions, and that often times the understood, reliable, boring tech will get you there over something new, shiny or propped up with marketing spin.
I firmly believe that design systems should be boring as hell. They should just work. And they should just work pretty much the same way, day-after-day for those using it. Similar to what this author writes about with boring tech, design systems should be predictable and come with as few surprises as possible.
Part of me thinks that’s a core reason why design systems and designers can be at odds. The “delight” in design systems is often subtle. Subtle enough to be unnoticed. And that lack of delight can be seen as a lack of design.
Foundations are chronically and perpetually undervalued. Because they’re “boring”. But boring doesn’t mean unimportant. My two cents is the degradation of software quality is directly related to the continued devaluation of foundations. Because, sadly, people are not incentivized to work on “boring” fundamentals.
Systems documentation generally has to include all the essential things; it’s our job to organize the content and make it as findable and useful as possible. We need to remind our shocked partners about this and show them how we work to make sure the documentation is findable, correct, complete, and usable. Yes, it’s information architecture, and every design system needs a healthy dose of it.
Speaking of boring… Information architecture is one of those things that doesn’t seem to get as much love as it should anymore. Design systems can really benefit from taking the time to refining its information architecture. Yes, in documentation, but I think it goes well beyond that. Figma libraries, code libraries–hell, even communications–can benefit from strong IA.
The author provides some useful resources in this post, but my take would be to take the time do develop your own. Come up with a rubric/structure that works for your team/company needs. And think beyond documentation. It’ll be worth the time.
Blogging forces clarity. It makes you structure your thoughts, sharpen your perspective. You stop writing fluff because — let’s be honest — you’re writing for yourself. And if you can’t keep yourself interested, nobody else stands a chance.
This is also why you write documentation if “nobody reads it”. Let’s pretend that no one reads documentation (which, in my years of experience is false). If the only outcome of that documentation is the team having a clearer and stronger point of view on best practices, that is a worthwhile outcome. It’s easy to think you’ve got a subject figured out. Try writing it down in a consumable format and see if you’re still confident about that.
This is also about accountability. It’s easy to waffle on a point of view if you’re not pinning your ideas down to something visible and tangible. People should not be guessing what today’s latest best practice is on button labels.
Lastly, writing it down now has the added benefit(?) of training an LLM. I think this is a net positive benefit, but…
Non-deterministic systems don’t have guaranteed outputs from their inputs. In addition, LLM-based technology hallucinates—it invents content with no self-knowledge that it is a falsehood.
This article uses some fancy words, but the gist is this–current LLMs will give different responses for the same prompt. This means the results can be unpredictable and inconsistent.
And that in a nutshell is why I haven’t been bullish on using AI with design systems. Design systems can act as a catalyst for consistency. But it can only do so it’s (you guessed it) consistent.
Now, I’m not against a design system team using AI tooling. But I think it needs a commitment that the final owner of decisions must have a pulse.
Almost any slog can be turned into a do-nothing script. A do-nothing script is a script that encodes the instructions of a slog, encapsulating each step in a function.
I really like this idea. And I don’t think they need to be literal terminal scripts–I think even a figurative stepped script to follow common tasks can be incredibly helpful. Without standards, tasks can be done a bazillion different ways which leads to unpredictable and inconsistent (or, as the fancy article above says, non-deterministic) results.
As the years go on, increasingly value predictability, consistency and reliability in a design system team’s process. The people who use your design system need to be able to trust it. Predictability, consistency and reliability go a long way to foster that trust. So, having a predictable approach to addressing common tasks/problems becomes important.
That said, this can easily become a road to death-by-process. This seems like one of those cases where aiming for just enough is pretty critical.
But there is a simpler path. You write code yourself. Sure, it’s more work up front, but once it’s written, it’s done. No new crates, no waiting for upstream authors to fix that edge case. If it’s broken for you, you fix it yourself. Code that works doesn’t necessarily need the maintenance treadmill.
I’ve come to want as few dependencies as possible. And the dependencies used need to have an easily-accessible ripcord. This is what makes me weary of relying on third-party services. Their pricing can change, their product can pivot, they can flat out go belly up. And there’s little to no recourse. Same with code packages. It’s something out of your control that can blow up.
Some things are too big to make yourself. But a lot of things aren’t. I’d rather own what runs a design system to remain in control of our own destiny. More work? Oh hell yeah. But with every year that goes by I’m more convinced it’s usually worth it.
Off-the-rack design systems are like off-the-rack suits. They are convenient, cost-effective, and designed to be good enough for most people. However, even the most flexible off-the-rack systems have inherent constraints. No amount of theming or configuring can match the complete customizability of a tailor-made system.
I don’t miss the irony here. Most system designers (myself included) would prefer the tailor-made approach as it gives them full control to make it what they think it can be–just like product designers when working on their features. I’ve done both and intimately understand the long-term risks of the off-the-rack direction. But I also understand the optics of this and how it smells of hypocracy at the surface level.
This, among many other reasons, is why I think design system usage cannot be draconically enforced.
Like features, tokens can create little piles of technical debt. “Is anyone still using –color-beefcake-primary-2?” you shout into the void of the team chat. No one responds because no one knows. The person who does know left the company five months ago. Alas, we’ll bolt on more until we find time to fix it. Always adding. Never subtracting.
Everything with restraint. Bias towards reduction. This is how design systems avoid becoming hyperobjects. If there’s one sign of a practitioner that’s been around the block, it’s the one that understands this. Flippantly adding to a design system is a recipe for pain.
Even teeny, tiny design tokens.
Side note: I’ve had to intentionally misspell the name of this site by omitting the accent over the first a. Because the fonts I made do not include that glyph. Because I didn’t think I’d need them. Because I’m a dumbass.
Diataxis identifies four distinct needs, and four corresponding forms of documentation - tutorials, how-to guides, technical reference and explanation. It places them in a systematic relationship, and proposes that documentation should itself be organised around the structures of those needs.
I don’t have an opinion on this, but I am intrigued. This seems to be a compelling resource to help shape any fledgling documentation project in search of direction.
Frameworkism insists that all problems will be solved if teams just framework hard enough. This is non-sequitur, if not entirely backwards. In practice, the only thing that makes web experiences good is caring about the user experience
To say I will be happy once I get to work on a design system devoid of React is a hilarious understatement. In the best of times I have tolerated frameworks like React as a necessary evil. Now they’re no longer necessary. You can guess what I think of them now.
I like this article because it thoroughly breaks down the absurdity of our current approach towards web development. And it reinforces my biases. But more importantly its a great critique of an idea that feedback-looped into becoming “just the way you do it”. That’s my fear about design systems as they continue to take hold. At some point, teams will cry out that it’s important to have a design system because that’s just the way you do it. And while I’m an ardent supporter of what systems bring to the table, I also think there’s a ton of downsides to be aware of. And that’s good, because it keeps us questioning and improving.
The design systems practice has fought its ass off to be given a shot. But we should always be our biggest critic and devil’s advocate. Otherwise, someone else with less interest in our success will do it for us. And they won’t be gentle.
OK, I need to preface that ShopTalk is one of my favorite podcasts–due in full part of the hosts. These peeps have put in more work to make the web better than most of us could even imagine doing–combined. So, I bring this up as a jest and because I think it slides nicely into a perpetual topic in design systems.
Around the 45m mark, Chris and Dave begin talking about wacky new CSS ideas. Chris mentioned how standards proposals can get mired in debates around how they could be used for harm. Then in the process of discussing the opinion on the problems with taking a defensive stance on tech, they proceed to inadvertently make a tremendously compelling case for taking a defensive stance on tech.
It feels so natural to err on the side of “let freedom ring”. But I think most of us assume with freedom comes accountability. Ain’t much accountability in tech right now–for many reasons. But suffice to say there’s a lot of harm being done with not a lot of consequences.
So, what in the living hell does this have to do with design systems? It comes back to the topic of how flexible or prescriptive a design system should be. A design system can be hyper flexible with strong governance, gating functions and accountability. The freedom of flexibility is balanced with accountability and oversight.
But what about the world of “move fast and break things”? What about companies that repeatedly break other teams’ features, inject tech debt, ship inaccessible experiences or just ship plain ol’ crap? What if there are no consequences for a pattern of working that way? Well, then, I say lock that baby down. I see no logical reason to give hammers to people who have a track record of breaking things. Unless you want things to be broken.
Freedom and accountability go hand in hand. The more of one requires more of the other.
You can add a CSS class to basically every HTML element. You can slap an ARIA role on anything (although be very careful about that!). You’ve got your shorthand attributes to toggle behavior on and off that work predictably. And much of these features work across all components so that if you learn how one component does something then you’ve actually learned something much bigger: you’ve learned the system itself.
A consistent API is a predictable API is a learnable API. I’d encourage anyone to assess how consistent the mechanics of a system is if it struggles with comprehension or a high learning curve. This is the kind of work that’s typically glossed over or just flat out ignored. But a system’s naming of components, properties and values are everything. They’re how people actually use your system.
Going further, I’d rather have a consistent but slightly borked API than an inconsistent but beautiful one. Mind you, there’s a lot of subjectivity in that statement, but I’m always going to lean towards consistency.
As I wrapped up yesterday, I realized this experience had become about much more than just documentation. It was about understanding our design system at a deeper level, about finding ways to make our tools work better for our team, and about growing my own problem-solving toolkit.
The process of writing documentation is as much for the people using the design system as it is for those making it. I’ll say this until I’m blue in the face. The simple act of creating documentation forces you to question what you’re documenting in the first place. That tedium has immense value. So, please think twice about if/how you begin leveraging AI for creating documentation. Sure, it can be useful, but it can also erode numerous learning opportunities.
The pianist whose fingers seem supernaturally nimble, the presenter whose message seems viscerally compelling, and the artist whose paintings seem impossibly realistic all wield the same magic: they’ve invested more time than you’d expect.
This is yet another case for dedicated and centralized design system teams. The industry is lamenting the decline of craft and quality in software. But that’s because those skills take time. And the industry has overwhelmingly displayed a disinterest in affording that time to employees. So, if companies want functional software but remain unwilling to give all their employees the time to make it, the next best thing is to give some of their employees the time.
We don’t live in an ideal world. And, in many regards, the rise of design systems are proof of that. Their fast rise is as much about their efficacy as it is a sign of the industry’s focus on quantity over quality. Ideally, everyone contributing to the development of software would have the ability to deeply focus on quality–with design systems acting as the glue and accelerant. But, again, we don’t live in an ideal world.
‘There may be just a stylistic way of writing from back then, and if it was seen as successful, people would use that style in other languages,” Gibson says. ‘I would guess that it’s an accidental property of how the laws were written the first time, but we don’t know that yet.’
Great, so the origin of legalese may be “everyone else is doing it”. Even after millennia, we’re doing the same dumb things…
This post is interesting for a couple reasons. The first is that people asked to write laws tend to fall into this “center-embedding” style of writing. This is important for design system folks to be aware of given design system documentation can loosely be considered a collection of rules–or to use another word, laws. So, if this article is accurate, we’re all predisposed to write this dumb way when we’re creating what we consider to be laws.
The second reason this post is interesting is how it calls out that no one finds this style of writing helpful. Not regular people (duh) and not lawyers. It benefits no one. This is important if only to reinforce the need to write documentation like an actual human being.
When you’re writing a tutorial, remember that you’re explaining things to a non-expert. Avoid jargon, abbreviations, or terms that would be meaningless to a newcomer.
I’d argue jargon, abbreviations and acronyms aren’t helpful for anyone, but hey, I’m happy to go with this rationale if it’ll get us to stop this habit. One thing I think most design system documentation lacks are good ol’ fashioned tutorials. There’s plenty of highfalutin guidance and principles, but not much get-your-hands-dirty, step-by-step tutorials.
I think design system documentation could greatly benefit from them. Things like “designing your first feature with the design system” or “contributing your first component”. These kinds of things have gobs of detail that I think would greatly benefit from a stepped guide.
What fascinates me about this scenario is how a seemingly functional 6-month-old project automatically turns into a haunted forest just by changing hands. Regardless of its age, SVC is textbook legacy software because, more often than not, a question posed about the system, to any team member, results in the same answer: I don’t know.
And this, my friends, is the textbook case for a dedicated design system team. And not only a dedicated team, but a highly stable and continuous roster on that team. Design system teams are an institution of institutionalized knowledge. That is why documentation is so critical–that knowledge needs to get out of brains and into a consumable medium. But everyone on the team could document every hour of every day and there would still be gaps.
A dedicated, stable team ensures that the underpinnings of the system are always known. Becuase the author is right, it takes very little to turn a functional project to turn into a haunted forest.
Figma is ‘always on’, so does this mean that we shouldn’t even try to version? Always live, all the time sounds fantastic and gone are the days of exports and imports and PNGs and PDFs and server storage, but we still have a big problem – maybe we want or need to freeze work.
I’m quite pro versioning–especially if it’s used to its fullest. Versioning keeps a canonical log for changes. It can help designers avoid updating to breaking changes. It does a lot of things that don’t seem all that useful–until it’s absolutely critical.
This post has some interesting ideas, but what irks me is that it doesn’t cover the most obvious one–have actual support for library versioning in Figma.
If there’s one thing I’ve hung my hat on in regards to design systems, it’s the need to reduce a design system’s cognitive load to encourage usage. This article does a good job outlining how this plays out in an engineering context. There’s a lot to like in the post, but this sentence stood out:
Involve junior developers in architecture reviews. They will help you to identify the mentally demanding areas.
This line jumped out at me because it’s a great tip for design systems’ approachability. Junior designers and engineers should be VIP reviewers of documentation and system libraries. Success isn’t praise from the super-senior IC who’s been at the company for a bazillion years. It’s seeing a junior designer or engineer independently get up to speed on the system and use it to create a feature.
In general, the purpose and power of an abstract idea is that it compresses a zoo of concrete examples. But if you haven’t built up that zoo of concrete examples then you miss out on that power.
People like quick wins. They like instant results. This is universal. It’s why humanity cycles through diet fads and get-rich-quick schemes.
This also plays a role in the rise of design systems. Why grind through the work of building everything from scratch when you can pull from ready-to-use components? Make no mistake, the value is deeper than that, but I’d be lying if I didn’t say it play a role. The downside of design systems is that they make fundamentals abstract. And while that equates to greater consistency and efficiency, it comes at a cost. And that cost is the erosion of fundamental skills.
But it’s not all bad. Design systems can also be the solution to this problem. There’s nothing stopping design system docs from acting as an educational resource on fundamental design and UI engineering subject matter. Yes, it’s more work, but it’s important work.