Overview
We decided to update the UI and UX of the whole app. To do it efficiently we created the Calliper Design System. It's the strong base for all our design work, making things consistent and work well across different parts of the app.
We created it with slot system. Imagine it like fitting puzzle pieces together: small components fitting into slots in pages, cards etc.
We wanted Calliper to not only make the app consistent but also make designing easier for us by ensuring better designer onboarding, and design collaboration between design, engineering and product managers.
Role
Designer
Team
Uendel Quintela, Lead Designer
Uttkarsh M, Designer
Meghann Chawla, Designer
Eduardo Roisman, Design Operations Lead
Company
Popup - a no-code e-commerce store building app
Year
2022 - 2023
Highlights
Context
We received user feedback highlighting confusion due to inconsistencies in the app. This prompted the Admin 2.0 project, where our goal was to revamp the admin view's appearance and to enhance the overall user experience.
Problem
As we worked on improving Popup's look and feel, we noticed some issues.
Inconsistent UI. Improper visual hierarchy in terms of colors and texts.
User Confusion. Different patterns for doing similar things confused the users.
Popup’s old UI
As Popup was gaining more users we found ourselves frequently tweaking and adding new features.
Detached instances. Lots of Figma instances were detached from it’s component to fit new needs.
Slow Design and Development. Starting from scratch for improvements or new features was time-consuming.
THE CHALLENGE
Screen Audit. Check all screens to figure out what layout and components we needed.
Design System Foundation. Formulate the colors, typography, the whole shebang.
Component Library Creation. Build the component library with slot system.
Documentation. Create proper documentation for easy collaboration.
Workflow. Roll out a workflow for using and creating components.
Foundation
Colors are a big deal for any interface and we noticed we only had a few shades of grey - that wasn't cutting it for a solid visual hierarchy.
The naming conventions relied on generic names like Neutral Light, Neutral Dark, and simply Neutral. While easy to recognise, this method was not scalable as we wanted to add more colors.
Old neutral styles
Cooler, cohesive and accessible colors.
Cooler feel. Tweaked the base grey a bit towards blue and upped the saturation for a slightly cooler feel.
Cohesive Palette. Used HSL to generate more colors ensuring a cohesive palette.
Accessibility. Validated the colors with WCAG 2.0 rules to maintain proper contrast and accessibility.
Updated neutral styles
Scalable names. Introduced incremental numbers to our names, maintaining a 100-gap between adjacent places to easily inject values inbetween.
Tokens. Converted it to tokens to ensure that designers and developers use the same language to refer elements for clear communication.
Neutral styles with new naming convention
And for a bit of fun, we decided to say goodbye to the usual blue and welcomed a fun purple as our primary color.
New primary styles
We identified and removed unused and rarely used text styles, keeping only those essential for our needs.
Old text styles
New text styles
Finally, converting names to tokens gave us clear and concise text styles—ta-da!
Tokenised text styles
Layouts
We finally had to face the devil, over 10 page layouts that were confusing and redundant. We dove into each layout, meticulously found the things they had in common, and merged the similar ones.
Layout study to identify commonalities
We narrowed it down to 3 page layouts that could help us design and build with consistency and velocity.
Index Page Layouts. Layouts for showing indexes across different domains.
Resource Page Layouts. Layouts for displaying items found in the index pages.
Settings Page Layouts: Layouts for managing account settings, preferences, and store configurations.
Streamlined layouts
Library
Figma introduced 3 new Component Properties in their Config 2022 conference. It was introduced to reduce variant proliferation and code align your design system for a smoother handoff.
As the existing components were built before this release, it only had variant properties.
For a better system, we needed to create everything from scratch – from buttons, input fields to tables and everything in between with the new properties.
Old button component with many variants
For a better system, we needed to create everything from scratch – from buttons, input fields to tables and everything in between with the new properties.
We created a total of 70 components. I’ll document some important components in the sections below.
List of components in Calliper system
Along with variant property, we designed components with the 3 new properties - text, boolean and instance swap. This improved how components are handled and used by the team.
Leaner file. It reduces the number of variants needed for each component, keeping the library file leaner.
Better onboarding. It will be much easier for new designers to understand which parts of a component can be changed.
Bridges the gap. These properties are closer to the attributes used by developers leading to a better alignment between design and code.
New button component
Button specifications and component properties
Workflow
Working in a team of designers, having a well-defined workflow is crucial for ensuring better collaboration and velocity.
To keep the main file safe from unintentional loss or edits, we utilized Figma branches to make edits to the main file. Each component was created in a branch and merged once completed.
Screenshot of branches from a year ago
We organized components, styles, and icons into separate files within the design system folder for easy maintenance and access by all stakeholders.
Design system file organization
Along with other steps in our workflow, we maintain a checklist of over 10 items for each component task on ClickUp.
For instance, to maintain low Figma memory usage, instead of creating variants for Switch component with and without Label, the checklist urges us to use boolean properties to manage Label visibility.
This approach significantly trims the number of layers in a component, consequently reducing the memory usage of the component library file and the files in other projects where we use these components.
Figma doesn't just load the instance variant you've added to a file; it also loads all other variants of the component, increasing the file's memory usage.
Less memory usage in files means faster loading times and smoother merging, reducing the risk of 'file out of memory' errors.
It's not a one-time fix; we continuously update it to address the new challenges we encounter.
Clean and Safe. Name and lock all layers to ensure component integrity.
The leaner the better. Utilize boolean and instance swap properties to reduce memory usage.
Documentation. Provide detailed specifications and component properties.
Branch discipline. Always update from the main file in branches to prevent loss of merged work.
Branch link. Link branches to ClickUp tasks for easy access to all stakeholders.
Request Review. Lead Designer, Lead Developer and PM review and approve the branch for validation.
Component creation workflow
THE HIGHLIGHT
Slot system
We use the Resource List component to present different types of resources—products, users, payment accounts, etc. With the help of slots and boolean properties, we can customise it for different contexts in a way that design systems allows us – without the need to detach instances.
Thanks to Figma's Auto Layout, our components dynamically resize and space themselves based on their content when updating the content of a slot component.
Using Resource List component for different contexts
The slot system is built using placeholders (slots), making it super easy to make our own complex component instances by swapping placeholders with small components.
This flexibility will save us from starting from scratch every time we wanted to improve an existing feature or create a new one.
Flexible. Ability to customise components for different contexts without the need to detach instances.
Consistent. Ensures a consistent layout structure and spacing while accommodating varying content.
Time efficient. Structure and layout are already ready to roll. Designers just swap components in the slots based on requirements.
Swapping a slot with different components in Card component
The Section component is a key nested component in cards, modals, and slideovers, featuring a title, description, action, and multiple row placeholders.
Section component properties
Placeholders.
The row placeholders are component instances allowing us to swap them with various components like text inputs, banners, tables, resource lists, etc., based on specific needs.
A row placeholder can also be swapped with a stack row placeholder component to group elements in a section.
Row placeholder components
Card, modal and slideover components are built with multiple sections nested inside. This gives us the ability to customise these components based on specific needs.
Card, modal and slideover components
We added appropriate component properties to all these components to seamlessly utilize them across different areas within the product.
Boolean properties. To show or hide title, description, action, and each row as needed.
Instance swap properties. To quickly swap rows with different components.
Text property. To easily edit content in title and description as all layers are locked.
Nested properties. To easily edit nested instances we exposed nested instance properties as all layers are locked.
Card component instances used in the app
We created the page component with multiple card components nested inside.
This allows us to create pages for different contexts using the same component.
Page component variant and Order page created using the variant
In response to additional requirements from Admin 2.0, we introduced three additional variants to the component.
Index Page Layout. Layouts for showing indexes across different domains.
Table Index Page Layout. Layouts for showing table indexes and empty states across different domains.
Resource Page Layout. Layouts for displaying items found in the index pages.
Settings Page Layout. Layouts for managing account settings, preferences, and store configurations.
Sub-page Layout. Layouts for sub-flows across different domains
Single Column Layout. Layout variant for small screens.
Page component
Row placeholders (slots) are part of sections, nested inside cards, which, in turn, are nested within pages.
Nested component hierarchy
One significant challenge with the slot system is its tendency to result in high memory usage, especially with components nested inside one another.
While working on the Admin 2.0 project, we encountered difficulties merging branches due to this high memory usage.
‘File out of memory’ error encountered in Admin 2.0 project
And guess who was the culprit? Yep, the page component.
It featured six variants, each with multiple nested cards, and each card contained multiple nested sections.
Consequently, every time we added a page instance to a file, it loaded around 20000 layers!
Layers in page component with nested cards
Turns out, we didn't even need all those cards every time. Usually, just 3 or 4 did the trick.
So, to fix this mess, we replaced the cards with slots. Now we only add the cards into those slots when we need them.
This brought the layer count down to 5000, significantly reducing the Figma memory usage.
Layers in page component with nested slot placeholders
THE HIGHLIGHT
Pages created using Page component
Documentation
Documenting components is crucial for collaboration.
Each component's specifications, properties, and instance matrix are detailed on its dedicated page, serving as a reference for clarity on structure and behavior.
It includes intended use, design specifications, and instance matrix for consistent implementation by the team.
Documentation for Thumbnail component
Documentation for Checkbox component
Documentation for Combobox component
We also added versioning and changelog to document the changes we make to the components.
This helped us and the engineers track modification and ensure alignment between the designed and developed components.
Documentation for Combobox component
Enhancement
Need for a touch up in the workflow.
As the Admin 2.0 project unfolded, despite our efforts to adapt existing components, we recognized the necessity of introducing new components to our library for some use cases.
Moreover, the implementation of these components in the project exposed bugs/issues in them.
As a result, we identified the need for a subflow in our component creation workflow to request new components and report bugs.
The goal was to ensure that the Admin 2.0 project wouldn't be hindered by the requirement for new components.
New components. Workflow to request and add new components.
Bugs/issues. Workflow to report and fix bugs in components.
Time efficient. Needs to be time efficient to ensure no delay in project timeline.
THE CHALLENGE
Recognizing that the process of creating, validating, and adding a new component to the library could take some time, we were determined not to cause delays for designers working on Admin 2.0.
To address this, we introduced the concept of Proposals.
Picture this: You identify the need for a new component, inform the design system team, and while they work on the official version, you swiftly put together a rough component (Proposal) for immediate use.
The proposals are named with the prefix 'Proposal' for easy identification in the Admin 2.0 project files.
This allows designers to continue their work seamlessly without waiting for the final component and it can be quickly put together and validated through comments.
Proposals also act as a reference for the design system team.
Validating the proposal with the product manager in Figma comments
We made a form on ClickUp - Component Library Task. When you submit it, a task is automatically generated in the Component Library project board.
This form serves a dual purpose, allowing us to request new components and report bugs in existing ones.
Screenshot of the Component Library Task form from ClickUp
With the addition of proposals and the form to our workflow, Admin 2.0 projects proceed seamlessly without delays.
Updated component workflow
Retrospective
When we started the project we underestimated how much time this would take. It took 100% effort from each member of the team for about a year to reach the here. This project has been one of the most challenging and undoubtedly one of the best projects I've worked on.
Screenshot of a meme about the project during a Town Hall meeting
Over-communicate. Communication is key, especially in remote work. I make sure to share as much details as possible in my messages and comments because it's easy for information to get misinterpreted.
Keep everyone in the loop. When we encounter edge cases and find creative solutions, it’s crucial to share these experiences with the team so that everyone understands why we tackled them the way we did.
Workflows are time-efficient in the long-run. Creating a ClickUp task for every change, checking off each item on the checklist, creating a Figma branch for every task, etc seemed repetitive and time-consuming at first. But with a big team, these steps are important. They keep everyone in the loop and help us collaborate better.
File organisation. Keeping the files organised and tidy from the start saves a load of time and chaos.
