Design Systems — v.kough

CoreStore Platform

When I joined the team the tech stack was more than 10 years old with many inconsistent elements from page to page. My task was to create universal design standards. The system I created was called “Legoland” because of it’s reusable parts. The software had two versions of the interface: an internal one for admins which was blue and an external one for agents that was green. I opted to start with the internal one first to get buy in and so it wouldn’t affect sales as we worked out the kinks. The first iteration was called “Legoland Blue.”

Legoland Blue

My approach started with an accounting of all of the existing elements variations in the admin area. The spreadsheet was quite large and the audit took a few weeks to get to 80% coverage. At this point, despite the recommendations to get a full accounting before starting I opted to move forward. My concern was that the project would loose management support if it took too long to show results.

I analyzed the information I had and talked to the engineers about what they wanted. From here I realized that they wanted a full custom system that could be used with the multiple languages on the stack including Ruby, Rails, Mithril, React, JQuery and several bootstrap type frameworks.

From here I came up with color, button and selector strategies and began to write the CSS/SCSS samples for the engineers. Normally I wouldn’t write the CSS myself but our resources were very short at that time and I could easily do it. I created a CodePen for this testing so the engineers could view the code and provide feedback.

The Framework

Since they wanted more than just buttons and elements specified in the library, I wrote and created a system using a specific naming convention and vars for colors and spacing. The colors were set up as primary, secondary and the alert colors. This would help scale to include the front end Legoland Green version, help with any custom branding for the Enterprise level stores and make future updates easier. I also set up vars for space increments in the grid.

I worked with one of the Ruby engineers to make sure that these would work for all of the older pages and we discovered that we needed more increments for the oddities of the older code so those were added. After which we released for wide usage on the admin area and scheduled in page by page conversions.

I did all of the documentation in Confluence and created several Cheatsheets for the onboarding to system and for the occasional contractors to use. When it was handed over to the engineers it was a success. It was easy to understand and helped speed up build times and made onboarding easier.

Challenges and Outcomes

In the end, we only used the defined Atoms (colors, spaces, buttons, selectors, etc) and Molecules (combinations of Atoms like an input plus a button) for the older pages of the interface since that light touch for updating would cause the least amount of down time for those pages.

For the new products that were added to the admin area, we added React based page templates to the library. These additions really speed up development time and get the engineers excited to use the framework.

We did such a thorough job with Legoland Blue that wen it came time for Legoland Green we only had to make small updates to the sizing and color vars. All of the other combinations and naming worked great in that area of the codebase.

Example of code provided in the CodePen

Confluence documentation for typography

Documentation for colors

Example of a Cheatsheet

DoubleGDP Platform

For this engineering team, they were already using Material UI for their front end when I joined but they were using it in a non-uniform way with lots of one-off customizations and the pages lacked cohesion. After talking to the team and discovering that they already had Storybook installed, I opted to use Figma for the UI design because of their integration with Storybook.

Figma with Storybook

After reviewing the entire app to see how exactly the elements were being used form page to page, I decided that the fastest and easiest way to create cohesion was create a solid color strategy, use only standard Material UI components as much as possible for at least the next 6 months and to make all of the inputs the style.

The Framework

We purchased a Material UI kit for Figma which made things much faster and I began to create the strategy for the colors. The challenge with this was that the software was white labeled for the different cities and the colors used in the UI were 100% controlled by the city admins so the usage had to account for every color combo possible.

In order to minimize the possibility for color clashing and readability issues, I restricted the color usage to a primary and secondary color. Usually the logo colors were used for this. The primary color was solely used for clickable objects like buttons, links menus, etc. This was purposefully done to help train the user to our system so they would see the color and know it was clickable. There were text labels and tool tips for the color blind users. The secondary color was used for decoration like borders, rollovers, etc.

Additionally I worked with the 4 alert colors (success/green, error/red, info/blue, and caution/yellow) and created a muted pallet that would work with most color combinations. These colors were hard coded and not controlled by the admins so they had to work with most color combinations.

Challenges and Outcomes

I created Figma pages for the elements for Storybook and documented the philosophy and usage in the company‘s Gitlab handbook. The initial testing with Storybook went well but after several updates it became problematic and was a time hindrance. Eventually Storybook was abandoned.

The system I put in place did ultimately serve the team even though Storybook did not. We ended up using the documentation I set up in Gitlab with direct links to the Figma pages. We ended up expanding the components to include pages right before the company closed. These pages really went a long way to creating uniformity in the app and sped up the page builds.

Example of Figma page for Storybook — Typography

Example of Figma page for Storybook — Page as React Component

GitLab Documentation

Learnings

Buy-In is Critical

I knew going into these projects that the upper management would need to be on board with the allocation of the resources and understand how long the process can take. But I learned that the engineers need to want it and participate in the format so the adoption will be high. It was only after I got the engineers’s buy-in did either project really gain momentum and ultimately prove it self by making it easier and faster for them.

Functional not Formal

I’m a big fan of “meet people where they are at.” The Atomic methodology made a lot of sense in the class room but when the resources were few and time is applying pressure, I ended up taking a step back from the formality of the system I was taught and literally met the engineers where they were at to create materials that worked for them. This informality worked for these teams.

I do believe that the essence of the Atomic methodology worked for both systems in that these systems documented the small elements, the most likely combinations and made it faster for the engineers create pages and complete tickets. If I were tasked with creating another system I would spend more time upfront talking to the engineers about what they really wanted and how they would use it.