Design System Objectives & Overview

The lessons and practices outlined in this article are summaries of the problems, observations, and solutions to the challenges encountered while I was a member of the design team that introduced and launched a corporation’s first consolidated design system (DS) for its application ecosystem.

The corporation for which the DS was created is a U.S.-based hardware and software technology company. It had many years legacy “thick client” applications using design styles that ranged from engineer-driven solutions to styles based heavily on third-party frameworks for its more-recent web-based applications.

The design system was introduced to simplify and standardize the vast, wide-ranging styles and to help solve the company-wide strategic initiative of transitioning its software applications to being SaaS-based solutions. The primary focus of the DS was on web-based applications and mobile applications.

The DS was launched with about 20 components, a color system, text-style library, responsive grid system, and breakpoint standards.

The DS was a set of four libraries:

1. Sketch
2. Angular
3. React
4. HTML/CSS

The Sketch library was shared to the design team via Google Drive, since the company used Google Workspace as its productivity suite. Using G Drive allowed the team to have automated file versioning and the ability to rollback easily to previous versions, although in practice, we never used that capability.

Lessons and Practices

This list is not in a specific order. It’s just a brain dump of my recollections and by no means is a full account of everything. Some have more detail than others because I was involved directly in the work to solve the issue.

1. Primary goal was for everyone to stay current
   

   Our biggest goal was for designers and developers to always feel confident in updating their libraries and staying current. We realized that if they delayed updating because they feared massive disruption in their workflows, then we were failing to be empathetic experience designers. Additionally, by not staying current, we were failing at the larger strategic objective of making our entire application ecosystem more consistent and having a better user experience. Lack of updating inherently meant the opposite on both points.

2. Wireframe variations/states in same library
   

   At launch, the DS was intended to provide designers with an efficient means to create high-fidelity executions and did not include low fidelity “wireframe” variations/states of components. Almost immediately, the application designers asked for grayscale/black-and-white variations of the components for two reasons. First, they wanted to be able to intentionally design in lo-fi because it was faster and required less “tuning” of their exploratory design solutions. Secondly, they didn’t want their exploratory designs to be confused with final output by either stakeholders or developers/engineers. To them, “high fidelity” had always meant, “near ready or ready to code.”

   To solve this, initially, a separate wireframe Sketch library with simplified variations of the components in grayscale/black-and-white was shared, however, this separate library was soon retired in favor incorporating wireframe variations/states of components directly into the main library. When the library was a separate file, it was cumbersome for designers to convert lo-fi wireframes into their hi-fi equivalents. Once they were part of the main DS library, it allowed designs to easily swap out lo-fi components with hi-fi components.

3. No such thing as a beta component/release
   

   Any released aspect of the DS even when labeled as “beta” or even “do not use” was for all intents and purposes the same as the final release. We realized that anything released in the DS would be used despite labeling to not use or use with limits.

   After numerous attempts at including beta-labeled components, we had to face the reality that the beta label was our way to excuse our (the DS design team’s) own insecurity about an aspect of the DS that we had included in a release. We started labeling components as “beta” when we had not completed all the work to fully develop them. Candidly, we put showing progress in the DS ahead of all other concerns.

   The solution that we adopted was to continue releasing new components or aspects to the DS even if they were not fully complete (still in beta), but before doing so, they needed to pass two “tests”: 1) The update/change/addition needed to be significant, meaningful, and important contributions to the DS, and 2) We needed to be committed to improving and maintaining them “forever.” If they passed those two tests, they were released, and tagged as “first release,” but never “beta.” (I think we called them “first release.” I don’t recall the exact word we settled upon anymore.)

4. Developer resources must release with design resources
   

   The DS included developer resources in the form of compiled CSS and HTML, Angular, and React libraries. We learned the hard way to never allow the developer resources to lag behind the designer resources. All the DS libraries had to stay synchronized and released together to avoid roadblocks to implementation. It seems obvious to not allow this to happen, but it’s easy to get out of sync when different teams aren’t working together.

5. Detailed change log for each DS library
   

   Each library in the DS had its own change log published on the DS’s website and associated distribution channels. The biggest issue we encountered was that there was not enough detail being included in the change logs. Designers and developers wanted detailed descriptions of what had changed so they could assess how their applications would be affected before changes were accepted into their projects.

   This meant that we couldn’t get away with a log entry like, “Line height change for large button.” Designers and developers wanted, needed, and appreciated much more detail like, “Line height changed from 1.2rem to 1.4rem of large buttons. Overall height of either single-text-line or double-text-line large buttons is unchanged from existing height of 36px and 80px respectively.”

6. Predictable update cadence
   

   Simply, random is bad – really bad – for everyone. After our initial release, we were so gung-ho about getting the next new update out that we forgot how truly disruptive updating is to the design and development process. In the early days, the libraries were being updated multiple times a week with bug fixes, tweaks to components, or even adding new components. It was counterproductive to the goals of the DS because the teams were choosing not to update to avoid disruption.

   We learned that a predictable cadence for updates was much preferred. The acceptable cadence was a range – no less than three weeks and no longer than five weeks. This was better for the DS team too because it allowed the team to conduct more testing against sample reference project files, formulate the necessary communication, and make updates to the DS website/documentation.

7. Communication event with every update release
   

   This seems like an obvious thing to do, but sometimes when you’re too close to something, you forget that not everyone is as close to the work even though it affects them. What this meant was that once we had a created a release cadence, prior to every release, we conducted a all-hand meeting that went over all the updates, spelled out any possible problem spots, and offered fixes to problems that we just couldn’t avoid – of course, we tried very hard to not have those, but it happened sometimes. Since the goal was to reduce the risk and mitigate the impact of staying current with the DS libraries, communication was key to achieving this.

8. Apply updated library to recent reference files—verify changes
   

   Another way that we mitigated the disruptions of updating was by testing the updates against a set of project reference files. For example, in Sketch, we maintained a set of wireframes for a fictitious application that used at least one instance of every component. Additionally, we had four different design teams share project files with us. We made copies of project files from those shares. This combination of files formed our reference set of files. We would update the DS library for reference files to verify and log the impact of the updates. The goal was to always reduce the impact, see how to make any intentional impacts predictable, and/or find quick solutions to intentional impacts. Everything was logged in detail. During our release communication meetings, we illustrated the impacts.

9. Too many style options reduced consistency
   

   Another counter intuitive result that occurred after our first release of the DS, was that consistency across the various applications we served went down. Sure, all the apps began using the same fonts and colors, but we started seeing too many variations for common application elements.
   For a very simple example, some apps used H1 for page content titles, some used H2s, and some used H3s. The fonts and colors were the same, but when you lined them up next to each other, they weren’t consistent.
   What we learned is that we needed to have dedicated components for elements that needed to be consistent. That would help achieve our strategic goal.

   In the previous simple example, we created a component named “Content Title” rather than have the team rely on the typical typographic size and style hierarchy. When we saw too many variations in multiple apps in the styling for an element with similar purpose, we created a component that was labeled with an obvious usage-intent name for the element. These were always communicated in our release meetings.

10. A subset of design style and elements was created as a transitional state for apps that required significant design changes.
    

    There were several applications that required significant code base changes and process updates. These apps needed an interim solution to aligning with the DS so that they could partially achieve consistency with the company application ecosystem.

    After much debate, the solution was to implement a “DS lite” system that captured the fundamentals of the intent of the DS. The lite version focused on element and font sizing, masthead/header, and colors.