ATOSS Workforce Management Design System Upgrade
(2023-24)
Brief
Detailed
Reading time: ~ 5 minutes

The brief version will give you a good overview of the project, highlighting the key challenges and solutions.
Summary
The three-year-old design system for ATOSS’s workforce management tool had not been fully implemented, leading to inconsistent interface components and confusion among designers, developers, and product managers. To resolve this, we decided to overhaul the design system alongside a software redesign. Our goal was to create a scalable system that balanced flexibility with clear guidelines, making it accessible to both technical and non-technical users.

I led the project, refining key aspects such as colours, typography, and other important elements to make the system more effective and easier to use.
Research & Analysis
I began with a benchmark report by comparing our design system against industry leaders like Atlassian, Material Design, IBM Carbon, and others. The goal was to identify weaknesses and gather insights for improvements.
Our findings were:
Our system was more designer-friendly but needed to be more balanced for developers.
Lack of accessibility guidelines for keyboard navigation, screen readers, and contrast.
Inefficient descriptions of design specifications.
Too loose guidelines, leading to design inconsistency.
The system wasn’t scalable for other ATOSS products or flexible for brand updates (colors, fonts).
Interviews with developers, designers, and product managers revealed their needs:
Developers: A pixel-perfect, well-documented library of components with clear instructions.
Designers: Customisable components, clear guidelines, and support for accessibility.
Product Managers: UI kits compatible with Windows and well-structured documentation.
We defined the following key goals for the project:
To increase developer efficiency, reducing time spent on UI bugs and rework.
Improve design consistency across the interface, based on designer feedback and usability testing.
Ensure the new system would be scalable for future ATOSS products, specifically by ensuring it was modular and flexible enough for rapid changes.
Enhance accessibility regarding contrast, keyboard navigation and screen reading to comply fully with W3C standards.
What a surprise!
I created a component inventory, auditing all design elements to ensure they were relevant and useful. We removed unused tokens and components to improve efficiency.

It turned out that many tokens, and even some entire components, were not used in the product at all. That means valuable development resources were wasted on implementing components that were never used, much like preparing a feast only to store it in the fridge. We aimed to prevent this waste in the new system at all costs!
Testing & Iteration
During the redesign, I held regular meetings with the development team to address any issues with implementing the new designs. Based on their feedback, I made iterative adjustments to ensure the design system was developer-friendly. Reviews with design colleagues, developers, and product managers, particularly for complex components, helped keep design specifications clear and practical.
I created a style guide, introducing a new font, colour palette, and a 4-point grid system, while keeping the icons unchanged. I also developed usage guidelines for good text-background contrast and standardised the design specifications for better clarity.
Final Result
Figma UI Kit with 86 pixel-perfect design assets and 867 components, creating a comprehensive, consistent, and efficient set of UI components.
Documentation is more detailed and up-to-date, covering all rules and principles.
Accessibility focus, making each component inclusive.
Design Specs with adjusted format for clearer design explanations and developer documentation.
After the implementation of the new design system:
Developer efficiency increased, as tracked through team feedback.
Design colleagues reported a significant improvement in design consistency.
The number of accessibility issues decreased drastically, particularly in areas such as contrast and screen reader compatibility.
Lessons Learned
I learned that building a simple foundation and gradually improving the design system works better than creating a fully detailed system upfront. Both the product and the system evolve together, and input from various disciplines is essential. Involving developers early in the process felt particularly beneficial.
Next Steps
Before leaving, we implemented a change management process, including training sessions for designers and developers, and weekly check-ins. A long-term maintenance plan was also established to keep the system updated and adaptable to ATOSS’s evolving needs.
Reading time: ~ 20 minutes

The detailed version offers a deeper dive into the design process, also covering additional information along the way.
Summary
The three-year-old design system for ATOSS’s leading workforce management tool, had not been fully implemented across the interface. Some components followed the design system, while others did not, resulting in inconsistencies in both design and code. This lack of cohesion caused confusion and frustration among designers, product managers, and developers.
‍
We decided to overhaul the entire design system alongside a software redesign project. The aim was to create a scalable design system that balanced flexibility with clear guidelines, making it easier for the development team and understandable for non-technical colleagues.
‍
I led the project, improving the existing design system by revising key elements such as colours, typography, and other essential guidelines.
Research & Analysis
I started by creating a benchmark report, comparing our design system with industry leaders like Atlassian, Material Design, IBM Carbon, Shopify Polaris, Ant Design, Uber, and Microsoft Fluent. Our aim was to identify strengths and weaknesses in our system and gather insights for improvements.
Our findings were as follows:
Our design system was more designer-friendly but needed to balance the technical side, as it must serve both equally.
Lack of accessibility guidelines for keyboard navigation, screen readers, and contrast.
Inefficient descriptions of design specifications.
Style and other guidelines were too loose, causing inconsistency in design.
The system wasn’t scalable enough for other ATOSS products or flexible enough for brand adjustments (colours, fonts).
I also conducted interviews with developers, designers, and product managers to understand their needs:
Developers:
A comprehensive, pixel-perfect library of reusable components.
Detailed specifications with clear instructions and practical examples, including a "technical playground" for documenting code snippets.
Lightweight and efficient components.
A scalable system for potential future use across other products.
Designers:
Customisable components that meet individual design needs.
Design tokens and variables for quick adjustments of colours, fonts, and spacing.
Clear guidelines.
Support for responsive design and accessibility.
Provision of Figma UI kits.
Product Managers:
UI kits available on Windows, enabling them to create their own mockups.
Clearly defined communication channels.
Consistent documentation standards.
We defined the following key goals for the project:
To increase developer efficiency, reducing time spent on UI bugs and rework.
Improve design consistency across the interface, based on designer feedback and usability testing.
Ensure the new system would be scalable for future ATOSS products, specifically by ensuring it was modular and flexible enough for rapid changes.
Enhance accessibility regarding contrast, keyboard navigation and screen reading to comply fully with W3C standards.
What a surprise!
I then focused on the architecture of the existing system. I created a component inventory, listing and categorising all existing design components. Each component was reviewed for its intended use and frequency of occurrence. During the token audit with the development team, we agreed to remove all unused tokens and adjust the ones in use according to the new guidelines.
‍
It turned out that many tokens, and even some entire components, were never used in context of the product. Valuable development time had been wasted creating elements that weren’t implemented in the software. It was like preparing a feast only to leave it untouched in the fridge. We were determined to avoid this kind of waste in the new system at all costs!
Testing & Iteration
During the redesign, I held regular meetings with the development team to address any problems they had during the parallel implementation of the new designs. Based on their feedback, I made iterative changes to ensure the new design system was as developer friendly as possible and according to their needs.
I also conducted reviews with design colleagues, developers, and product managers, particularly for complex components that required extensive documentation. This ongoing review process ensured that the design specifications remained clear and practical.
I created a style guide using a mood board, introducing a new font, color palette, and a 4-point grid system, while keeping the icons unchanged. I developed usage guidelines to ensure good contrast in text-background combinations. Descriptions and instructions for each component were reviewed and adjusted. I also reviewed the design spec structure for better clarity and standardisation.
Final Result
Figma UI Kit with 86 pixel-perfect design assets and 867 components, creating a comprehensive, consistent, and efficient set of UI components.
Documentation is more detailed and up-to-date, covering all rules and principles.
Accessibility focus, making each component inclusive.
Design Specs with adjusted format for clearer design explanations and developer documentation.
After the implementation of the new design system:
Developer efficiency increased, as tracked through team feedback.
Design colleagues reported a significant improvement in design consistency.
The number of accessibility issues decreased drastically, particularly in areas such as contrast and screen reader compatibility.
Lessons Learned
I gained valuable insights into how a design system functions in code.
Rather than building the system first and then designing, it’s far more effective to create a simple foundation and gradually introduce improvements while designing components.
Developing a fully detailed design system without having a product in place is counterproductive, as both evolve together, leading to duplicated work in some areas.
Input from different disciplines was crucial to shaping the design system into its final form. Involving our development team in the creation process, in particular, felt absolutely right and purposeful.
Next Steps
Before I left the company, the team and I implemented a structured change management process. This included training sessions for designers and developers, and ongoing support through weekly check-ins to address questions and challenges.

A long-term maintenance plan was also established to monitor the design system’s quality. Regular audits will ensure that the system stays updated and can adapt to the evolving needs of ATOSS products.