Dear (none)Designer,
Welcome back to the forty-eight Design at Scale™ Newsletter – focusing on innovation and how design drives change in a large organisation or an agency.
Recently, we have been advising on a proposition focusing on a solution architecture for the design system to be integrated within a financial institution. In the combination of products and services, we often deal with telecommunication, transportation media, and fintech.
A great number of these industries are highly regulated, and therefore, having a design system that companies can communicate with an internal engineering team can become a profoundly different exercise than just creating the UI kit.
What does it mean in practice? Does Figma usually represent the design system? It operates by using tokens that are mapped into a specific architecture representing the modules organised in respective containers. This way, designers on one side of the channel can use these containers, including component elements and atoms, to create a visual design proposition in Figma.
On the other hand, the same design system stores the values in a JSON file, which is then transferred to GitHub (or BitBucket). This way, both designers and developers are looking at the exact source of truth and consuming the same data.
On the other hand, the engineering team in a fintech company consume a secure JSON file and converts it to a very basic CSS – Cascading Style Sheets that represents the latest version of the design system released to a specific date.
While updating this design system on a client site, we can push the changes to the so-called repository (REPO), and the engineering team can integrate them immediately right after the deployment.
This way, we shorten the time between the design and
development by sharing the actual value of colour, size, spacing, margin, and other specifications in the code (we call primitives), allowing us to reduce the handover by over 60%.
By reducing the time to deployment, our engineering colleagues have become defining partners of our design system, creating a solution architecture that outlines where and how these definitions will be used in the solution agreement.
Once primitives are organised in primary, secondary, and tertiary clusters for brands, the spacing-related values are distributed horizontally and vertically to inform so-called white-label modules that carry the behaviour for a specific interaction in our online or (app-based) proposition. These values also drive the components provided by the same design system, enabling our engineering colleagues to create suitable components and implement themes aligned with the preferred brand direction.
Ultimately, define a structured approach that allows both sides of this knowledge base to create additional structures, allowing them to test the components in a real environment and improve the accessibility, readability, and usability of these components.
The second step is something we call mapping, where we associate the appropriate primitive value with a wide range of components represented in a design system.
When the value is adjusted, the engineering team does not need to rebuild the entire component. They just consume a new design system release in the entire user interface update to a new look at a field.
Which brings us to the third point: branding and modes. Every company relies on multiple brands. This way, they can switch between brands and sub-brands while still using the same website structure or proposition. This flexibility allows the creation of separate branches of the design and testing them before the release.
We have become faster in deployment and have also become very efficient in designing user experiences across a variety of design propositions.
In summary, the handshake between design and development, represented by the JSON file, allows both parties to significantly improve the way of working of the connection between the engineering team and the design function while empowering business to be able to integrate the changes in a fraction of the time, regardless of the dependencies from the supporting teams.
This way, the overall efficiency that the Solution Architecture of the design system offers is approximately a 60% improvement compared to the design system that is just a best UI Kit in the town.
For more information, please visit Designa at Scale™ – GRID Magazine, where you can find additional relevant articles that explore high-performing teams, self-organising teams of 001, teams of 010, and teams of 100 that deliver the value proposition within a product-led environment.
