Jeff Nixon's profile

Design System Part III: Living Documentation

Aristotle
A Participatory Design System

For me, the Living Documentation to a Design System is not only a single source of truth that unifies the implementation of Design for a cohesive look-and-feel, but helps to orchestrate the workflow from design to production. It's a living document that serves as an opportunity to educate the audience on concepts that reduce technical debt and reinforce aspects of design that make the company unique. For design specifications relevant to product, there are a couple rules that came to light when learning front-end development that I feel help to improve the outcome of deliverables. They particularly touch on the topics of Typography, Spacing, Color, and Nomenclature.

I have and still do work with brand teams to determine ways to communicate the expectations of brand standards within the design system, but for the sake of this piece, I am going to focus on the product side of the design specifications.
Typography
Type Ramps are instrumental in setting the foundation to look-and-feel. There are so many dependencies that factor into type specifications, but the one message that I feel is important to incorporate into the documentation is how to redline text based on ascenders and descenders. Text boxes in HTML accommodate both ascenders and descenders, even in their absence. Meaning that the text "core" has no ascenders or descenders, but an HTML text box remains the same height as it would to accommodate text such as "dog" which has both ascenders and descenders. Now, I know this might seem petty but if spacing for a List or Button were spec'd without consideration to this concept, there could be a blocker when the component/module/feature needs to accommodate ascenders and/or descenders, but the spacing is no longer balanced. I know it might seem like a no brainer to some, but you would be surprised how this detail falls victim to debate.
Color
One of the most valuable discoveries that made Aristotle so nimble was how color mapped to the blocks of the products real-estate. We had three palettes; one palette was reserved for the global elements in the page, the second palette was applied only to the page content and the third palette reserved for data visualization.

Applying separate color palettes to specified blocks of UI allows those blocks to be them-able independent of each-other. For example, say a customer requirement was to have the ability to theme the UI. The customer could designate their primary brand colors to the global elements, without effecting the page content. There are other advantages but the theming was the biggest win for the color palette since our design system adopted a re-brand without breaking the system.
Prior to the color palette being addressed, I had done an exploration, merging color theory with logic, intended to explain color theory principals algorithmically. The goal was to map color builds to charts in a way that would avoid color conflicts and sustain harmonious combinations, no matter how many or few data sets were represented.
Spacing
In spec'ing out the design system, I wanted spacing to be structured in a way that would follow how HTML elements scale naturally, cascading from the top left corner to the bottom right. The parent elements have no outside spacing, so margin's are determined by the grid, and the spacing within the container are determined by the child element(s). Another specification was for designers to use "spacing" rather than margins or padding in order to avoid inconsistencies in development. For example, if Designer 1 spec'ed the spacing between a button and its parent container as "margins", but Designer 2 spec'ed the same spacing as "padding", the same component could be built with varying CSS rules applied.
Sticker-sheet
Since we were leveraging Material Design as our front-end framework, I picked up the sticker-sheet as a starting point and applied the styles (fonts and colors) to the typography styles and color palette in Adobe Illustrator. As the requirements changed, the components were updated and new components were added. The sticker-sheet was hosted in Creative Cloud with each component as a symbol within the CC Library and distributed globally from within the living document. 
Living Document
For Aristotle, I used WordPress as a light-weight CMS solution in order to quickly get the documentation up and design spec's communicated to the global Design and Development Community. As the spec's were established, I was able to quickly publish the content and keep the community up-to-date with the latest-and-greatest. The Living Documentation not only had short blurbs of supporting content that were to the point, but also linked to design resources such as templates, Creative Cloud assets, Craft Libraries, and code snippets.
Scalability
A good design system is not just scalable, but flexible. Its more hypothetical, than prescriptive, in order to accommodate growth, both vertically and horizontally. If its prescriptive, it stands less chance to accommodate the inevitable change all companies go through. For example, we went from a gold and blue primary palette to red and black, without breaking system since our color palette was hypothetical. We had data to gauge what it was, to what it became, and adjust the design strategy accordingly.
Design System Part III: Living Documentation
Published:

Design System Part III: Living Documentation

Published: