Design System for Warehouse
PixelWave Innovation was conceived to transform the digital narrative of a leading creative agency. Our goal was to blend cutting-edge design with intuitive user experience, crafting an engaging story that resonates on multiple platforms. By integrating advanced digital techniques with creative insights, the project set a new benchmark for interactive brand storytelling.
Client
Addverb
Date
May 2024 - April 2025
Industry
Robotics & Automation
Scope of work
Design System
Product Design
A/B Testing
Background
In this case study, I would like to share our experience of developing a new design system at Addverb, on which we started working 1 year and 5 months ago. Within that time frame, we assembled a core team, built processes, introduced new tools for work, and laid the foundations of our design system. This project was rolled out without dedicated design or development resources assigned to the design system work. Our experience is about finding a systematic approach and enabling continuous progress in the environment of a large flow of accompanying tasks and changing priorities. In this case study I will be talking about the approach and processes we have been following so far both at the interface design level and at the technical development level.
What is design system?
A Design System is a systematic approach to product development complete with guidelines, processes, components, and code. It is a single source of truth for teams that simplifies the product creation, testing, and development, and ensures consistency across different pages and channels.
Challange
Addverb lacked a comprehensive design system that unified our brand prior to an update. The design system at that time was fragmentary, lacked consistency, and was partially outdated. Additionally, the old documentation left much open to interpretation. As a result, our product, brand, and engineering teams lacked a shared foundation around process, design language, guidelines, and UI pattern libraries. This created inefficiencies for each team, as well as inconsistencies within our product.
Below is a visualization of our Warehouse Management Application that highlights the inconsistencies
As you can see, we had many different colors, font sizes, and spacing values. And that was not only part of the problem.
By creating an updated centralized design system, we aimed to:
Align our teams by giving them a more structured and guided way to build products.
Speed up our design and development process: with a ready-made library and patterns teams can create and test layouts much faster.
Improve brand perception and user trust through consistent experiences that work for everyone and allow users to accomplish their goals.
Promote accessibility of our products by building accessibility and inclusion into our component libraries, both from a design and code repository perspective.
While it was clear that this project would require a lot of resources, planning, and time commitments, we knew that this work was a justified long-term investment in our company, brand standards, and our customers.
UI Inventory
To better understand the current state of our existing design ecosystem, we started with a UI Inventory of our main interface components. We used Brad Frost’s interface inventory guideline as inspiration to conduct a full-day audit that we ran as a team of 2 designers and 2 developers. The plan was to screenshot unique instances of our main design assets such as typography, buttons, icons, input forms, drop downs, etc., and add them to our notes template we had prepared ahead of time. Then each group shared their findings with the team.
As a result of this exercise, we identified a lot of inconsistencies in our design assets, which only proved the need for a more systematic approach to documenting, communicating, and maintaining our design system.
Below are some examples of the irregularities screenshots we came up with after this exercise:
The inventory process helped us clearly see all discrepancies and inconsistencies across our product. It served as a foundation for our design system work. With the audit results in mind, we created a priority list for our design system minimal viable product (MVP).
Company wide collaboration
In order to ensure the success of this project, it was important to get stakeholders on board before we start building our design system.
We systematically promoted the initiative via:
A kick-off company-wide presentation where we shared the current pain points and the anticipated benefits of the project for the company as a whole.
Involving engineering into the conversation early on through bi-weekly design system meetings and workshops to collect their input.
Sharing with squads work in progress and the roadmap of the project.
By getting other teams involved from the onset and as the project evolved, we strived to promote understanding of the project and inspire a sense of co-ownership throughout the entire process.
UI Inventory
We decided to focus first on the foundational elements (atoms) of our design system, such as color palettes, fonts, grid, spacing, buttons, etc., and then move on to more complex blocks and pieces (molecules, organisms, templates, pages). We created components from Ionic Framework since its a warehouse specific system as it served our design needs better.
Some of the activities at this stage involved:
Researching other design systems and interfaces for components common practices and inspiration.
Analyzing the instances and use cases captured during the audit and ideating on the solutions that serve our goals best.
Unifying: we merged different variations of components to leave only the essentials. For example, we limited our color schemes to a maximum of 9 shades for each hue and all the excessive variations were matched and merged with the decided upon schemes based on proximity. Below is our final color palette:
Prinicples
Some principles we followed:
We tried to make our components responsive with the auto-layout Figma feature, so we could reuse those components when designing for different devices or layouts.
We designed to cover all scenarios, or “states” in the system: hover, focus, filled out, error, and disabled state.
When the Variants feature was introduced to Figma, we started using it to combine variants into component sets with custom properties and values. Using variants makes components easier to maintain, browse and swap through the sidebar menu.
Each component we designed with accessibility in mind. We strived to comply with WCAG AA/AAA accessibility standards. Below is an example of intentional choice of color on a warning alert to achieve sufficient text contrast (checked via A11y Figma Plugin) so that users with poor vision can see and use our component.
Reveiw
Reviewing work is an important part of any design process to ensure we arrive at decisions collectively and align on details such as component design, documentation, and tools.
For this project, we formed a multidisciplinary design system team (including cofounders, product managers & devs) that would meet every two weeks to discuss the direction and progress of work.
We also set up a design-systems Teams channel, where we post the design system updates and requests for asynchronous feedback.
These practices allow us to collect everyone’s perspective and bridge the gap between design and engineering.
Documentation
High-quality component documentation is crucial to an effective library allowing everyone to quickly and efficiently make consistent decisions. We wanted to create detailed documentation that would support every single aspect of our design system, and also be organized, consistent, and easy to use. We referred to several design systems such as IBM’s Carbon, Material, Atlassian, Salesforce Lightning, and other design systems for some good practices, guidelines and tools that we could apply in our design system.
Design-led Documentation
Once the Figma components are approved, we move them to a Figma Atomic Components file, a shared library of assets that our team can use to drag and drop while working on their designs.
Sneak Peek: Design System Presentation
Tailwind CSS
We decided to use Tailwind and Iconic Framework for Development as our base CSS framework, main reasons being:
It’s utility focused, which encourages the creation of modular/reusable styles
It’s framework-agnostic, which means Tailwind utilities are supported well both in PHP (our main monolith codebase) as well as React (supplemental parts of our front-end codebase).
It’s highly configurable, allowing us to customize styles for our brand.
It encourages interoperability between design & engineering.
We built Tailwind configuration based on our design system fundamental variables and use it to more easily enforce design system constraints within both of our main technology stacks.
Tracking Progress
In order to track and communicate the progress of the different steps, we created a Jira board that can be viewed and updated both by design and development. We create tickets for specific components that link out to all the relevant documentation and move them to corresponding status columns (In Design, Needs Feedback, In Development, etc.) throughout the process.
Naming Conventions
To ensure everyone is on the same page and speaking the same language, we aligned on consistent, clear naming conventions between design and code, be it font styles, colors, spacing, icons, etc.
The table below specifies font sizes and line spacing in text styles. For convenience, each style is named the same as in the code.
Build
Since we did not have dedicated resources to work specifically on the design system, we sought opportunities to work with squads to incorporate building the design system components into the existing efforts. For example, during the Concinity (Our WMS Application) update, such fundamentals as a grid, typography, spacing, buttons were built out and documented. We plan to continue with this approach with the upcoming initiatives. Of course, we need to account for the extra time teams need to document the components in addition to the main scope of work.
The Future
The design system is an ongoing project. We iterate, change and learn a lot in the process. So far, we have a set of basic components ready, which has been game-changing for our team in terms of efficiency, as well as consistency, and standardization.
In June 2025, we began work on Design System 2.1—an evolved version of our original system shaped by our collective learnings. While our initial design system established a solid foundation, the introduction of new robot types, updated UX processes, and expanded platform requirements revealed gaps in our component library, use cases, and responsive capabilities.
Mainly Colors, Text-fields, Tabs and Icons failed during testing in real warehouse
Design System 2.1 addresses these gaps with more refined and flexible components, enhanced accessibility, and seamless responsiveness across desktop, tablet, and handheld devices. We're also developing specialized components for maps, robot status indicators, and remote robot control interfaces—capabilities essential to our evolving product ecosystem.
This work is currently in progress, demonstrating our ongoing commitment to building a system that effectively scales with both our users and technology.
Some of our team’s next steps include:
Continuing to grow our component library and supplement it with more complex components.
Adding sections on brand and animation.
Cultivating processes and best practices for maintaining the documentation to ensure that our library stays up to date and perfectly in sync both on the design and code side.
Raising awareness across the teams and promote adoption and contribution to the documentation.
Building processes for testing the components on compliance with guidelines and accessibility standards.
