Creating Stable Design Systems at Scale

Cause and Effect: A Toolkit for Applying Systems Thinking to Design Sprints

System Dynamics in Design Systems


In 2006, some students at Xavier High School in New York were given a writing assignment: write their favorite author in an attempt to get him or her to visit the school. Five of those students chose to write Kurt Vonnegut.

Vonnegut did not end up visitng the school, but he did write a letter in response. That now famous response was brief and wonderful and its premise both simple and profound: practice any art in order to better yourself.

I opine that Vonnegut's words extend beyond the scope of his letter, past "any art" as he suggests to the students, but instead into _any act_. Practice science, or philosophy, or running, or law. Practice being alone, being with others, loving yourself, loving someone else. As Vonnegut describes it — become. _Become_.

The letter, in its entirety, is here.

> November 5, 2006
>
> Dear Xavier High School, and Ms. Lockwood, and Messrs Perin, McFeely, Batten, Maurer and Congiusta:
>
> I thank you for your friendly letters. You sure know how to cheer up a really old geezer (84) in his sunset years. I don't make public appearances any more because I now resemble nothing so much as an iguana.
>
> What I had to say to you, moreover, would not take long, to wit: Practice any art, music, singing, dancing, acting, drawing, painting, sculpting, poetry, fiction, essays, reportage, no matter how well or badly, not to get money and fame, but to experience becoming, to find out what's inside you, to make your soul grow.
>
> Seriously! I mean starting right now, do art and do it for the rest of your lives. Draw a funny or nice picture of Ms. Lockwood, and give it to her. Dance home after school, and sing in the shower and on and on. Make a face in your mashed potatoes. Pretend you're Count Dracula.
>
> Here's an assignment for tonight, and I hope Ms. Lockwood will flunk you if you don't do it: Write a six line poem, about anything, but rhymed. No fair tennis without a net. Make it as good as you possibly can. But don't tell anybody what you're doing. Don't show it or recite it to anybody, not even your girlfriend or parents or whatever, or Ms. Lockwood. OK?
>
> Tear it up into teeny-weeny pieces, and discard them into widely separated trash recepticals. You will find that you have already been gloriously rewarded for your poem. You have experienced becoming, learned a lot more about what's inside you, and you have made your soul grow.
>
> God bless you all!
>
> Kurt Vonnegut


On The Experience of Becoming: Kurt Vonnegut's Famous Letter to Five High School Students


Sometimes it can be hard to know what to work on in a design system. There are so many things which command our attention. There's always a very delicate balancing act between wanting to use the design system as a way to advance systems-level thinking inside the organization while at the same time utilizing the system as a way to embrace what there already is, and set up a set of guidelines to help others understand the decisions that have been made thus far.

This gets trickier in very large design systems or in cases where the design system has been neglected or absent up until this point. Both the amount of time saved by advancing foundational parts of the design system and the debt accrued by failing to document new things as they come into existence can be a zero sum game.

One way I've taken to dealing with this is to think about any aspect of building a design system in terms of **variance, mass, and size.**

Variance tends to be the enemy of design systems. Variance might be defined as the point at which a portion of the design system takes on new form to meet a new goal. Variance may also be at a low or high _intensity_. A high intensity variance would be one in which two states of an object in the design system exist to meet the **a wildly different** goal. A variance of normal intensity would be one in which two objects or states exist for **similar, more closely related, but not congruent** purposes. A low intensity variance would be one that simply needs to specify state or interaction related to **the same goals**.

When cataloging a design system, the intensity of variance tends to come into play not so much in the objects themselves as in the combinatorial sets of these objects. Objects which are comprised of many other objects, or objects with a high intensity of variance, can be said to be of great **size**. The parts of the design system with the smallest size consider the _least relationships and goals possible_.

An object in a design system has **mass** if producing a chance in that object _affects other objects_ in the system. An object can be incredibly complex (i.e. it can be said to be of great size) but be fairly isolated in its application. It would be isolated to a specific surface or seldom used situation, and thus, would have a small mass. Conversely, an object could exist at a relatively low state of complexity but have a cascading effect that has implications on many, _many other parts of the design system_, thus giving it **large mass**

Design systems can do a lot to keep the overall complexity of the system down by considering the parts before the whole. By prioritizing the parts of the design system which have the smallest size, but the greatest mass, it's easier to start building a design system that pays dividends. Likewise, when new objects come into existence, the question about whether or not to let new circumstances impact the momentum of the design system should also be a matter of the mass and size of that change relative to the current state of the overall system.

This is by no means a perfect way to build a design system. I recognize that the massive complexity of building at scale and parallel to ongoing product development efforts can strongly impact one's ability to always rationalize system adaptation against the notions of mass and size. At the end of the day, design systems are built for people, and we should be doing whatever we can to make their lives better, in both the short term and the long, and not let any guiding notions like these become dogmatic treatises any more than should the idea that these systems are winding and complex and cannot be neatly put into boxes mock the attempt.


Size and Mass in Design Systems


Design systems have done much in terms of advocating for and advancing collective thought towards the notion of component-based design and development strategy. By documenting patterns and discussing the application and extension of those patterns, the design system has established a kind of **figure-ground** relationship between the things that are and are not a part of that system. What is, is recorded, and what is recorded describes what their is.

But a design system is not a library of sketch symbols neatly arranged on an infinite canvas, nor is it a folder of components, or set of pre-made templates. It’s not the dos or the don’ts. And while design systems that are generated from code tend to be easier to maintain and describe a more **accurate** representation of what can actually be put into production for other people to use, than those drawn by hand in vector, assuming that a generated design system would be an ultimate source of truth will result in a design system with an equally narrow field of view as its inverse. The component itself, drawn or coded, has very few inherit _principles_, beyond its affordances, which describe what is known about it. For us to truly _know_ any object, we need to know about every occurrence of that object. To do this would mean to edge slowly closer towards a system as lumbering as the application to which it represents.

> A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. **– Alfred Korzybski, Science and Sanity (1933, p. 58)**

We would do well to keep Korzybski in mind when referencing what a design system is and how accurately a design system should seek to represent its application blow-by-blow.

Nothing can be devoid of place and time. For a thing to exist, it must exist at a particular point and place in time. Design systems describe not objects, but _possible_ objects, stripped down and generalized, and do not necessarily reference the relation of an object to its environment. These generalized concepts are things that cannot be fully described until the moment in which they exist again. Only though the application of a pattern in a particular situation can we truly say whether or not that pattern is a well-executed application of a system. The application of most parts of a design system are esoteric, and can only be described though metaphor.

Design system are not rigid rules to be followed. They’re more like sketches, gesture drawings that suggest a shape, a texture, a quality. They are the _map_. They help guide us towards the right reality, but they are not in and of themselves _the_ reality. So it seems that the best way to describe a design system is spend an equal amount of time not just documenting any given object, but documenting the _application_ of that object in time and space and in concert with all the objects it interacts with. But this is still not the territory. If we go through the process of naming and describing and cataloging a portion of the interface with the intent that the end result is a perfect depiction of the territory of that which it represents, we cannot ever reach objective truth. Any description of any interface would be done with a specifically chosen taxonomy to describe and account for that interface, and the very act of choosing _what_ to say is also a choice of what _not_ to say. We can then look at that map and ask ourselves “what does this map represent?” and thus, we only make another map. Again and again, on and on.

Design systems should aim to tell **stories**, organized through **patterns**, which set up scenarios and suggested outcomes. Throughout the description of these patterns, the design system will reference other patterns. Some of these patterns may be more or less gestural than others. When a design that utilizes that design system is being iterated upon, the system should serve as a guide towards more consistent outcomes. When the design is finalized, if a real pattern or object cannot be well-described through a design system, then either the object or the system should be modified to be rationalized through the order of the system, carefully minding that the design system not grow to such immense precision that it reaches an unusable size. I believe this is how design systems can be malleable to new ideas without becoming a tome of prescriptive specificity that everyone dreads.


The Map Is Not The Territory


Coming up with a consistant set of colors for us in UI design is no easy task. Many times, when style guides are created, a few key hues are picked out and documented. This doesn't take into account he myriad tints and shades that may be needed when used in practical applications.

One approach to this is to use something like SCSS' `rgba()` function to build new a new color to build a new color.

```css
.alert {
  background-color: rgba($red, 0.1);
  border-color: $red;
}
```

This gets us pretty far without much effort - but visually, the effects can sometimes be less than desirable. Certain hues behave different under different levels of luminosity. As Henry Munsell in his 1905 book _A Color Notation_ noted, reds, blues, and purples have a much longer chroma axis than some yellows. Likewise, some hues may need to be adjusted as saturation increases to keep them optically consistent.

I found myself wanting the flexibility to pull or push hues around quickly, and I wanted the results to be something that could be quickly translated to code so that the single source of truth could live with the developers, rather than a sketch file designers would have to export and transmit back and forth.

I tried some existing tools created by [Brent Jackson](http://www.jxnblk.com/), namely [Palx](https://palx.jxnblk.com/), which served as a huge inspiration for this project. However, it didn't have the flexibility to adjust hue or saturation. I built Palettes using the same tool as Palx, [Chroma JS](http://gka.github.io/chroma.js/), but retooling it to have increased flexibility. This little library works wonders.

## Palettes

Here's a peek at Palettes:

```javascript
const stepsToFloat = (options) =>
  Array.from({ length: options.luminance }, (n, i) => (i + 0.5) / 10)
    .reverse()
    .map((s) => modulate(s, [0, 1], [options.start, options.end]));
```

This is the first piece. It will return the number of tints of a given base color to me, specified later in `config.js`

I then needed to be able to adjust colors with a few parameters.

```javascript
const shiftColor = (color, s, index, shift) =>
  chroma(s)
    .set(
      "hsl.h",
      chroma(color).get("hsl.h") - index * (index * 2) * (shift * 0.01)
    )
    .hex();
```

```javascript
const shiftSat = (color, s, index, sat) =>
  chroma(s)
    .saturate(sat * 0.1 * Math.log(index + 1))
    .hex();
```

Figuring out the math here was a bit of trial and error. By picking colors manually and plotting them on a curve, I found I was consistanty adjusting saturation on a roughly logarithmic curve. Hue shifts were adjusted on a quadradic curve. This takes a starting color, a step in the scale, an index, and a level of saturation or hue shift. Positive numbers shift hue right on the standard `CIECAM02` model. Negative numbers shift the hue left.

Then I needed to adjust each color based on it's starting point, changing hue and saturation as those parameters existed:

```javascript
const buildColor = (key, sat, shift) => {
  const color = hueSet[key];

  const steps = stepsToFloat(lumSet)
    .map((s) => chroma(color.hue).luminance(s).hex())
    .map((s, index) => (sat ? shiftSat(color.hue, s, index, sat) : s))
    .map((s, index) => (shift ? shiftColor(color.hue, s, index, shift) : s));

  // return values as incremented key value pair
  const values = expandColors(key, steps);

  colors[key] = values;
};
```

I can loop over this for each step hue I specify:

```javascript
const buildPalette = (set) => {
  Object.keys(set).forEach((key) => {
    buildColor(key, set[key].sat, set[key].shift);
  });
  return colors;
};
```

## Configuration

The `config.js` has two objects defined in it:

```javascript
const lumSet = {
  luminance: 10,
  start: 0.05,
  end: 0.95,
};

const hueSet = {
  blue: {
    hue: "54A2F0",
    sat: "3",
    shift: null,
  },
  yellow: {
    hue: "FFCC00",
    sat: "3",
    shift: "12",
  },
};
```

`start` and `end` are used to keep values from going to dark or too light. This way, individual values remain distinct.

When I run the script through node with `$ npm run build` it will output a `.json` blob that can be read in to a webapp's config file.

```javascript
{
    "blue": {
        "blue0": "#ecf5fd",
        "blue1": "#d4ecff",
        "blue2": "#bce1ff",
        "blue3": "#a1d5ff",
        "blue4": "#84c9ff",
        "blue5": "#62baff",
        "blue6": "#2fa8ff",
        "blue7": "#0094ed",
        "blue8": "#007bc9",
        "blue9": "#005b98"
    },
     "yellow": {
        "yellow0": "#fff4ca",
        "yellow1": "#ffe788",
        "yellow2": "#ffd43a",
        "yellow3": "#ffc300",
        "yellow4": "#eeaf00",
        "yellow5": "#dc9a00",
        "yellow6": "#c78300",
        "yellow7": "#af6a00",
        "yellow8": "#924f00",
        "yellow9": "#6b3300"
    },
}
```

You can grab the tool for yourself [here](https://github.com/seanblanton/palettes)

## Next Steps

This project is by no means done yet. I'd love to expand more on this, building it into a webapp to visualize colors on the fly.


Programmatic Color Palettes


The web is an accessibility nightmare. For many companies, A11Y guidelines are relegated to some "other" time or a "nice to have". But even when a website meets accessibility standards reasonably well, one of the components in design that seems to be left behind is the disabled state. And it's a somewhat reasonable thing to leave behind. After all, this is a _disabled_ state. It's not intended to be interacted with, so it's reasonable to assume that because of this, accessibility can fall by the wayside.

But disabled buttons are buttons, too. And disabled text that is still visible on the screen exists to inform a user about the current state of the system. Often, disabled text is there to nudge a user towards another action that could perhaps _enable_ the same text at some point in that context. Or it might exist to inform a user of options that may be unclear to him or her.

A great example of this is in faceted search. I'm on Amazon right now, and it's late in the evening. On the left hand side are my search options. Halfway down the page is a `Refine By` subheader and the very first filter option is for `Delivery Day`. No doubt this is because it is in Amazon's best interest to inform a user that `Get It Today` _is_ a delivery option, and a damn good one, at that. But it's almost 10:00PM at night, and so the only option I have available to me as a user right now is `Get It Tomorrow`. Maybe I should hop online earlier in the day to take advantage of Amazon's great shipping options next time. But if I couldn't see both the disabled gray label and the disabled gray checkbox, the the shipping options aren't nearly as sweet.

Surprisingly, there isn't much talk out there about the `right` shade of gray for disabled. But here's what I do know: **WCAG doesn't set contrast requirements for disabled text**

> **Incidental** – Text or images of text that are part of an inactive user interface component,
> that are pure decoration, that are not visible to anyone,
> or that are part of a picture that contains significant other visual content, have no contrast requirement.
> – [_From WCAG 2.0_](http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html)

Default, unstyled HTML button labels set to `disabled` are `#7F7F7F`. This is a `4:1` contrast ratio on a white background, just slightly off from minimum. This comes close to meeting the standard for low vision and moderately low visual acuity that tends to come with age. This is around 20/40 vision and tends to represent the acuity of a user around age 80 years old. This would be fine if the text was over 18pt or was 14 point bold.

Default, unstyled radio buttons set to `disabled` have borders of `#D8D8D8`. This is a 1.43:1 ratio, which is pretty terrible.

Disabled, checked checkboxes have the checkmark at `#A1A1A1`. This is a `2.58:1` ratio. Still bad, but getting better.

Pretty dismal as far as options go. Just because WCAG AA doesn't specify a minimum, doesn't mean we can't adopt some sensible best practices for disabled text:

### Best Practices

- Leave disabled form elements at their default styles, even though they don't meet WCAG A.
- But set the disabled label color to no darker than `#7F7F7F` to ensure that while the button isn't visible, the identifying label is still readable for most. This will serve as a clue for most users.
- Disable any visual styling on hover or click for disabled buttons or text to prevent confusion
- Consider some hint text, either in a tooltip or copy next to the disabled action instructing the user on why the action is disabled.
- Keep the contrast on regular, active items high so that the difference between active items and disabled items is still distinguishable at a glance.


Which Shade of Gray Should I Use For Disabled States


When choosing fonts for web typography, it's easy for a designer to impulsively reach for Open Sans or Lato or Avenir or whatever the newest, hottest thing out there at the time is. I've done it. We all have. There's a compulsion for the fonts we use on the web to match the fonts we use in marketing material, particuarily print. After all - we do want to be _on brand_, right? But is that the most important thing typography should address?

But if you start to consider your performance budget, using webfonts starts to make less and less sense. [Users hate slow websites](http://globenewswire.com/news-release/2010/09/07/429014/200875/en/New-Survey-From-Compuware-Gomez-Reveals-Consumers-Will-Quickly-Abandon-Slow-Websites.html)

#### We need to consider what typography is _for_ and what problem it aims to _solve_.

Let's pay attention to the words we don't often even bother to look up in the dictionary. Take user _interfaces_ for example:

> #### in·ter·face
>
> ˈin(t)ərˌfās - **noun**  
> &#8291;1. a point where two systems, subjects, organizations, etc., meet and interact.  
> &#8291; 2. a device or program enabling a user to communicate with a computer.  
> &#8291; – [_From Google_](https://www.google.com/search?q=interface+definition&oq=interface+definition)

### When I design something, I aim to make every single design decision solve a problem.

Sometimes that problem is for the user, like increasing legibility or reducing cognitive load. Sometimes the problem is for the business, like increasing maintainability and scalability. So maybe that means adding constraints to the design requirements and increasing the efficiency of the system.

## If typography in an interface exists to facilitate interaction, putting a webfont in a button or other parts of UI copy does little to advance this cause.

But what it does do is this: make your page heavier and harder to maintain. Good web typography should be functional and performant. Everything beyond that is nice to have and should be considered an optimization on an already validated design.

## Using system fonts allows designers to focus more on solving problems and less on aesthetics.

They also allow your site to feel native to the platform in which a user is experiencing it.
[W3C is already considering this as a standard anyway](https://lists.w3.org/Archives/Public/www-style/2015Jul/0169.html)

If you must include webfonts as a part of your UI, at least consider the [alternatives](http://cognition.happycog.com/article/7-alternatives-to-popular-web-typefaces-for-better-performance) that might help reduce your page to help reduce weight and load them [in the most efficient way you can.](https://github.com/bramstein/fontfaceobserver)

## Further Reading

- [Bram Stein on loading fonts](http://bramstein.com/writing/)
- [Marcin Wichary on Using System UI Fonts in Web Design](https://www.smashingmagazine.com/2015/11/using-system-ui-fonts-practical-guide/)
- [Sites with System Fonts](https://github.com/mrmrs/awesome-system-fonts)
- [Katie Kovalcin on Designing wtih a Performance Budget](http://cognition.happycog.com/article/designing-with-a-performance-budget)


Why Use System Fonts


Reading fiction, and even more so, writing fiction, has been one of the greatest things I’ve done to better understand how to design for others. In the design community we talk a lot about the importance of writing. In general, it's a great thing. There's a wealth of great resources on the recommended reading for designers, and there's plenty of designers putting out great content on a regular basis, too, but much of it tends to be on usability, psychology, user research, testing, should designers code, design leadership, and other kinds of technical writing. But it's not enough.

The act of reading and writing fiction requires the author to imagine a reality that is not and never will be her own. It means imagining and coming to an understanding that the people in these stories have lives and experiences equally as complex as hers, and that whoever conceived of these stories has (or had) a life and motivations that are wholly different from her own life and experiences. And when we write fiction, we're asked to create realities that are not prototypical, but specific, and then to understand the implications of those realities for the people that inhabit that imagined space. How do two people with differing value sets perceive the world differently, and how do they interact together?

All fiction is a design problem, that is to say that fiction seeks to organize the world for a specific purpose. And while the world in which novelists organize and create meaning and just happens to be imagined, that imagined world is valid, and real, and informed and strengthened by the reality that surrounds it.

The act of fiction goes far beyond something like writing personas. While personas tend to be constructed to be a single, concrete figure, that persona is intended to stand as proxy for an entire user group. This is the difference between _persona_ and _character_. Persona is often too reductive to ever be more than a ghost of a person inside of a work of fiction. It's through a combination of persona, user journey, and storyboarding that we as designers only begin to scratch the surface of what it means to be the personas we imagine, validate, and ultimately design for. What the very best fiction does so well is examines character through the lenses of change and time. It finds nuanced differences in character's moods, behaviors, belief systems, needs, goals, etc between what was and what is. And the very best writers consider you, the reader, too. Your thoughts and your emotion and the experience of you as person sitting and reading the scene and comparing it in your mind to your entire worldview.

The more we read stories and the more we try to write our own, the better a language we have to understand the people whom we design for, and the better context we have to understand ourselves.

Some of the most important things I may need to convey in a design can only be really talked about anecdotally, through some metaphor, image, or story. It’s through story that my thoughts are condensed and transfigured. These stories become easier to understand or draw correlations between because we’re all so used to them. Every single one of us tells stories. Anthropologists have identified that storytelling exists in every country and every culture in the world, and stories have existed in some form or another, oral, written, or visual, for thousands of years. Our entire civilization has been built on our ability to communicate with and understand one another effectively.

When I tell you a story, it's because I need to tell you something about the way I think or the way that I feel. I tell stories when something is funny, or interesting, or profound, or beautiful, or inspiring. When we tell stories we assume our telling will communicate something to the recipient about who we are and what we think and value.

> "Is this what I think? And is this all I have to say? And am I making myself understood?"

And herein lays the key problem: the words I write can only sketch the outline of what it is I mean to say. But then I present these words as a tangible artifact of who I am and what I think.

As a designer, my understanding of the person whom I design for can only ever be a sketch of who I think they might be, not who they are. It helps to practice healthy skepticism:

> “Health Approach presupposes that truth is objective at least in the minimal sense that believing something does not make it so, that something‘s being true does not mean we believe it, and that we are capable of making mistakes.”
>
> – (pg. 90) LE MORVAN, Pierre. "Healthy Skepticism and Practical Wisdom"

It behooves me to be as skilled as I can be at creating such a weak representation of real life, and to be always conscious of the fact that no matter how true I believe the facts to be, it’s always possible that I may be wrong every time. And that — that is incredibly humbling.


Fiction Writing For Designers


Today I'm releasing my very first open source project. Albeit tiny, I wanted to share it with the world. I hacked on this over a weekend while trying to refactor my site to make the css a little leaner.

For a while now I've been using [Susy Grids](http://susy.oddbird.net) to prototype both personal and professional work. Susy grids are great for designing responsive layouts quickly in the browser. I often find that I have a hard time conceptulizing how content will react to breakpoints. I can make static mockups at several sizes, but my intuition is often wrong. Susy grids help fix the problem by allowing me to experiment early.

But Susy and I weren't getting along with how I wanted to write CSS when it came to dealing with media queries and breakpoints. I was stuck constructing grid component media queries with OOCSS, which wasn't jiving with my interests in utility classes (inspired by [BassCSS](http://www.basscss.com) and [Tachyons](http://www.tachyons.io) )

I wrote Susy Bricks as a module to extend Susy's mixins into atomic classes at multiple breakpoints using the prefixes `.xs`, `.sm`, `.md`, and `.lg` to quickly adjust layouts without even having to touch css. Here's an example below.

```html
<div class="box xs-span12 md-span6 lg-span3" />
```

To give credit where credit is due, I did look to Buzzfeed's [Solid](https://solid.buzzfeed.com) to help me get the prefixing mixin off the ground.

I've been tryin to find better ways to organize my CSS, and this is a step in the right direction. I hope to continue to work on this in the future. Right now, this module only works with the most vanilla version of Susy (which is all I've really used Susy for), but I'd love for it to be more robust in the future.

Check it out over on [Github](https://github.com/seanblanton/susybricks) if you'd like to play around with it


Sean Blanton — Product Designer & Writer

Writing

Creating Stable Design Systems at Scale

Cause and Effect: A Toolkit for Applying Systems Thinking to Design Sprints

System Dynamics in Design Systems

On The Experience of Becoming: Kurt Vonnegut's Famous Letter to Five High School Students

Size and Mass in Design Systems

The Map Is Not The Territory

Programmatic Color Palettes

Which Shade of Gray Should I Use For Disabled States

Why Use System Fonts

Fiction Writing For Designers

Making Susy Grids Atomic

About

Bookshelf

Thinking in Systems

Everything I Never Told You

The Moment of Lift: How Empowering Women Changes the World

The Most Fun We Ever Had

Good Strategy Bad Strategy: The Difference and Why It Matters