Tripla is a Japanese B2B PMS (Property management software) that allows hotel managers to do tasks such as managing reservations, tracking occupancy, generating invoices and receipts, and maintaining financial records.
Tripla Book, the company’s main product, had two interfaces: The Booking Widget for potential hotel guests and the Concierge Manager for the hotel staff. The CM (Concierge Manager) was being updated every new sprint with new features requested by customers. This meant two things:
- An existing page was being added new functionalities.
- A new page would be added as a new feature.
The problem was that PM’s and engineers were building these updates and pages without any design guidelines.
As a result the whole CM was lacking consistency.
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.
As I became aware of the issue, the next step was to know if this was actually an issue for other team members. With each meeting, it became increasingly clear that the further we progressed in building the product, the harder it would be to fix any issues. It was also clear that building a Design System was not a priority.
How can I persuade top stakeholders that UI/UX inconsistency isn't just a design problem, but an issue that impacts engineers, customers, and users alike?
Some stakeholders never had no clue what a design system was, so it was up to me to to spread the word and state the importance of having a set of rules that we could all agree. After a few months (and meetings) of pointing out at the same issues over and over again, I got a green light to allocate a few hours a week to build a design system.
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.
With a set timeframe and a clear deadline, now it was time to focus on getting it done. I started with logos, colours and typography. From there I thought on how to categorise the rest of the issues. I decided to settle for 11 categories, each one though to group a set of issues that I had observed through time.
Each section would have an introduction which would be followed by subcategories. In each subcategory, there would be an explanation of the component and a side by side comparison
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 enginnering resources on fixing these.
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.
