Flats or Spikes Design System
I love working on design systems and I've been working on them for a long time.
When I worked at John Deere I defined many of the mobile guidelines and helped create templates and sticker sheets (some of these were built in Illustrator before migrating to Sketch). When I joined Agrible the biggest challenge I undertook was working closely to rebuild the entire platform using an all new design system. While at Nutrien Ag Solutions I was an active contributor to our design system and presented in organization-wide meetings to advocate for engineering resources to bring our design system to life.
When I worked at John Deere I defined many of the mobile guidelines and helped create templates and sticker sheets (some of these were built in Illustrator before migrating to Sketch). When I joined Agrible the biggest challenge I undertook was working closely to rebuild the entire platform using an all new design system. While at Nutrien Ag Solutions I was an active contributor to our design system and presented in organization-wide meetings to advocate for engineering resources to bring our design system to life.
Suffice it to say, I am a huge fan of design systems! They help teams bring new features to market faster and they foster collaboration between engineering and design. It's been amazing to see the tooling for design systems improve over the years. Personally, I find the act of working in Figma to build system like building with LEGO. It's just plain-old fun! Wild, I know.
Background
When I joined Flats or Spikes as the lead designer, I spent time talking to product, engineering, and quality assurance to get a sense of how reusable the code and designs were. Long story short, it wasn't great. They had a number of bad experiences with designers and the team felt like the app was really visually inconsistent. Worse yet, almost nothing was set up as a reusable component in our ReactNative codebase. It was like every screen was hand-built. Not great.
Luckily this was all before we launched a version 1.0 to the public, and we had a little time to refactor and set us up for success moving forward.
Luckily this was all before we launched a version 1.0 to the public, and we had a little time to refactor and set us up for success moving forward.
Investigate
Digging into the Figma files, I found a single "features" file and a separate "library" file. This seemed promising! At a bare minimum, I recommend teams separate their design system from the active feature files. That simple division means you clearly know what is "universal" and you have to knowingly edit it in a separate file to make changes. Some people may grimace at the idea of a single file to contain the entire app with dozens of pages to split up the parts of the app … but really that's mostly personal preference! The most essential part is separating the library from your features. So far so good!
But when I started looking into the design system I found… oh no.
But when I started looking into the design system I found… oh no.
In this example, you can see that tab bar is not a component. The "active" and "inactive" tabs are also not components.
There were elements labeled as "components" but they were not actually created as Figma components.
This meant previous designers were likely copy and pasting from this file, but it was just a standard frame so nothing was reusable. For example, the app heavily used table rows and there were thousands of them throughout the feature file; but they were all completely unlinked frames, instead of instances of a component.
Additionally, while there were a couple text styles and colors, it was not a 1-1 with what was visible in the guidelines.
This was a mess.
This meant previous designers were likely copy and pasting from this file, but it was just a standard frame so nothing was reusable. For example, the app heavily used table rows and there were thousands of them throughout the feature file; but they were all completely unlinked frames, instead of instances of a component.
Additionally, while there were a couple text styles and colors, it was not a 1-1 with what was visible in the guidelines.
This was a mess.
Where to start?
The first part of the process was reviewing all the "final" designs by reviewing the feature file and comparing it to the staging build of the app. I pulled out all the one-off designs, elements that repeated (ex. buttons) and brought them into a single spot, and "generalized" them by keeping things generic, adding auto layout and mapping to text and color styles.
This was also a great time to ensure the smallest aspects of the system were in good shape, so I focused on the atomic level of text, colors, icons, and simple controls.
Collaboration
It's also worth noting that while I created the Flats or Spikes design library, I couldn't do it alone. Building the design system means having your designs be represented in code and to bring this system to life I collaborated closely with engineering.
Throughout this process, I worked with a newly hired engineer had a good background in building components. We collaborated on correlating the components in our code repository to Figma. At this point we had a handful of common components and they started to refactor parts of the app to use the new components.
Throughout this process, I worked with a newly hired engineer had a good background in building components. We collaborated on correlating the components in our code repository to Figma. At this point we had a handful of common components and they started to refactor parts of the app to use the new components.
Refactoring
I started making new Figma files for each major part of the app then refactoring all the "final" designs using the new components. Separating the features into multiple files made it much easier for product and engineering to find designs and reduced load times, so we kept going down that path.
One aspect I was particularly proud of was the kiosk components. These are for single-step forms, like a wizard-like setup experience where you only ask for one thing at a time. These screens always have a navigation bar with a back button, a progress bar showing how far into the flow you were, a big title, sometimes a description, an input field, and a button to continue. I wanted to build a system for building these flows in seconds while keeping spacing and other considerations consistent across hundreds of screens. I created a "template" component which was preset to use a text field. That text field could then be overridden to a number of controls, all without "detaching" the instance.
Another component to call out was the navigation bar. While technically you could put any icon into navigation bar, we wanted to constrain ourselves to help make the experience predictable as users navigated the app. Limiting ourselves also meant that it was super easy to get the correct variant of the nav bar: just change the right icon to Plus and away you go!
Aside from a basic button, our table row components were the most heavily-used component throughout the app. They provided a spot to house all kinds of data, like the time or location of a cross-country meet. They also had a set of controls for advanced custom elements like building workouts where you needed to be able to remove or reorder within a table group. Suffice it to say, having a consistent set of table components in Figma and code was paramount to building our app quickly and in a consistent way.
Working with engineering we decided to build lots of table components with a handful of properties each, rather than a single ultra table component with 20+ properties. This kept each component simpler, easier to maintain, and eliminated unnecessary variants.
Working with engineering we decided to build lots of table components with a handful of properties each, rather than a single ultra table component with 20+ properties. This kept each component simpler, easier to maintain, and eliminated unnecessary variants.
Results
Over the course of a sprint or two we had rebuilt most of the frontend using the new design system. While it wasn't a drastically different aesthetic, the app was now much more consistent and reusable. It also allowed us to build layouts for new screens (in both Figma and React) much faster. If we made an improvement to a control, such as improving its VoiceOver support, all instances across the app would gain that benefit.
A design system is never done, but having these core elements made repeatable and reusable made our team more efficient and saved the company a ton of time and money especially with a small development team.
The last thing to mention: as the sole designer at Flats or Spikes I did my best under the circumstances to keep the system organized and well-kept, but it was not always my number one priority! I was the only direct "user" of the Figma library, so I spent my time making sure it was easy to use (ex. adding synonyms to component descriptions to improve search) and less time on rationalizing every design decision or providing detailed layout specifications (we relied on the Figma's Inspect panel).
A design system is never done, but having these core elements made repeatable and reusable made our team more efficient and saved the company a ton of time and money especially with a small development team.
The last thing to mention: as the sole designer at Flats or Spikes I did my best under the circumstances to keep the system organized and well-kept, but it was not always my number one priority! I was the only direct "user" of the Figma library, so I spent my time making sure it was easy to use (ex. adding synonyms to component descriptions to improve search) and less time on rationalizing every design decision or providing detailed layout specifications (we relied on the Figma's Inspect panel).