Development
Why Design System?
A new design system was initially a part of a high-level initiative in the design department called “Getting our House in Order.” Issuu’s former design department had disbanded, and there was little documentation about the existing implementations and neglected product areas. Furthermore, Issuu had transitioned from Sketch to Figma and also lost documentation on many of the implemented components and layouts. This resulted in a high level of design debt.
It was also observed that a lot of teams at Issuu had siloed themselves, which resulted in multiple teams exhausting resources to build the same components.
This was addressed by creating libraries principles and guidelines and collaborative protocols in order to streamline effectively. These elements are what comprise Issuu's design System.
Intial Input
My work on our design system first began while working as an intern, which evolved into a full time position. I was an individual contributor. At the time, Issuu was also being sued for violating U.S web accessibility standards. For one year, I audited existing components to create and document components that comply with these standards. Some of these violations were that components did not have focus states, images did not have alt-text, and contrast between text color and background did not meet web-accessible standards.
Audit
Before
After
From this audit, I created the visual guidelines for the Design System. The visual guidelines were the very first guidelines to Issuu’s design system and set a standard for how things should be documented and the initial requirements for component proposals.
Visual Guidelines
How large certain fonts and line height should be on certain devices. Color contrast for text - ensuring that the color of the text had the appropriate amount of contrast to its background color to ensure. Epilepsy: How animations, such as loading states should be built in order to adhere to those at risk of seizures.
As our design system library grew, so too did our design team. With different engineering teams working in Denmark, Germany, and Portugal on different projects, it became important to integrate designers in a way where they could communicate just as fluidly with each other as they could with their cross functional teams.
The importance of a design system struggled to be prioritized throughout the organization. I speculate it had to do with the culture of the company at that time. The ominous disappearance of the former design department naturally resulted in an absence of understanding of design. The company was very developer-centric.
The design was seen only as an aesthetic, an afterthought after something was to be implemented. Prototyping and validating assumptions were rare and sometimes completely absent in processes. Furthermore, products and features were developed and implemented without the knowledge of Product Managers and Designers driven by a poor understanding of Agile practices.
Observing these discrepancies, I spearheaded an initiative called “Design System Architecture.” This involved a series of workshops and presentations that I facilitated to understand what was needed to develop an industry-standard design system from a design perspective.
I analyzed various mainstream design systems and created a checklist for achieving an industry-standard system. I broke things down and delegated tasks to people throughout the design department. Through my analysis, I broke down the foundation of a design system into 3 primary areas: Principles and Guidelines, Components, and Aesthetics & Styling. These areas were turned into epics for design leadership and delegated into tasks to further evolve the system.
