Building a Ubiquitous Design Language with Components

UI developers and visual designers, despite working very closely, often speak very different languages without realising it. Most discussions use terms that simply do not align across domains. Whether it is CSS’s misuse of terms like line-height and baseline or HTML5’s semantics not aligning, these deviations result in confusion and less maintainable code.

The world of components give us the opportunity to create abstractions that directly model the designer team’s intent. The drive to establish a ubiquitous design language has improved the quality of conversation and the consistency of the dev team’s output — innovating on solutions to things like vertical rhythm on the web. If you care about building large scale well-designed apps quickly while still focusing on maintainability, accessibility and composition, this one is for you.

Wireframes only share the outcome of a design process; and they ask a developer to reverse engineer the idea from a few pictures. They need to work out the purpose and semantics, make it accessible and responsive. It tends to result in inconsistency.

 

Focus on building a common language, the markup that will be used at build time. Largely this is expressed by abstracting the markup away and building components. Even then we tend to focus on widgets like buttons and inputs and not so much on principles.

 

So Michael’s team are trying to capture the designers’ intent and not just the outcomes.

 

Remove the pixel translation layer – get to the bottom of “what’s not right?”. Most of the build-time discussions were about spacing. So they set typography first.

 

What does a 21px heading on 27px line height really mean? It’s part of a type hierarchy scaling on a base value. It’s not 21px, its 2.1 x base size of 10px. The line height was not 27px, it was 3 x 9px row height.

 

This is based on extracting the design principles and not just the design outcomes. This means the code can be following the right paths. They can extend the language without talking about pixels – px only exist in the compiled output.

 

Then you realise “CSS does not speak design”. Line-height means something entirely different in CSS than it does in Typographic Layout. True typography measures line height from the baseline, so the height isn’t right – leading to build-time “nudging”.

 

You can pull this information into SCSS variables: capture the descender height and nudge the text down to where the designers expected it to be. In EM units, Roboto has a descender height of 0.15em.

 

open source library to do this: Basekick

 

Now the conversation is happening in design principles, rather than pixels. Component interface becomes your design language. It’s the way to form understanding between teams.

 

This applies to colour as well – what is the intent of some green text? It was being used to reinforce positivity. “Positive” beats “green” as a design language.

 

Controlling the snowflakes: people always think they have a special case. To begin, Seek are driving consistency by default, and pushing variation into design discussions that can be mainstreamed.

 

What’s worked? Components everywhere – small, composable components. Cross-discipline pairing.

 

What’s hard? Naming things is hard. Justifying the ‘why’ is even harder.

 

seek-oss.github.io/seek-style-guide if you are interested to see their work in action.