Aristotle
Data-driven design system
The Aristotle project documents a design system created in 2017. The 3-part series explains the major steps taken towards completing the project and the rationale associated with each step.
Part 1
Distributed Design Strategy discusses the scope and how it was defined through Experience Workshops.
Part 2
End-to-End Brand Experience focused on bringing the Product Design Strategy together with a post-merger/acquisition rebranding, for an end-to-end brand experience.
Part 3 (you are here)
Living Documentation discussed through examples, the process of defining patterns, creation of the sticker sheet, Adobe Creative Cloud design assets, the Craft Library, and publishing the specifications to a WordPress site as a guide for both designers and developers.
Living documentation
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 design aspects that make the company unique. For design specifications relevant to the product, there are a couple of rules that came to light when learning front-end development that I feel help improve 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 brand standards within the design system. For this portfolio 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. 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 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 product's real-estate blocks. We had three palettes; one palette was reserved for the page's global elements, the second palette applied to the page content, and the third palette was reserved for data visualization.
Applying separate color palettes to specified UI blocks 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 affecting the page content. There are other advantages, but the theming was the biggest win for the color palette since our design system adopted a rebrand without breaking the system.
Before addressing the color palette, I explored merging color theory with logic to explain color theory principals algorithmically. The goal was to map color builds to charts to avoid color conflicts and sustain harmonious combinations, no matter how many or few data sets are represented.
Spacing
In documenting the design system, I wanted spacing to be structured to follow how HTML elements scale naturally, cascading from the top left corner to the bottom right. The parent elements have no outside spacing, so margins are determined by the grid, and the spacing within the container is determined by the child element(s). Another specification was for designers to use "spacing" rather than margins or padding to avoid development inconsistencies. For example, if Designer 1 documents the spacing between a button and its parent container as "margins," but Designer 2 documents the same spacing as "padding," each component would hold 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. I applied the styles (fonts and colors) to the typography styles and color palette in Adobe Illustrator. As requirements changed, I would update each component and add them to the sticker-sheets. 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.
Scalability
A good design system is not just scalable but flexible. It's more hypothetical than prescriptive to accommodate growth, both vertically and horizontally. If it's 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 the 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.
Living documentation
For Aristotle, I used WordPress as a light-weight CMS solution to quickly get the documentation up and design documentation communicated to the global design and development community. As documentation becames established, I quickly published the content and kept the community up-to-date with the latest-and-greatest. The living documentation had short blurbs of supporting content that was to the point and linked to design resources such as templates, Creative Cloud assets, Craft Libraries, and code snippets.
