Skip to content

Instantly share code, notes, and snippets.

Last active October 11, 2016 12:38
What would you like to do?

UI Kits and Open Design.

The last few years has seen the wonderful proliferation of UI kits for the web. These libraries offer non-designers a way to create designed interfaces without needing to involve a dedicated designer. They function much like the libraries that save every developer the time of mastering the diverse range of technologies (file IO, networking, application structure, etc) that go into making a technology product.

Like open source software, these projects also have the goal of open sharing so anyone can take the project and augment it, use it without charge, change and redistribute it, or commit changes back for everyone to share.

A UI kit means a trained professional has done the complicated and time consuming task of crafting a reusable set of elements that can be combined in many ways and still retain the cohesion and unity that come from good design. Some kits also ship with HTML and CSS, saving you the time of taking a design and converting it from pixels to the powerful but quirky DSL we have for web interfaces.

On the surface this looks like an equivalent to open source software: "open design" if you will. But these projects aren't as open as I suspect the authors intend. That's a bold statement, so bear with me: releasing images and/or HTML and CSS, even accompanied by permissive licenses governing their free use, doesn't constitute "open". They're certainly free-as-in-beer, but I'd argue they fall short of the loftier free-as-in-speach.

The problem with PSDs, dribble shots, even HTML and CSS is that no matter how much freedom we have for use, none of these things are the design. They are artifacts of the design. They're an encoding, visually and in a DSL (HTML/CSS), of the design but they are not, themselves, the design.

The actual design – the information I wish the authors of these frameworks opened – is the decision making process behind the values they've selected for sizes, proportions, colors, line, textures, and all the other primitives that make a design.

Let's use Topcoat as an example. Here's a button from their kit:

I can know from the CSS that the button's color is a light gray (#e5e9e8), the text inside is 1.167em in size, that it has 1.16em of padding accomplished with padding for the right and left and with line-height for the top and bottom. It has 1px border of solid #a5a8a8 with a 3px radius. The text is Source Sans with a weight of 200 in dark but not pure black (#454545) with a slight #fff shadow.

Even if Topcoat was like other UI kits and only made images available, I could use tools like xScope and ColorSchemer Studio to derive the values. Having the CSS is awesome because it saves this step and encapsulates best practice solutions for getting these values into a format parseable by a browser. Still, those specific values are the "what" of the design but they aren't the most important part, the part that makes a design truly open and reusable: the "why".

Why a 3px radius and instead of 5px or 1px? How does 3px relate to the size of the button as a whole or the size and weight of the text? Why is the button #e5e9e8 and the border #a5a8a8? How were these colors selected?

Expanding outwards from the button we can continue our line of questioning. How do the values that create space between the button and other elements near it relate to each other? How were colors in Topcoat selected and how do they relate to each other? The colored buttons have various blues to indicate state. How were these blues picked from all the possible combinations of hue, saturation, and brightness? How do the blues and grays and near blacks compare to each other?

The answers to those questions (and more) is the actual "source" of design. If you think the "why" isn't the single most important aspect of a design, open one of these UI kits (or even a favorite web app!) in a browser's inspector tool and start changing values. You won't need to change many values and you won't need need to change them by much before the design will look "off" or "broken" to you. Change them back with a reload and the design will appear to snap into place, rich with its original cohesion.

Go, give it a try. Isn't it amazing? What's more amazing is that you'll see it even if you aren't a designer[1]. You live in a designed world. You've been trained by constant exposure to see design. And, while you probably haven't been trained to make new designs from scratch you're perfectly capable of distinguishing between good and poor design. If you don't believe me, go play with the games at

Every design is like a little language with its own correct grammar and syntax nearly as specific as a programming language. It contains primitives but instead of concepts like maps, arrays, integers, and functions the primitives include size, weight, color, proportion, and texture.

Without first understanding that language it's impossible to correctly express anything new. And that's where the problems start for most people using these libraries. If they stay safely within the provided components they can make an application that looks designed (because it is) but no UI kit provides every possible component or even has guidance about all the ways existing components can be combined.

Inevitably these kits will fail to help. You'll need something new – it might be as large as a new component or as small as a new highlight color – and it will look wrong somehow. This is the #1 complaint you'll here from developers trying their hand at design. Not that they don't know what makes good design, but that when they try it comes out all wrong.

It's tempting to think the HTML and CSS are design source and that reading through it will explain everything you need. Let's examine this idea a bit by returning to the button example from above and adding another button into the mix:

Large button

Small button

Let's say our applications needs three hierarchies of button to properly draw attention. The large button for actions on data they are currently interaction with, the small button for actions elsewhere, and small_er_ buttons for global but infrequently used actions.

How much vertical space should the smaller button should use?

Implicit in the design artifacts that FlatUI, Bootstrap, Foundation, and Topcoat expose is the actual design. A skilled designer can extract it in the same way that a skilled programmer can look at an application and reverse engineer with surprising accuracy.

Once a designer has uncovered the underlying primitives, it's trivial to create new elements that fit into the overall design.

Most programmers lack this skill. So do many novice designers. For an expert designer, and especially for the ones who make UI kits, the design is so obvious from the artifact that they can't understand why we throw up hands up and say "These are beautiful examples, but how do I actually make a damn thing."

The good news is programmers are highly trained at working within a set of constraints and rules. You just need to tell them what those rules are and how to use them. A design isn't random. A design is the accumulation of intentional choices about size, proportions, colors, textures, line, etc. Values are selected for specific reasons and the relationships between these values is what becomes the language of the design.

For all the popular UI kits someone knows the reasons behind the values, but that knowledge isn't open. With enough skill you can derive a good guess at the answers, but that's no more open than any exercise in reverse engineering.

I'm extremely grateful for work people put into making these frameworks. I just wish they'd share the right parts.


  1. I've tried this exercise with some design friends, too. They're often able to notice the breaking when a single value is changed by a small amount. It's impressive.

Some resources that informed my thinking

Copy link

Thanks for writing this up @trek. Really appreciate the insight as that I work on @adobe.

You make a two points to which I will address:

  1. UI Kits aren't open if they don't include their motives
  2. UI kits aren't open if they don't include their design research

(As that you used Topcoat as your example I'm going to address these points from the perspective of our project.)

Topcoat Motives

Topcoat exists to solve two primary issues in CSS libraries today.

  • performance
  • maintenance

Our mantra is Performance First which is more of a guiding principle than an output itself. It colors all of our work. We have a unique CSS benchmarking server which is a top level concern on our homepage and in our development workflow. We separated the Topcoat controls into discreet repos so we could independently revision them and thusly independently benchmark. We compose optimized builds of of only the controls you need. We separated our CSS reset, from its layout, from the aesthetic so each of these deceptively complex facets could be discreetly measured for performance. A guiding principle like Performance First sets the tone and scope for all our actions in the project. The practice of having a guiding principle is something I often recommend to all open source projects to adopt.

Maintenance is less subtle. The discreet repos, and the benchmarking, contribute to good maintenance. We utilized the BEM architecture [1] to ensure our CSS outputs where sane, consistent, easy to understand, and update. In the process of generating optimized builds we also create a living usage guides [2] which means developers using Topcoat don't have to hunt around the CSS, weird online docs, or other markup to know how to use Topcoat. We only generate CSS and do not have any funky JS DOM library dependencies so we can work with any projects that do such as Ember (or Angular, or Backbone, or VanillaJS). Finally, we centralized most theming information into an independent repo called, you guessed it, which you can fork/modify and generate builds to your hearts content. The workflows are very low level developer centric but that is only because we're putting the foundation in place for future higher level tooling.

Topcoat Research

At Adobe we take design very seriously! The process of design. The tools we use to design. The artifacts of the design process. The art, the beauty, and the people. It is tricky to accredit any one person in a moderately sized open source software project like Topcoat but if it had two dads they'd be @g1sh and @kristoferjoseph. @g1sh lead the creation of the visual design and related experience of Topcoat while @kristoferjoseph leads the implementation of the architecture and related experience. It is important to mention them because they'll find this interesting and most certainly will have comments too! =)

You almost used the term Design Language which is what we called Topcoat before we created the tooling, and CSS artifacts. In an effort lead by @g1sh whom conducted extensive design research into web apps, their user interfaces, and how people interacted with them. You can see most of that in a presentation [3] he and @kristoferjoseph gave at CSSConf which should have videos online soon.

Additionally Topcoat includes SVG icons and our open source font Source Sans which where both created in Adobe's legendary XD department and always under active development. This is a key counter to your hypothesis that design research should be included at the beginning. Design today is iterative and is conducted throughout the software lifetime. If we find a user struggling with a character or glyph in our font you can bet we are going to update it! Likewise as the mediums of the web change to new screens and devices we too have to adapt Topcoat to suite. I'm honestly unsure how this could manifest in our work to be fully transparent more than the usual channels of issue trackers, mailing lists, twitter, etc but I assure you I am now thinking about this. =)

Outcome of this Dialogue

Now, I felt that our motives for Topcoat where made clear on our homepage but given this article I don't know that they were! We also just simply did not give any focus to our research in the home page. I filed an issue to address both of these concerns and make this more explicit. [4] The project is very new so we're learning our audience and their concerns as we go. Topcoat's design is responsive to that. (Bad pun. /me groans)

Open Source FTW

Thanks again for the post @trek. (It is far easier to have a discussion here than twitter!) I like to say to folks that contributing to open source is much more than just code and I think this conversation is a good example of just that. If we can ever get the chance to talk more f2f the first beer is on me. =)


[3] topcoat/topcoat#328

Copy link

trek commented Jul 28, 2013

UI Kits aren't open if they don't include their motives

Knowing the motivation behind the designs is awesome, but not what makes a UI kit open for easy extension. To be open, I need to know the grammar behind the language.

Let's use a concrete example:

Here are 3 color swatches:

The motivation behind them is to provide a series of blues that are similar but distinguishable enough to highlight differences in a subtle way for elements like links. Knowing the design goal doesn't help you select a 4th color that fits into the set.

If told you how I selected those colors, however

Each blue is the same hue (206) and blackness (87). The lightest blue has a saturation of 30 and steps up in increments of 20.

Knowing that, you can select a fourth value if you need one:

More importantly I've only provided a family of blues but you can use that rule to select other hues that fit into the same design:

Copy link

Themes are in Topcoat but you are encouraged to use our tools to create your own.

Copy link

trek commented Jul 28, 2013

Maybe color was a poor choice. Surely something like sizes are more integral to the design. Why is button-large line-height: 2.6rem and regular buttons are 2.0rem. Someone selected those values purposefully. They're related to each other and to the other sizes in the design. How do they relate to each other?

Copy link

Wow! Great post and also great answer. Thank's.

Copy link

@trek this is an amazing write-up. Such a great point and I really hope the conversation continues and that Ui kit developers get it and start sharing their knowledge in greater detail.

Copy link

This is a great conversation.

I think maybe a good illustration point would be this example from Twitter's bootstrap docs:

Body copy
Bootstrap's global default font-size is 14px, with a line-height of 1.428. This is applied to the and all paragraphs. In addition,

(paragraphs) receive a bottom margin of half their computed line-height (10px by default).

Why 14px with a line height of 19.992px? Is there a 20px baseline grid this is aligning to? If so, why was that grid chosen? I am very guilty of it, but as designers sometimes we rely too much on "it feels right" or "it just looks right."

* Edit*
Note: the docs say 1.428 but the actual css contains 1.428571429, which is far closer to 20px. Even a ~ before the value in the docs would have been clearer.

Copy link

jimsynz commented Jul 29, 2013

Thanks for bringing this up @trek. I have felt this pain very personally. A story:

When @fourseven and I started porting Yahoo's Pure into SASS we made quick progress at first; scraping the Moustache templates from the theme generator and run them through FlavourSaver and translate the expressions into SCSS variable statements.
The second stage was to try and convert their rules for generating their whole theme from a couple of base colours, however the task of reverse engineering Yahoo's extremely convoluted JavaScript colour space code in the end was more work than we were willing to invest.

Pity. It would have been awesome to be able to understand at a glance what the relationships and rules between the design decisions were.

Copy link

spion commented Jul 29, 2013

I've found that The Non-Designers Design Book (non-affiliate link) filled a small part of the hole you describe (at least for me)

The book explains the principles of contrast, alignment, repetition and proximity then demonstrates how to apply those principles by example.

Each example starts with a "designless" item that doesn't follow one or more principles.

One or more principles are applied (if more, in successive steps) to multiple aspects of the design. The reasoning behind the application is explained.

The final result is a designed version of the item that doesn't look "off" anymore.

I think that the explanation method used in this book can be used as a good starting point for a design that strives to attain the openness you described here.

3-page example from the book

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment