Opteamis
Industrialise the design of a white-label platform with a design system
Team
Date
Start of design - Q2 2023
End of design - January 2024
Methods
Design system, card sorting, expert analysis.
Introduction
Opteamis is a VMS (Vendor Management System) platform that brings companies and IT service providers together. Clients publish invitations to tender, contract and manage their services from the platform, while ESNs and freelance consultants search for their next assignment.
Recruited as a UX designer in September 2021, my mission was to ensure the quality of the user experience. My recruitment led to the creation of the Product department, where I defined the initial design foundations to support the strategy initiated by Johan Dhennequin, Head of Product. On a day-to-day basis, we worked together to identify problems in using the Opteamis platform.
Context
For 12 years, Opteamis has been developing features to create a tool capable of meeting all the needs expressed by its customers. In the end, the platform became a jumble of features that were sometimes hard to understand, often frustrating and always complicated to use. Furthermore, interface components were not homogeneous: they were all different from one page to the next, creating a visual cacophony to which were added problems of information architecture.
Problem
Goals
Guarantee greater consistency and visual quality by standardising components for all brands.
Increase the speed of prototyping and front-end development.
Issues
Visual inconsistencies
Some visual elements were differents from one page to another, even though they functioned identically. This problem affected all types of component, including important components such as drop-down menus, datepickers and search bars.
Poor ergonomics and accessibility
The components did not meet the quality standards required for a usable interface: the contrasts did not meet WCAG requirements, abstract icons had no labels, etc...
Unnecessary delays during prototyping
During prototyping, I was wasting precious time recreating simple elements such as a button, a search bar, items in a list, etc... What's more, every time I needed to make changes to a component I had to carry the changes over to all the prototypes instead of updating the style on one click.
Going deeper
Additional and costly development for white labels
Opteamis often had to engage additional development work in order to launch the white-label platform to its customers. Whether it was a slight rebranding or the development of new functionalities, the time involved was too long and costly.
Problematic CSS overlays
The components of the library used (Bootstrap) were not very flexible and difficult to customise. To compensate for this, developers added CSS style sheets when creating pages. But CSS additions were local: if modifications were necessary, they had to be made one by one on each page to standardise.
This method was not scalable, as making minimal changes required precious and tedious time. This became even more complicated when making large-scale changes, particularly in the context of white-labelling for a customer.
There was no front-end documentation. No designer or developer knew what components existed and what to use when a new feature was developed.
Solution
I launched the project of design system creation in order to :
-> Increase the speed of prototyping and development.
-> Guarantee better quality and greater visual consistency by standardising the components of the white-label platform.
-> Improve collaboration between teams by creating a common reference for designers, developers and other stakeholders to facilitate communication and minimise misunderstandings.
Challenges
Create a system compatible with 3 different products.
Design a system that can be easily customised and deployed on a white-label basis for the customer.
Set up a collaborative work process to involve the company in the product improvement project.
Approach
Opportunities
Opteamis used the components and grid system of the Bootstrap library. But in 2022, a technical migration to a new technical stack integrating PHP and Angular was initiated. And it opened the discussion about a change of front-end framework.
preferred solution
As a designer, I recommended the CSS Tailwind solution, which had the advantage of being very popular, working well with Angular and being easily compatible with the topic of design tokens. In addition, I mentioned the installation of a storybook as a repository for developed components.
TOOLS
Component design
Figma
Component library (for design)
Figma
Component development
Tailwind, Angular, CSS…
Component library (for development)
Storybook
Documentation
Probably Zeroheight
Tools to define
Process
Design 1.0 - Designing a first version compatible with the legacy
With this first version, the idea is to make all the components uniform, consistent and linked across the platform, so that if changes are made to a component, there will be no inconsistency from one page to another.
Step 1
Listing existing components
The first step was to list the components that needed to be redone. The aim was to obtain an exhaustive overview of what already existed and to anticipate the consequences for the interface if one of these components were to be drastically modified.
Step 2
Thinking about the components needed
Next, I drew up a list of potential components that are essential but missing. These future elements would be anticipated in the design.
Step 3
Organising the structure of the design system (card sorting)
We organised events with the developers to sort out the old and new components in a logical way. Given that developers and designers were going to be working with this common tool, they had to have the same language and it had to make sense to both parties involved.
Step 4
Designing components
I defined the component variables on paper and then had them validated by the developers. Then I created them on figma. These first bricks were the start of our component library.
Step 5
Testing components
Even though we had anticipated the possible impacts, we had to test the components to ensure the integrity of the pages. The results were as expected. The pages weren't any better, but at least the components were unified and we had solved an initial problem: the inconsistency of components across the application.
Design 2.0 - Designing for the future
This second version was part of a major overhaul. The aim was to update the platform interface with the new Opteamis branding and to improve the components for the new platform redesign. It was in this version that we began integrating the principle of design tokens to improve control, update components and manage our white-label platform.
Step 1
Improving and updating components
Improving usability, legibility and accessibility issues to make the user interface more pleasant and closer with the new brand image.
Step 2
Defining the palette and design tokens
I collected the colours from the Opteamis brand identity and then used the UI Colors application (from Tailwind) to create different shades. All the colours were then adjusted to improve contrast and adapt to the interface.
The colours in my palette were used in named tokens. The outline, background and text colour tokens were applied directly to the components. If colours from the palette was modified, then all the tokens using the hexadecimal in question were affected. Similarly, if the value of “color/border/textfield/default” was modified: all components using this outline token (input, textarea, select...) were automatically updated.
In addition, the design token designation helped developers to know which token to use instead of using vague references such as ‘brand:100’ or ‘grey:700’.
Step 3
Creating a white-label management system
As the colour tokens for Opteamis were defined, we could create versions of these tokens for other brands such as MyTopManager and LuxeForGuide. This was managed using Figma's “mode” feature.
Once the tokens were defined, we could select any prototype and see what it looked like for MyTopManager, LuxeForGuide, etc... And so adjust the customer's colour palette.
This allows us to manage our product roadmap with updates to our platform, without damaging or modifying the visual specificities of each of our customers.
Step 4
Developing components for the Storybook
The components designed were developed and stored on Storybook. This repository also served as a playground for testing each component case.
Whenever a developer needed to use a component for a feature, they could copy the correct code and paste it into their text editor.
Learnings
The design system is an often misunderstood tool
When I started working on standardising the elements of the legacy version (1.0), we were talking about slight visual improvements. The team in charge of visual identity and marketing at Opteamis got involved because, before the creation of our Product Department, they had historically worked on visual improvements to the platform. Unfortunately, they had reworked individual pages and elements without thinking in “atomic” terms. The work produced was neither coherent nor usable.
It was by presenting new screens and re-explaining the implications of the project that I was able to take charge of the subject. I took over responsibility for the design.
The need to explain the cost of bad design
An element hard to understand, lacking of contrast or hard to use can have a negative impact on an experience. But it's hard to convey the scale of the impact of such a mistake with numbers. Yet, this is what decision-makers without a designer background needed to visualise in order to understand. Faced to this problem, user testing was the best solution.
By carrying out user tests, I've shown stakeholders how interface elements that are considered “trivial” or “incidental” are in fact extremely important for the user to understand the interface and for their experience to run smoothly.
This has often saved me when I was facing stereotypes and preconceptions about the web, which are sometimes hard to resist.
Foreword
The design system has become a very common tool. But this topic does require a few reflexions before jumping in the project of a design system creation. Even if it is often beneficial, it requires skills, a daily investment and costs.