Clover Go is a mobile point of sale platform. It is an integral part of the cloud-based payment system built by Clover Network Inc. This project highlights the process of building a design system to establish consistency and structure in their app. By crafting a design system, we had a single source of truth that enabled us to build features better and faster. Most importantly, it made our design reusable and scalable.
Due to the lack of structure and consistency in the design process, my on-boarding to the project slow and painful. With no design system, I knew that building any new feature would take me much longer than it should. Clover Go was a fast-growing product with a weak foundation. So, as my first task, I took upon the responsibility of auditing the app and establishing a concrete style guide and component library. I worked closely with the development team and the project manager to streamline the design process and unite the product. In addition, standardizing things like naming conventions and file structures was part of the overhaul that helped prevent user errors.
There was more than one reason why Clover Go desperately needed a design system.
1. Poor versioning system
The team was using Dropbox for versioning. There was, unfortunately, no master file. Every version only had the flows that were added/updated in that release. For example, v2.5 sketch file will only have the screens that were added and changed since v2.4. This means v2.4 sketch file still has flows that are in production. There was no go-to place to check the latest designs.
2. Platform Differences
Even though iOS and Android were designed together, both the sketch files were out of sync. It made aligning and comparing the two platforms very difficult.
3. No naming convention
Not having a naming convention made it difficult to keep track of screens and maintain consistency between iOS & Android.
4. UI Inconsistencies
The checkbox styles, buttons, and padding varied across the app with no structure. This created a fragmented user experience by disturbing the cohesiveness of the product.
5. Undefined styles
With over 25+ shades of gray, 5+ shades of “Primary” green and no defined text styles, there were lots of inconsistencies.
6. Non-existent symbol library
Not having a symbol library can be very costly. One small change to a button style meant hunting for every screen with that component and updating it.
7. Pixel imperfection
There were icons that were PNGs and measured 17x13.87px. This is a BIG NO. If the pixels are not whole numbers (multiples of 8 ideally) and the icons are not vectors, they tend to get blurry on different device resolutions. The app direly needed a cleanup.
8. Lack of accountability
With Dropbox, there was no way to tell who made what changes to the sketch files or folders.
As a fast-paced and ever-growing product company, optimizing speed and efficiency in our process was crucial. Building a design system is an investment - it costs a lot in the beginning but the benefits you reap afterward are tremendous. The biggest challenge I faced was communicating the value of a design system to the client. The design debt we had accumulated over time was slowing us down. The timelines were tight and pausing the work on new features was not an option. So, I set up a meeting with the decision makers to sell the value and gave them a preview of how a component library increases our productivity. We worked out a method where alongside building new features, I started to build components and slowly bring them into our workflow. Simultaneously, I audited the app. I began creating, consolidating and documenting the different UI components, patterns, and styles that were used. I broke down the app into sections and sub-sections and set weekly goals to recreate 150+ screens using our brand new component library. Over the course of 2 months, we were finally in a place where we had a robust design system that doubled our production speed.
To reduce the design overload caused by the abundance of redundant, non-reusable and inconsistent styles, I set out to create:
- A standard set of visual attributes (such as color, typography, and icons), which will help create a unified brand language
- An inventory of UI elements (such as buttons, cards, and modals), which will help create a holistic library of component
- An efficient and accountable working methodology, which will make the process of designing faster and easier.
Established color scheme
Cleaning up the colors used across the app was much needed. We created the colors as layer styles in case the client ever wants to update the color. This would enable making the color change across the entire application with one click.
Defined text styles
Defining our text styles truly helped to pull the app together. It also made it much easier and quicker to design new screens when referring to the styles.
All the icons were redesigned in SVG format and in multiples of 8, so they could be scalable to use in different resolutions.
Robust symbol library
A library of all the UI elements and components that made up 150+ screens was compiled and set up on Abstract for easy reference and maintenance.
Systematic naming conventions
Each symbol, screen, and page was renamed following certain naming conventions. This highly helped in ensuring consistency between different platforms, collaborating with other team members, and maintaining the updates efficiently.
New working methodology
We replaced Dropbox with Abstract to manage and version our design files and symbol library. This saved us tons of time by not having to hunt through folders to find the right sketch files. It was an efficient and accountable way to maintain a single source of truth for our designs.
A UI component library saves designers from spending time on creating repetitive and redundant styles.
Unity in Product
Standardized components used consistently creates an intuitive, predictable and easy to use app.
Working by referring to a design system allows you to put together layouts and flows quickly. This, in turn, helps the team to prototype potential solutions to gather fast feedback.
The more the number of interface elements and styles, the more will be the cognitive load and weight of the app. By using a design system, we ensure that we are thoughtful of which components we are using and adding to the library.
Having a single source of truth is very helpful in bridging the gaps between designers, developers and the QA team. The more in sync the product team is, the better is the work they can produce.
Implementing accessibility at the component level ensures that the entire product is optimized for use for all kinds of users.
Creating a design system was a successful way of not only unifying the user experience but also the product vision, design principles, process, and the brand voice. It gave Clover Go the solid foundation it needed to scale and grow rapidly. The use of a component-based structure helped bridge gaps between the design and development team and vastly improved the team's productivity. Building a design system helped Clover Go so much that the parallel teams that work on Clover's POS systems were inspired to do the same. This sparked a revolutionary design change within the company. Currently, we are all working together to build a master design system that encompasses all of Clover's products.