Exsportia is a comprehensive solution for sports venues and their customers. Businesses receive the Back-Office—a CRM tailored to the sports industry that they can customise. Venues also benefit from a custom mobile booking app, eliminating the need for back-and-forth communication via phone calls or messengers. The app is always up-to-date and works in the background.
From 2021 to 2023, I worked at Exsportia on their customer mobile app. During that time, I took ownership of the development of a new design system as well.
Before implementing the design system, Exsportia experienced inconsistencies in designs across its products. The apps were mostly hardcoded, and the development process was slow, bulky, and unoptimised. Furthermore, there was a gap between the work of the designers and the development of the apps.
Why we made a design system
The main goals of implementing a design system were:
-
To reduce design and development time by providing reusable components;
-
To improve collaboration between designers and developers and eliminate the gap between designs and actually developed applications;
-
To systemise the workflow and minimise delays;
-
To improve the user experience by providing a consistent and scalable design language and interface across all products and services.
The process
Design audit and implementation
I began by examining the existing components and assets, as well as evaluating the current state of the production apps. The goal was to make the existing components more flexible, scalable, and reusable. This involved performing a complete cleanup of the Figma library files, restructuring components, optimising them, and removing any obsolete ones. I also named all the layers 🫢.
Upon evaluating the adoption of components within the Back-Office, we discovered that only 24% had been implemented, with the remaining 76% hard-coded within the app. Since the customer app had no components at all, we reworked the design and gradually adopted components over the course of several months, adding them piece by piece. You can learn more about the process of implementing components for the customer app by referring to our case study.
After evaluating the design system, we prioritised future components updates and began the long work. While there is always a boost of motivation when starting a new design system, the work eventually becomes routine, including tasks such as upkeep, bug fixing, and documenting. However, this is important work that pays off in the long term. I will share more about the results in the end.
Documentation
Initially, I began documenting in Zeroheight, which provided a Notion-like interface with useful features such as easy Figma asset integration. However, Zeroheight did not offer automated technical information input with interactive components, which we later achieved through Storybook.
Technical ecosystem
We created a general Figma components library that distributed its components to both the Back-Office and the customer app libraries. These two libraries were connected with the React Native and React libraries of both products.
Typography
We created a typographic system with simplicity in mind, using as few tokens as possible. The system was designed for both web and mobile, with identical styles to easily switch between the two during the design process.
We based the design system on a 4px grid, sticking to it for most of the typographic styles. The only exception was the smallest Footnote style, which was given a preference for visual compensation and balanced line height. We also followed the Material design recommendation of using a font size of 16+px for paragraph text.
Colour system
When you compose a colour system within a design system (excuse me), it’s crucial to pay attention to a few major aspects which will shape your choice: Accessibility, Shades transparency 🆚 Solidity and Hierarchy.
Accessibility, of course.
We made sure each colour passes the WCAG 2 AAA threshold. I personally prefer the Contrast Figma plugin for quick checkups during colour exploration.
Shades transparency 🆚 solidity.
We opted for transparent shades over solid colours to minimise the number of tokens and ensure visual quality control and consistency. However, more care had to be taken when selecting colour styles to avoid overlapping colours that look messy or hard to read.
Colour gradation, such as 9 shades from 10% opacity to 100%, was avoided intentionally, as this approach could damage visual consistency and slow the iteration process unless the project was extremely complex.
Hierarchy
We organised our colours in a separate file within Figma—just like Typography, Icons, and Components. Colours are grouped by usage:
-
PrimaryandProjectstokens are accent colours, varying between projects; -
TextandIcontokens are separated to enhance productivity and enable bulk editing.Iconcolours are slightly lighter thanTextcolours for visual compensation; -
Labeltokens are used to provide visual cues, such as errors, notifications, highlights, and callouts. They feature solid shades for text, icons, outlines, and halftones for backgrounds; -
DividerandBordertokens are used for lines and outlines; -
Statestokens provide the background colour of design items in different interaction states, whileOverlayis static.
Icons
At the moment when we needed new icons the most, we didn't have the resources to create our own custom icons set from scratch. So, I decided to look at what commercial assets were out there and narrowed it down to 5 different 24px Figma sets.
After some careful consideration, we ultimately chose MyIcons as our main UI icons set for a few reasons. First of all, it was the largest set available at the time, boasting an impressive 9,000 icons. To put that into perspective, the closest competitor, Bowcaster, only had 1,200 icons. Plus, the Myicons creators were constantly adding new icons each month, which was a huge plus.
Myicons set covered about 90% of our needs with their extensive categories (such as sports, e-commerce, payments, communication, and web controls). Also, I was able to design the missing icons myself in the same style. And in addition to the main UI icons, we used over 270 custom icons for sports, classes, amenities, and venue types.
To keep everything organised within our design system, we stored the icons as a separate file in the Figma team. And to make sure everything stayed up to date and synced with the React repository, we used the handy DSync Figma plugin. Overall, using the Myicons set ended up being a great solution for our design needs.
Components structure
When it came to developing our design system, we didn't just rely on our own knowledge and experience. Instead, we scoured through a variety of sources - including other design systems, case studies, documentation, articles, and guides - to find the best practices out there. While our design system hierarchy did end up being quite similar to the Atomic design methodology by Brad Frost, we didn't try to shoehorn everything into a strict framework. Instead, we took the principles that made sense for our particular project and built upon them in a way that worked best for us.
As for the actual design of our components, I made sure to prioritise future flexibility and "swapability" when building each complex component. For example, the table component was a typical atomic template. With this in mind, I designed the component in such a way that designers could easily swap out each column for any functional variant preset or customise the headers for quick iterations within the attached component. By doing this, we were able to create a more dynamic and adaptable design system that could be easily tweaked and modified to meet our evolving needs.
Upshot
Over the course of about a year and a half, we successfully implemented our design system and saw a significant increase in component adoption across both our customer and Back-Office applications. In fact, our customer app adoption rate went from 0% to 92%, while our Back-Office adoption rate increased from 24% to 58%.
Of course, a design system is never truly "done". It needs to grow and evolve alongside the product's goals and changes. With this in mind, we continued to push forward and not rest on our laurels. In addition to the design system improvements, we also implemented Scrum framework elements to help systemise collaboration within the team. This resulted in a more polished workflow, which allowed us to deliver features 5 times faster than before.