Maida Design Language System
A richly documented design system for both mobile and web applications, created as a white label solution, capable to adapt to different brand identities and products, while aiming to remain clean and clear even with heavy density of information.
Company Maida Health
Project date June/2019 - April/2020
Role Head of UX, UI/UX Designer, in a team of 4 designers
Problem
In an expanding healthtech company that introduced design later in its lifespan, mature products were in need of consistency in experience, interfaces and corporate identity, while serving B2B clients which required white label solutions and had varied end users.
Solution
To unify the experience across products, we proposed the creation of a proprietary design system, to guide the future developments and enable the restructuring of existing systems.
Extensive studies and benchmarks were carried out to understand the concepts behind a working design system and define the baseline for the state-of-the-art in the subject, along with practices such as Design sprints and Design thinking to reach a better grasp of the problems that we had to solve with this solution; all while mediating support for the project with the board.
Defining the problem
As a result of our research, we have reached pain points that our design system had to solve:
Accessible ecosystem - As a "product, serving products" its primary use is to be consumed by others (designers, devs, marketing), and be an easily accessible source of truth that anyone could tap into, enabling the creation of products sharing the same experience and visual identity.
Promote communication - It must solve problems in communication, providing a shared language between developers and designers and allowing them to work together.
Everyone is invited - There is a diversity of personas involved. While it is a challenge, it is also a feature – If any solution is too complex, make it simple, so it can serve everyone.
White label - Customization is expected to accommodate our clients' branding.
Pictured: one of the design sprints we performed to define our challenge better.
Deliverables
We aimed for a modular, reusable structure for both designers and developers, and this structure must be easily accessible and consumed. Thus, our delivery artifacts would be as follows:
-
Pattern and component design library;
-
Reusable frontend frameworks;
-
Complete and clear design and frontend documentation, for all environments (Web and Mobile).
Some examples of the design deliverables are shown below:
Tools
-
Early in the process the design team switched to Figma (from Sketch), for ease of collaboration and perceived more robust tools.
-
Developers in the project decided to go on using Angular for web, and Flutter for mobile, aiming for multi-platforming.
-
Components and development documentation would be consolidated in Storybook.
MVP
Since the project evolved from previously created material, the definition of our Minimum Viable Product came from an intersection of what was the bare minimum needed, what was already done and the estimated effort to develop needed custom elements.
Documenting
If we want real people to actually use this, we must create a documentation structure as easy to read as possible.
We divided the documentation in 3 main sections, as follows:
Principles
This section states the driving purposes, values and objectives of the design system, describing the philosophy, personality, and how it communicates with the user.
Our tenets are:
Include everyone - Consider white collars and blue shirts. Make experience easy for them all.
Plan. Create. Iterate - Create based in theory and intent. Evolve when necessary.
Clear and accessible information - Information takes the front seat.
Permanent construction - if it is to evolve, everything can change, even this manifesto.
Guidelines
This section goes about the fundamental rules that we will use to create products in our Design System – Patterns for creating, best practices and defining our identity.
-
Documentation - How to write down pages on the system;
-
Terminology - Common jargon used throughout the documentation;
-
Naming - Naming conventions and patterns be shared between design and development;
-
Measuring systems - Clarifications on the use of Pixels and REMs;
-
Grids, Hierarchy and Spacing - How to spatially construct and place elements;
-
Typography - Font family and variations;
-
Color - Our two-color system, color variations and color uses;
-
Shape patterns - Usual shapes and effects applied on components.
Press any of the images to see more details.
Elements, components, organisms and templates
The last section is dedicated to the tangible parts of our design system, describing how to construct, which patterns to use, and guidelines on how to use them.
While we put these parts together for ease of use, internally we differentiate them like this:
Elements - Generic terminology for tangible objects;
Components - The basic building blocks of our system;
Organisms - Complex elements, usually containing a group of other components;
Templates - Mockups for frequently used pages.
While this classification is different from the one described in Brad Frost's Atomic Design, we agreed that following this format is easier to understand, making our work easier.
An element documentation will usually include:
Definition - A quick explanation of the intent of the element;
Naming - Unique identification according to the naming standard;
Anatomy - Construction and responsive behavior;
Options - context-specific variants;
Interaction - How the element changes when manipulated;
Use guide and best practices - How to best apply the element;
Checklist - Quality assurance test;
Version - Changes to the element;
Press any of the images to see more details.
Workflow: the golden path
-
All work starts the in the design team;
-
Define tasks to be done and assign to team;
-
Before starting, some research and benchmarking;
-
First prototype and discussions with the team. Iterate when needed;
-
Documentation, following our document guidelines;
-
Hand over to Frontend development for coding, implementation and documentation. Discuss with design team to resolve any problems and iterate when needed.
Results
Unity and flexibility
New products were adopting our Design system and adapting when branding demanded. We reached our modular build objective, as our system provides components made of patterns defined by our fundamental guidelines.
Speed
In the 3rd development sprint, a login screen could be coded in under 30 minutes, versus an estimate of 12 hours without our system, according to the developer. Also, a complex telemedicine project starting from scratch reached market in just 5 months, with help of our Design system.
Costs and revenue
Faster development means cheaper development, as it means resources saved or efficiently spent. Also, reaching market earlier start making money earlier, as shown by our telemedicine example.
Challenges & Next steps
Life in the fast lane - As a small team, we frequently would be creating and applying the system in parallel. To our advantage, that meant we could test and iterate right away, but with limited time to evaluate a problem and validate the solution.
Maintenance - It was hard to track constant changes, and to decide what should and should not be added to the documentation. To mitigate this, governance rules were created to define how the system would be updated.
Lack of testing - Due to our small team, when on a crossroads, we would have a team discussion and try to pick the better option, publish it and let the test happen in the wild, as we were not afforded the time for testing.
Design Tokens - Most characteristics in code are accessed via variables and tokens in Storybook, but implementation still depends on a developer. Designer tokens maintained by the design team were not implemented.
Evangelization - Getting everyone onboard certainly is one of the biggest challenges of proposing a design system. Belief and adherence to the project was kept by the shown results achieved by using our design system.
Supervising coding and the choice of framework - We had trouble supervising code and assuring its modularity. This was solved when we managed to appoint a dedicated front end developer to the product. And, in hindsight, we would reevaluate the choice of framework, considering how much better we understand the challenges now, and how hard it is to find skilled Angular and Flutter developers.