Airkit is a low-code app making platform. Airkit’s super power enables users to easily connect multiple APIs to create headless apps or build front-end user experiences in its WYSIWYG Studio. As you can imagine, this is a very complicated application with many user interactions from end-user interface building tools to database management and chat script path authoring.
Airkit app interface
The Airkit Design System was built from the ground up starting as a single page in the first product design Figma file, to a single page Figma Library file, then to multiple pages, and finally multiple Figma Library files. The design system is broken up into a number of core Figma Libraries:
Tokens - the basic building blocks such as color, fonts, typography, styles, and layout grids
Components - ****interactive and informational core elements
Patterns - common collections of components such as toolbars, footers, and navigation
Icons - basic graphic elements or glyphs
Art - more complicated illustrations and animations for micro interactions
All our design system library files link to the #design channel in Slack as well as our Storybook on Github. Each library page focuses on a single element and consists of documentation / best practices, examples, and reusable Figma components as well as a link to the corresponding Storybook page when applicable.
Badge component page in Figma
Badge component page in Storybook
When joining Airtkit, the design system had no real owner and there were many disconnects between what was live production and what was in design. Typically designers would add new components to a design with little oversight or input from other designers and engineers. Engineers would either pushback at the point of handoff or implement the new designs into the system. There was very little documentation or communication when new elements were created and implemented.
Upgraded Info Banner Components using variants, booleans, embedded instance swaps
Although the Airkit Design System wasn’t the only problem to solve when joining Airkit, there were definitely some glaring problems that I felt could drastically improve team productivity and design consistency. As I got familiar with the team and the design system I started to plan some basic changes that helped quality of life for engineers and designers.
One of the easiest things to change was our design system update process. We needed more accountability as well as utilize Figma’s powerful features to gain oversight and version control.
The first change I made was to establish an owner for the design system. To lessen the burden and spread knowledge of the system we opted to change the owner quarterly. At the end of each quarter a new designer would become the Airkit Design System owner, with the previous designer connecting the new designer with the lead frontend engineer. This owner would act as liaison to engineering and together would approve changes.
I also implemented Figma’s branching feature. Once a part of the design system was branched, changes could be made without disrupting other designers and allowed the design system owner and engineering to approve those changes before merging the branch and sending to production. Branching also made it easy to document changes and roll back to previous versions if necessary.