With the challenge ahead of rebuilding a product in a scalable and consistent way, with support for themes and modules shared across multiple product lines, developing a design system was the natural solution. This would ensure the optimal use of our team's capacity and the delivery of a great user experience.
Far from being a panacea, but also much more than a buzzword, Smart Reporting's design system was an answer to the complexity of the work ahead. It was rewarding to learn in an area that is still under development - especially in the field of design tokens - and to see the project gaining strength, maturity and adoption.
To see more about the design system in practice, using DS, see the Report Editor project.
Determining factors
Factor 1: Legacy system
As part of the diagnosis of version 1 of the product, it became evident that many interface elements, interactions and flows were sometimes duplicated, inconsistent or just unnecessarily cumbersome. These shortcomings, typical of a legacy system, were a product of its fast and organic development, which occurred largely without the involvement of designers. Features were added on top of others without the identification of patterns, reuse of code, or a deeper evaluation of the problems they were intended to solve. Besides giving users the impression that they were going down a rabbit hole in every click, this implementation also failed to ensure basic design principles such as hierarchy, contrast, input validation among others.
Factor 2: Product lines and integration
It was part of the new business strategy to offer different product lines to different types of customers. These lines would have some modules, services and functionalities in common. To do that, the new interface had to be dynamic enough to accommodate different configurations without compromising the user experience.
When embedded or integrated with larger systems for workflow control and imaging (RIS/PACS) such as the ones provided by GE, Siemens, and other partners, the interface should inherit colors, fonts, and other features from their design languages, making the experience as seamless as possible for physicians.
In addition, dark and light mode should be available in most cases.
Factor 3: Other design systems and frameworks
Given the very specific nature of these products, adopting or extending an existent design system was unfortunately not an option that would work beyond some forms and settings screens.
Development
Inception
Often a design system emerges from contexts such as the consolidation of identified patterns, from scalability limitations – product or team – and also from the need to reflect in the product the characteristics of the brand. In our case it was no different.
As the screens and interactions of version 2 were being prototyped, tested, and gaining maturity, the components used to build them were being consolidated. Similarities and inconsistencies were identified and standards were established. The development of the design system draft occurred organically, parallel to the design and validation of the main product.
Sketch was at the time the main design tool in the company. Consequently, the entire symbol and style library was created and maintained there, making the development of new designs become more and more agile.
Front-end development
Just like the design, the development of the components and their states was organic, without a serialized handover. When it was time to create a repository and a specific package for the design system, components that had already been fully or partially created for PoCs, prototypes or early versions of the product were migrated to the new space.
The development of new components, the migration of old ones, the writing of specifications and the adoption of what was released were all done almost simultaneously. This process was not simple and smooth and required intense collaboration. However, it went very well in spite of the limitations we had between the deadlines of other deliverables.
Storybook was used for the acceptance tests for each component as the final source of truth. There, it was possible to interact with each component, change its states, theme and read the documentation, both for construction and good usage practices.
Design Tokens
Design tokens are the smallest building blocks of the design system. Properties like colors, sizes, spacing, typefaces, border radius and animation properties. These are some of the ones we can specify and reuse across multiple elements, contexts and platforms, from the most generic to the most specific applications.
Tokens are also key in communication and handover for frontend developers, since they completely eliminate noise in the interpretation of properties; color pickers, measure tools and 'Inspect' modes are no longer relevant.
At Smart Reporting, design tokens were fundamental, not only for consistency and specification, but also to support light and dark modes and to customize components for each partner in a scalable way.
Style Dictionary was configured to recursively fetch overrides on properties for each brand and for each mode. The property list of colors, sizes, fonts and other parameters is always the same, but their default values may or may not be dynamically modified depending on the partner. The JSONs of the tokens are compiled into 3 formats, the main one being the list of CSS variables and their values.
Components in React reference a (typed) object that takes the variable names as values. CSS variables are, however, dynamically loaded and replaced as static files, allowing mode switching or updating the theme on-the-fly at any time, completely independent of the application.
New design stack
Technical limitations and other communication challenges accross different stakeholders also led us to replace our design stack - Sketch, Abstract and InVision - with Figma. Key factors in this decision included: the ability to collaborate from any OS, embed designs to Jira, Storybook and Confluence, as well as the availability of features like Variants and Auto Layout, and plugins like Tokens Studio (formerly Figma Tokens).
The migration process of the libraries and design files alone deserves a whole new case study. However, the results were a set of more robust components, a better match between the variations present in the code and design, improved maintainability and the postponement - at least temporarily - of the use of specific documentation tools such as zeroheight.
