ARISTOTLE
A Data-Driven Design System – Part 2
Aristotle is the Living Documentation of a Design System I created in 2017 which I broke up into a three part series. Part 1 explains the project, what Data-Driven Design is and how scope was defined through Experience Workshops. Part 2 focuses on how I brought the Product Design Strategy together with Brand, for an the End-to-End Brand Experience. Part 3 will focus on the Living Documentation, the process of defining Patterns, creation of the sticker sheet, Adobe Creative Cloud design assets, Craft Library, and publishing the specification of the Design System to a WordPress site for Designer and Developer consumption. Please note that fuzzy little spots in the images presented in this Behance project are not an accurate representation of the design deliverables and are in fact, the removal of the branding until I have time to drop in placeholders. Thank you for your understanding.
End-to-end Brand Experience
The best thing to happen to our design system was accommodating the customer requirement to rebrand the UI. This is what made us more nimble than a leprechaun navigating the landscape of Silicon Valley in a 70D Tesla Model S. Overs night we were able to go from a UI with texture, and interesting angles, to a plain-vanilla flat design. We had already plotted color based on common chunks of a web-based UI. We tracked Angular 2 MD (now MDC) and MDL style classes to every design decision we made, being sure not to break the model. This gave us full functionality of the framework while rationalizing design specs that mapped directly to the Material Design palette requirements. Here’s what happened.
No more than two weeks after the design direction was established the company acquired another, and the two companies were merged. New brand guidelines were in full affect and a new set of stakeholders had eyes on the new product initiative. Dang.
A good design system is not just scalable, but flexible. It rationalizes every aspect if needed, not when needed. Its more hypothetical, than prescriptive, in order to accommodate change. If its prescriptive, it stands less chance to accommodate the inevitable change ALL companies go through, and with-stands the test of time. We went from a Gold and Blue primary palette to Red and Black over-night, without blinking.
There is a lot of underlying details, and back-stories that go into the rationale behind Aristotle being the name of my Design System. I wont bore you with too many details but the bases of the name was to support my message to the design comity, that a more holistic approach was more conducive for a successful workflow, based on our timeline and the fact we were trying to catch up to the development cycle.
Brand Impact
Given that this was a product in its conceptual phase, each department researching the best product to go to market with, all I had to work with were some half baked wireframes and some high level feature aspirations,. What I did, rather than skinning some perpetual pages of the prototype was take some basic pages that would go into a product like this (List View, Dashboard, and Card View) and apply the styles (color, typography, etc) from he moldboards, alongside a mock style-guide.
The Cooper approach is to apply styles to a Common Component sticker sheet, but a feel it still leaves things to abstraction, and simply isn’t as tangible as a UI re-skin. Based on the UI re-skin, the audience was fully on board with the Trend-setter direction, which allowed me to work independently, factoring all their feedback into my design decisions, and focus on developing a style guide and pattern library.
Going from a granular "atomic" design spec, such as Spacing and type size, through each component, module, and page layout, without any context of how those granular decisions effect each page, within a given flow, simply presented a slew of problems, forcing us to go through the exercise again. I know this to be best practice for Atomic Design, going up and down the Atomic model, iterating on the fly, but when you are trying to operate in a cross-functional, multi-talented design team, globally, in various time-zones, within a convoluted corporate structure, it simply doesn't work. Nice idea but...you get my point. Atomic Design is a precursor to the development cycle, since it requires being tested and iterated upon, over and over and over again. When there is a centralized design team, meaning in the same room at the same time, with ample time to massage the details into a fool-proof design system, prior to development, bingo, Atomic Design is great!!!! Rationalizing everything, meticulously. Every tiny detail. When you are behind the dev cycle, and the product scope has not been determined (scope change, scope creep, etc.) and the design team is different time zones (allowing only a couple hours a day to meet, discuss and delegate, with no context (the various instances each component is implemented), it doesn’t work. In order for Atomic Design to work, you need context. There needs to be page layouts for key flows, breakpoints, and contextual decision making.
Bear with me here, as this may seem contradictory to what the industry seems to have adopted as "best practice", but the name Aristotle flies in the face of the Atomic Design approach. Not because it's a bad idea, but it was simply not working provided any number of indeterminate factors but provided the team dynamic, and project scope, its simply wasn't working. A wholistic approach would have been more suitable for a number of reasons.
