Design that fits all
Building a design system at cure.fit
It’s one thing to design for a single product and another to design for multiple products that all fit and integrate into one. Over the past three years, cure.fit has scaled to 4 businesses in 8 cities. We deliver healthy food, offer group workouts and meditation through more than 200 centers, provide holistic healthcare with doctor consultations and will continue to expand in other domains for the years to come.
Each of our products caters to a different health need. So, while a customer may use one product predominantly for eg ordering eat.fit meals, when they need to use the app to book a Therapy appointment they should be able to do it with as much ease and familiarity as that of ordering a meal. And that’s where cure.fit needs a design system — for usability, scalability and consistency
What we set out to do
We had 3 main goals:
- Single language for all platforms: We mostly worked on building and fine tuning our mobile flows and wanted to maintain a strong feature parity with our products on our website too.
- Scaling to more contributors: Over time, we would expect different stakeholders - new and old to contribute to the product without worrying about consistency.
- Harmony between design and code: When we thought about standardisation, we wanted it to be spread across visual elements for design and re-usable UI components for the developers to drive efficiency.
Going back to the start
We laid down all our flows and their associated screens. As we dug deeper, we saw some foundational issues such as
- the lack of a responsive grid system
- multiple icon styles
- too many colors
We also found a few broken experiences and screens that needed immediate attention.
Foundational grid
We started referring to other design systems including Apple, Google, Airbnb, Go-jek, Uber, Atlassian, Marvel, etc. Based on our findings from the previous exercise and after studying the processes followed by other design teams worldwide, we decided to start with defining our grid systems. So, we worked with our developers to understand the frameworks they use.
Should we follow a 12 col- grid on all platforms (desktop/tablet/ mobile)?
Should the gutter space and margins be same across all platforms?
Would different number of columns work on different screen sizes?
How would this affect our components?
These were some of the questions we grappled with during our initial days. After multiple discussions and iterations, we decided to go with 12 col. on desktop, 8 col. on tablet and 4 col. on mobile.
Out with the old, in with the new
Before jumping into our components, we took stock of all our current assets — icons, tags, typography and colors. We identified the most used icon styles and button types. We scanned all our existing flows and defined two distinct icon styles — actions and information. We also defined specific button styles for core use-cases.
This exercise took place around the same time we were re-defining our in-app and web navigation. This helped us standardise our headers, sub-headers and footers. These became our new building blocks. All our components were then built on these base elements.
Lists and more lists
In the process of going through some of our previous steps, we made some exhaustive lists and populated some excel sheets to keep track of the components we ideally need, the ones we already have and some that need thought from ground-up. Let’s just say that the number of inconsistencies we found, surprised us all.
A list like the one below also helped us go through our widgets by pages, by use-cases and by devices. All the tracking, linking, vetting was done on this sheet. We were three designers working on the project and a list was easy to manage and update but I would strongly recommend using tools like DSL(InVision) and Abstract to help collaboration, especially with a larger team.
Creating Components
We went through multiple iterations as we picked up different pages and their elements. A few rules that we followed were:
- Follow the grid!- All components should be designed for web, tablet and mobile sizes (of course, barring a couple of exceptions)
- Make sure the assets (images/ icons) have the same aspect ratio across different screen sizes so that it is easier to maintain assets
This was also when we standardised some of our font styles, largely for headings, sub-headings and body of text. We also started combining all our components into a single master sketch file which could later be used as a library. Like I mentioned earlier, Sketch might not be the best way to collaborate. We ended up having a stack of duplicate files and screens which needed to be cleaned up and organised.
We could see patterns emerging within our widgets in terms of structure and styles. For eg., We needed carousel for most of our widgets on the landing pages and so we iterated on the carousel arrows. Eventually, all of our components started to become similar in structure while still having a distinct personality.
Here’s how our master file finally looked:
Naming our design system
The cure.fit logo is derived from the human form. It draws inspiration from Leonardo Da Vinci’s Vitruvian Man that essentially represents ideal human proportion and balance in nature (Read more about our logo design here). Since our design system also brings about balance and consistency to our products, we decided to name it Leonardo or as we fondly call it ‘Leo’.
A big shout out to Uttam Soni , Ranganath Krishnamani and Milind Kaduskar for their contributions to Leo.
Into the future…
This was just the first phase of building Leo at cure.fit. We are still in the process of getting some of the elements developed and also working on the next set of components. Here’s a list of our key takeaways that we hope to implement in phase 2:
- Align in terms of tools and process. Use tools like Abstract and Dropbox for version control and syncing up files
- Document all changes for future references.
- Involve developers early so that you don’t spend too much time on basics like grid system
- The design system has to keep evolving.
We are also looking for designers to join our team at cure.fit. Write to product.design@cure.fit if you are interested.
