Company:
Tripla
Year:
2021 - 2023
Team:
UX designer, Product Owner, BE Developer, FE Developer
Issue:
Tripla’s CRM lacked visual and interaction consistency as new screens and features were being built without shared design guidelines, leading to inconsistent UI elements (buttons, toggles, messages) across the product.
Challenge:
Design and implement a Design System capable of bringing visual consistency across products while aligning designers and engineers around shared UI standards.
Outcome:
Delivered a Design System that defined a shared visual language and standardized core UI components. While the system established a solid foundation, limited adoption across teams reduced its impact, highlighting the need for stronger integration into workflows and ownership beyond design.
Once alignment was established across teams, I began building the Design System. I structured it into 11 categories, each intentionally defined to address recurring issues I had observed over time. A core component of the system was a clear set of do’s and don’ts, supported by real examples that contrasted incorrect usage with the recommended execution.
The Issue
Tripla’s enterprise CRM shipped new customer-requested features every sprint, driving constant page iterations and new page creation. Without design guidelines, PMs and engineers implemented these changes inconsistently, leading to a fragmented CRM experience.
Some examples of inconsistency were:
- Button styles and states were different from one page to another. Even colour and hierarchy were not the same.
- Toggles, checkboxes and radio buttons were being used indistinctly without regards for each items technical specification.
- There were “messages” all across the system without proper formatting or differentiation between warning, error, success or information.
Information banner displayed with red tones, which can be easily misintepreted as an eror message.
Information banner displayed in a unique format and color, inconsistent with any other format on the platform.
Building Process
Through the whole process, there was constant communication with the front-end developers and Product Managers to get input on what their concerns were and agree what to prioritise on the first version of the design system. In order for it to be successful, I needed the point of view of the engineers so they felt involved in the process and the would get to adopt and use it as often as possible.
Adoption Phase
After four months of hard work, the project was done. It was released as a Figma file and prototype that anyone at Tripla could reach out to anytime they wanted. Ideally it would have been launched as a live site but we had no engineering resources.
I naively thought from then on, all inconsistency issues would disappear. I could not be more wrong. There were two problems:
1. I had no overview of what features were being built. I only noticed design inconsistencies once the feature was deployed, and by then, despite me creating a new ticket to correct the issue, it meant more debt to maintain and fix it.
2. Despite we having a Quality assurance team, their focus was on finding any functionality issues rather than design issues.
3. Pre-existing inconsistency issues continued to be there months after the DS was launched and there was no clear intention to allocate any engineering resources on fixing these.
Team Consensus
As I started to recognize the issue, my next step was to validate whether it was shared across the team. Through ongoing conversations and meetings, it became clear that the further we progressed, the more difficult and costly it would be to address these inconsistencies. At the same time, it was evident that building a Design System was not considered a priority.
This raised a critical question: how could I convince key stakeholders that UI/UX inconsistency was not merely a design concern, but a structural problem affecting engineers, customers, and end users alike?
After months of consistently raising these issues and demonstrating their impact, I was given approval to dedicate a few hours per week to building a Design System.
What Could I’ve Done Different?
I failed to integrate the Design System into the organisation's workflow and culture.
In the first place, design inconsistency was never considered an issue. In order to put it on the map, I would elaborate more and do workshop or presentations to expose why it is an issue ans why it should be fixed. Then clearly communicate how the design system would help solve these issues.
Second, I should have provided training and support to help team members effectively use the design system. This could be achieved by following a structured approach to ensure they understand both the principles and practical applications of the system.
And last, but probably most difficult, I would suggest to add a filter for UXQA before shipping any new feature. This might slow down the speed at which new features are launched, but it would improve on the long run the quality of the platform.