Profile picture
Sarah Mei @sarahmei
, 24 tweets, 4 min read Read on Twitter
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. 😊
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:…
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.
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.
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.
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.
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.
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.
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.
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.
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 😴😴😴
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Sarah Mei
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!