I’ve been inside the @salesforceux Lightning Design System for several months now. Been thinking a lot about what design systems are for, in general, and what they’re trying to do.
A design system, functionally, is a set of prebuilt UI elements written in HTML & CSS. Think bootstrap, but minus the javascript, and more tailored to a particular company’s brand and UI standards.
Developing a style guide as you build a site is not a new idea. A design system is the BigCo version of that. Design systems tend to be more organized, complete and, uh...systematic.
Done well, a design system can free your UI developers from worrying about difficult but important things like accessibility and browser compatibility.
Done well, a design system can also give you the latitude to easily make UI updates, even across a large site where different parts of the page are owned by different teams.
BTW if you’re even a little bit interested in design systems, go follow @jina. She has done some incredibly important work in the space AND runs a design systems conference.
I’ll wait. 😊
I’ll wait. 😊
Ok, so that’s what a design system is functionally. I’m really much more interested in what it is philosophically.
A design system is essentially a type system for HTML & CSS.
And what is a type system?
Well, Wikipedia will certainly give you the super computer-sciencey and tbh not very useful definition: en.m.wikipedia.org/wiki/Type_syst…
Well, Wikipedia will certainly give you the super computer-sciencey and tbh not very useful definition: en.m.wikipedia.org/wiki/Type_syst…
In particular, a design system tries to bring elements of _static_ typing to two languages that don’t have it: HTML & CSS.
If you’re thinking “Why on earth would I want that?” ... you might work mostly in small teams. :)
Static types in general (not just design systems) are for large teams. They slow you down too much when you’re little, without accruing any of the benefits.
Static types in general (not just design systems) are for large teams. They slow you down too much when you’re little, without accruing any of the benefits.
In a programming language, static typing serves two purposes, in order of importance:
1. It is a communication mechanism for very large groups of developers.
2. It is a tool that enables refactoring across a very large codebase.
1. It is a communication mechanism for very large groups of developers.
2. It is a tool that enables refactoring across a very large codebase.
Let’s talk about each in more detail.
1. Static Types as Communication
People on small teams can just go ask other people what they’re expecting to be passed into their API, and what the caller will get back.
Those conversations don’t scale as your team grows. Types _automate_ a lot of that communication.
People on small teams can just go ask other people what they’re expecting to be passed into their API, and what the caller will get back.
Those conversations don’t scale as your team grows. Types _automate_ a lot of that communication.
Tests are another way to automate that communication, but testing is hard to explain and hard to absorb and most people don’t really get it. Types are easier.
2. Static Types as Refactoring Tool
Static types make it WAY easier for code editors to help you with refactoring tasks like renaming methods, changing signatures, etc. In a very large codebase where you only really get to know a tiny piece of it...that assistance is important.
Static types make it WAY easier for code editors to help you with refactoring tasks like renaming methods, changing signatures, etc. In a very large codebase where you only really get to know a tiny piece of it...that assistance is important.
Again, tests are another way to achieve this. Instead of types, you could have a regression suite to give you confidence that your change didn’t break anything in the 98% of the code you never see.
But in a very large codebase, a regression suite will take a looong time to run.
But in a very large codebase, a regression suite will take a looong time to run.
And given that testing is hard to teach and hard to grok and most people don’t really get it, at scale a regression suite doesn’t give you the confidence you want anyway.
Because someone always asks: I am NOT saying that static types obviate the need for tests.
But _for large groups_, static types automate a certain kind of confidence more reliably than the equivalent tests would.
But _for large groups_, static types automate a certain kind of confidence more reliably than the equivalent tests would.
Ok so what does this have to do with design systems?
Well, even a very large team building a web application with a statically-typed backend must at some point output code in non-statically typed languages like HTML, CSS, and Javascript, for the browser to consume.
Well, even a very large team building a web application with a statically-typed backend must at some point output code in non-statically typed languages like HTML, CSS, and Javascript, for the browser to consume.
A design system is an attempt to let developers operate at a higher level, thinking in terms of composed sets of elements with a name (“search box,” “card,” “tab set,” “multi-select list,” etc.).
Those are our types.
Those are our types.
These “design types” serve both as communication (answering questions like “how do I make a tab set that looks & works like all the others”) and as refactoring tools (because to “refactor” the design, you can just change the CSS and it’ll update everybody).
In the real world, it’s not as clean as that (on either side) for a variety of reasons - mostly having to do with the difficulty of effective “typechecking.”
But more on that tomorrow - it’s 1am, and I just had to get this first part out of my brain. Now I can sleep 😴😴😴
