Provide a strategy for achieving and maintaining ±90% Consistency Through all the Company's Visual Communication Channels and Products.
The "Road to Consistency" initiative was part of the global rebranding and restructuring processes that started long ago. The company is a supplier of 6 digital products with their audience and branding. Besides that, the company has its umbrella brand for employees and business partners. Complex organizational and technological structures created difficulties for synchronizing design between stakeholders, departments, and products. The initiative's goal was to find, develop, and implement the solution to achieve visual unity and create a holistic image for the company and its products.
— Specifiyed Goals and restrictions with stakeholders;
— Organized the group of responsible design leads;
— Analysed the structure of design resources;
— Analysed the level of consistency;
— Researched the possible solutions.
The level of consistency for each design solution could be determined only in relation to the standard of consistency, which should be determined in advance.
There are many different types of consistency. For product design:
— Between application or channel and guidelines (standards);
— Between screens inside one application;
— Between applications for different platforms inside one product;
— Between marketing channels and application;
— Between different products and their applications inside one umbrella brand.
For marketing design:
— Between marketing channel and guidelines (standards);
— Between design publications inside one marketing channel;
— Between different marketing channels inside one product;
— Between different products and their marketing channels inside one umbrella brand.
There are 11 design teams and each of the teams work with their own design library. It was clear for us that before we can offer any global solution we need to determine how they operate consistency inside each of the teams. Therefore we have applied fast but not very accurate method of heuristic evaluation. Nobody ever used it for consistency so we have build the scales from the scratch.
An empty template for evaluation was sent to all the teams with the request that each team member fills it out. Each team lead has taken an average and sent it back to us.
At last, after observing the situation with all the details, we could agree on our year objectives and set benchmarks. The heuristic evaluation we have used for defining the level of consistency was not very accurate but gave us the baselines.
At first, we analyzed all the gathered data and brainstormed all possible solutions. Then we defined the criteria and picked the three most promising solutions for the cooperative analysis. According to the analysis results, design tokens looked like the only way to achieve our objectives.
Since not all the teams yet operate through component systems all guidelines, tokens could look too radical if introduced too early. Therefore we started with Reconciliation Tables as the transitional measures. Here we:
— Listed key values and parameters that can describe the design of an application, website, service, or assets;
— Determined reference values for each of the products;
— Defined key values that should be consistent and key values that should remain unique like brand color or native parameters of the platform;
— Implemented the table with reference values for creating and verifying the design inside the product;
— Started to use the tables of reference values for multiple products or parts to validate designs across platforms, products, or teams.
On this level, all the values like spacing, color, typography, object styles, and animation were extracted from each design system and represented as data. Later we planned to use them in place of hard-coded values to ensure flexibility and unity across all products and marketing channels.
There were a couple of primary requirements were taken in the considerations:
— Different products had different branding;
— Different departments used different component systems for their web sites;
— Four products were built with the native components: Apple, Android, Microsoft, or Ubuntu;
— Two products were built with web libraries.
It increased the complexity, and we had to define what could become tokens and what could not and how we spread them among all departments.
The company has already tried to implement the component system and guidelines. The failure left an unpleasant aftertaste casting a shadow on all new projects in this direction. Therefore it became even more critical for our team to succeed the third time. Our detailed Roadmap described how the new system could be implemented with the small steps, and each step could improve the consistency and speed up the processes. It would give everybody the confidence and the motivation to keep going till the very end.
At first, the design tokens were implemented only on the design level and used with Figma. The full implementation requires a well-planned naming system. And this system should work for many different teams and departments and their component libraries. Therefore as the next step, we have to analyse all component libraries in use to define the optimal naming patterns. We also need to ensure that all our designers have basic front-end development knowledge to operate the new system.