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 upsteam 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.