An in-depth assessment of Vivisol's design system highlights areas for improvement in accessibility and consistency across healthcare interfaces.
In recent years, the tech world witnessed how design systems have gone from a trend to a standard, allowing us to guarantee the consistency and scalability of any digital product. Initially, many tried to create their own design systems but made mistakes due to lacking best practices and literature.
Buildo has always been deeply interested in this topic, and we have gained valuable experience creating and maintaining design systems. As a result, we are now well-equipped to guide our customers through every phase of the process, from initial development to ongoing evolution.
The first step is always the Audit.
Vivisol, part of the SOL Group company, is a homecare service provider that focuses on improving the quality of life of chronic patients whose therapy is delivered at home or in residential facilities. For this reason, their design system must guarantee a coherent and accessible experience across all their touchpoints.
The audit results have provided Vivisol with a comprehensive evaluation of its design system's strengths and weaknesses. By identifying potential issues, the assessment will enable Vivisol to improve its design system by addressing inconsistencies and enhancing the overall product design and user experience.
Just as the creation of every design system starts from its foundations, the same happens when we start our audit analysis. Every improvement we suggest on colors, typography, and spacing scale can bring alone the most significant impact in a design system rework since they effortlessly propagate to every component, pattern, and layout that uses them as a token.
The qualitative analysis was carried out starting from the experience and know-how Buildo gained in the creation, maintenance, and restructuring of design systems on behalf of its customers. It was then integrated by a quantitative analysis based on the Web Content Accessibility Guidelines 2.2 (WCAG 2.2), defined by the Web Accessibility Initiative (WAI), part of the World Wide Web Consortium (W3C).
As for colors, we do two primary checks: accessibility and semantics.
Regarding accessibility, we refer to WCAG 2.2 criteria 1.4.3, 1.4.6, and 1.4.11 when examining the contrasts between different color combinations in our design system. We collect all the colors used in the design system and check whether or not they respect the contrast values in their different combinations. All combinations don't need to be valid, but a low percentage of correct contrasts is often a valid indicator of possible accessibility issues in the design system.
As the psychology of color teaches us, each color contains a semantic meaning that allows it to communicate more than just color.
For this reason, it's essential to carefully consider how we use brand colors in the interface. In our experience, we notice how some companies use their red brand color to indicate potentially harmful interactions or actions that could result in losing users' data or work. It is best to avoid creating any unconscious negative association with the brand.
As for companies that use green as their brand color, like Vivisol, it may seem like a good idea to associate the brand color with success, but it can be unclear for users. This confusion is particularly true when brand color is also used to indicate interactivity or as a purely communicative aspect of the brand.
It is crucial to choose color semantics to allow users to discern the role of the different elements on the screen at a glance.
Often, we may need to use more than just the typical web typography tags when designing the interfaces for a digital product. While it's okay to expand and modify the typographical scale, there's a risk that it can become too complex and lose its usefulness in organizing and prioritizing textual information. To avoid this, we must simplify and rationalize the typography to maintain the information hierarchy.
Most first-era design systems assigned a typographical token to nearly every textual element of their components. For instance, a dedicated token would be assigned to the Button label and another to the Card title.
In recent years, more and more design systems, Google Material 3 above all, have started to create typographical scales that describe the hierarchical roles entrusted to the text. This classification allows us to maintain a small number of typographical styles capable of satisfying all design needs and facilitating the designer's choices.
One of the most common mistakes we have encountered in our experience is not providing a spacing scale in a design system.
Implementing a system of consistent spacing that standardizes dimensions and alignments can enhance the coherence of products, provide an easier-to-follow hierarchy of information, facilitate communication among development teams, and minimize the number of decisions designers need to make during the design process.
We usually recommend using a 4-based or 8-based scale, recognized in the literature for its flexibility and scalability. However, if we adopt a linear scale with such small base units, we may have too many values in the spacing scale. While this flexibility might initially seem helpful, the cognitive load resulting from the choice becomes more burdensome due to the minimal semantic differences between the higher scale values.
The scale we have extensively tested and found most flexible and efficient is 0, 4, 8, 12, 16, 24, 32, 40, 80, 120, and 160.
The initial values of this scale are denser and more flexible, primarily intended for the construction of components. The final values are sparser and more recognizable, suitable for managing page layout hierarchies.
Less impactful on the user but highly insidious for those working with the design system, the lack of a coherent nomenclature for tokens can seriously compromise the maintenance and evolution of a design system.
On the left, the example shows tokens whose name describes the color they represent. The token names on the right describe how those colors will be used in the interface. Both naming conventions are valid, but standardizing the names of tokens can guide future design system evolutions.
Our experience suggests that managing colors in a design system is most effective when using two groups:
This approach is highly scalable as it enables us to independently manage the number of colors in the design system and the number of tokens used to assign colors to interface elements. This method allows us to effortlessly increase the number of tokens, for instance, after creating new components, and restyle the design system theme if necessary, such as after a brand redesign or when introducing a dark theme.
Stats source: ZeroHeight's "How we document 2024" and Figma's "The future of design systems is accessible".
The design system audit for Vivisol was an in-depth analysis of its design system, particularly its foundations, which helped identify its strengths and areas where it needed further improvement.
Our audit report provided detailed insights and recommendations to Vivisol, which they can use as a guide to enhance and improve their design system. By addressing the inconsistencies and shortcomings, Vivisol can provide its users with a more accessible and user-friendly experience.
Are you searching for a reliable partner to develop your tailor-made software solution? We'd love to chat with you and learn more about your project.
