I am going to talk out my ass about design systems for a few minutes, so I want to make sure I get this preamble in:

Of course you need to have procedures, which means you need to have governance, which means you need to have people, which means you need to have money, which means you need to have executive buy-in. None of this is peculiar to design systems, old-school style manuals, or really any long-term initiative within an organization. As such I am going to take this state of affairs as given, essential as it is, and concentrate on the actual class of artifact itself.

So What Is a Style Manual?

In a keynote address , software design and management sage Fred Brooks had this to say about style:

If one had asked what is it that characterizes style? how is it that when we hear a piece by Mozart, or by Handel, or by Bach, in a few bars we can tell who it's by. …It turns out that style is a collection of detailed micro-decisions, and it characteristic of most people that they tend to make the same micro-decisions the same way. …Now that means that if you're designing a new product, and you want it to have conceptual integrity, one of the things you want to develop as the product goes along, is a style sheet, that documents the micro-decisions, so that everybody on the team makes them the same way.

I'm going to define a style manual as a declarative set of prescriptions and proscriptions pertaining to design decisions that have already been made the hard way, so we don't have to relitigate them. Since a huge amount of the effort in design goes toward generating the differentiating information we need in order to decide conclusively over otherwise ambivalent criteria, a style manual not only considerably abridges this process, but adherence to it also contributes toward a consistency of presentation, desirable when many people are nominally working in concert but generally do not spend much time communicating with each other directly.

So What About a Design System?

I'm going to define a design system, perhaps naïvely, as a style manual with digital characteristics. Whereas an ordinary style manual is intended to be consumed and executed directly by humans, a design system is at liberty to be extended by machine-readable content, up to and including executable code. Confer Brooks, what he said immediately after the passage cited above:

And one of the ways of accomplishing that is of course standard libraries of common parts, and that means the micro-decisions are already made, and the mere re-use of those parts accomplishes the uniformity.

We know a lot about this in the software industry: reusable parts are called libraries, modules, APIs, frameworks, components, etc. There are a zillion ways to encapsulate and deliver these things, but the one that sticks out the most is the Web, which you would be bonkers not to use. We can thus refine our definition: Design System is Style Manual with Web Characteristics.

So Why Wasn't I Consulted?

Whereas a conventional printed style guide has the force of edict, creating an analogous artifact on the Web is going to import all of its idiosyncrasies: In a medium where everybody can effectively get a say, everybody expects one. It no longer suffices to simply tell people to do it this way or else—decisions need a rationale in order to be taken seriously. This is the part that I find interesting.

A style manual, again, is fundamentally a set of prescriptions and proscriptions. It says do this, don't do that—it doesn't say why, because it doesn't have to. But even if it had to, retracing the rationale behind each decision would have been prohibitively expensive, to record, organize, and display. A style manual fits in a binder, but the research materials, the prototypes, and the attendant deliberation for what goes in the binder, transcribed to paper, would barely fit in an entire room.

A good example of the Web-as-a-medium in action is in the bug report threads of any remotely significant piece of software. In a presentation that recently came across my desk, maintainers of the programming language Rust recount when members of their community revolted over the changing of a single, albeit fairly important word. The presentation goes on to elucidate how the Rust maintainers worked a request-for-comments process into their process at large, to give the community the sense that—and in a very real way—that they weren't the victims of the opaque and mercurial decisions of a small group of bureaucrats.

In my opinion, what makes a designer competent is precisely their ability to credibly justify their conclusions. If you can't do this as a designer—no matter how successful your results are—then neither I nor anybody else can tell if you aren't just picking things at random.

What I am proposing, then, is no less than to make a designer's entire line of reasoning a matter of permanent record. On the surface is the familiar set of prescriptions, components, examples and tutorials, like you would expect out of any such artifact. Attached to every element, though, is a little button that says You click it, and it tells you. The proximate explanation will probably not be very satisfying, so you click on the next until you get to the end, at which point you are either satisfied with the explanation, or you aren't.

Why would anybody want to do such a crazy thing? Well, for one, you're already kinda doing it. The Web can store a nigh-infinite quantity of content. If anybody wants to nail you badly enough over a flimsy design decision, they can plod through GitHub, or Jira, or Slack, or the company mail archives or whatever. Bad-faith actors have a remarkable amount of stamina for that kind of thing. The point of meticulously collecting design rationale information is not far off though: if the ultimate stated reason for a certain thing to be a certain way isn't good enough, you can change the thing, because you aren't working in a freakin' cargo cult.

Yes, yes, I know this would be a herculean technical undertaking, irreducibly laborious, and probably completely out of the question for anybody considering this kind of endeavour, even if they could be convinced that it was in their interest to pursue. That said, I wouldn't be talking about it if I didn't have some idea of how you could pull it off. Oh well, start small, I guess.