Empowering the product growth with a Design System(s) means that the Design System has to be developed, maintained, shared and used.
Very often I stumbled on business environments with several Design Systems, Design Languages, User Interface Showcases, Pattern Libraries and User Interface Collection and each of them was claiming to be the single source of truth. Every Design System was claiming to cover the most important business requirements and use cases.
Especially in the Fintech world, we have plenty of options when it comes to design a pattern to solve a need/problem. Developing a design system is a great idea to share a tool that allows to:
- gain consistency across the family of products
- optimize the collaboration between product people, designers and engineers
- boost the delivery process
Once we clarified the value of building up a design system we should also define the Key Performance Indicators (KPIs) to measure it:
- Scale good standards
- Build-in accessibility
- Unify component style
Said that it’s a matter of fact that even with such bold preconditions, sometimes, the outcome is that the final products are not consistent with the examples/templates provided within the design systems.
What are the reasons why the final product is not 100% mirroring the design system?
Here I’ve collected some of the most frequent User eXperience (UX) and User Interface (UI) gaps:
- navigation patterns – even by investing a lot of effort into documenting all the navigation patterns, is not easy to provide the full amount of options. A good compromise is to define the main options such as primary navigation (the main section fo the site/app) and sub-navigation patterns (how to go back and forth between pages and sections)
- multiple font-size values – for instance, we can face different sizes for the same content-type navigation links such “back to…” and “go to…“
- font-weight values – for instance, the unwinnable battle between the rendered code VS the accessibility. The tag “strong” is the only solution to render the text as “bold”
- components and widgets positions – for instance, the toolbar to execute the actions related to a selection within a table. Once we define the position, both on the top or on the bottom of the table we have to figure out how the use-cases where this component can be delivered (eg in a dialog)
- widgets default status – when we define the guidelines for the “select” we have to figure out how to provide a consistent and valuable UX for this widget, for instance when the “placeholder” is needed and when the “default value” is needed. We have to define a clear set of rules to allow our stakeholders to understand how to develop these widgets
- icons – most of the times the icons are provided by an icon-font (eg Font Awesome), this approach costs an effort to be maintained and developed according to the product needs. In terms of time, is necessary to establish a workflow that covers the icon design phase and its own implementation as part of the icon-font
The tool I’ve found extremely helpful and powerful to drastically solve these issues is the user observation
Exactly!
As for all the products, the best way to improve your brand new design system is to ask for feedback and observe humans interacting with it.
Just book some time to observe how the developers are using your design system, where they get lost, what they like the most and where they see room for improvements.
I’m sure that as soon as you will observe people interacting with your widgets and components you’ll notice how to reduce the friction