Imagine a design system team that gets so many questions from their colleagues about component patterns that they can’t do anything else. Yes, it sounds painful, and it used to be. This was the first challenge I noticed when I joined Diana DS. And the first question I asked myself and the design system team was:
Why is the documentation that exists not being enough?
At this point I didn't even know if that was the right question to ask. So the discovery process started. First, with a very exploratory profile. We first needed to frame our design problem. Then the plan came up.
Below we will understand what was done in each phase.
1. Empathy / Immersion
The first phase brought up a lot of problems regarding ds documentation and the ds process helping define what was the real problem and where our focus should on.
Desk research and CSD Matrix rounds
In-depth interviews and data compilation
Discoveries:
→ The documentation was confusing, a lot of information was missing and then people always ended up asking for the DS team.
→ It was not clear to what extent it is possible to customize the components.
→ The tool was also not good and intuitive (DSM).
→ Didn't have a clear organization of how the documentation was structured and that made it difficult when looking for a document.
→ It was not clear to what extent it is possible to customize the components.
→ The tool was also not good and intuitive (DSM).
→ Didn't have a clear organization of how the documentation was structured and that made it difficult when looking for a document.
→ Few visual examples.
→ The DS also wanted to evolve from a more static to a dynamic model.
→ The difficulty in finding the documentation generated many inconsistencies in the use of components.
→ Many specs missing generating a big “neighborhood rule” where things were defined only in the heads of a few.
→ The DS also wanted to evolve from a more static to a dynamic model.
→ The difficulty in finding the documentation generated many inconsistencies in the use of components.
→ Many specs missing generating a big “neighborhood rule” where things were defined only in the heads of a few.
2. Define
The definition stage was where the analysis of the results of the in-depth interviews took place and the mapping of the personas that used the ds documentation.
Personas
Two user profiles were mapped. Designers represented in Laura's persona and developers represented in Mauricio's persona.
4. Ideate
All the documentation was in DSM, Invision's design systems manager. After several analyzes of what would be available on the market and how much it would cost to develop ours, we decided to move from DSM to Zeroheight, a platform made specifically for this purpose.
Sitemap
Once we understood the architecture and constraints of Zeroheight, we were able to design our sitemap and define where should everything be.
This deliverable requires validationt but, at this point, having spare time was a luxury. Any card sorting style dynamic would take at least another week to get schedules from everyone involved and it was at this very moment that the benchmark done earlier on became most useful. We would then follow the industry standard on the main pages and structures that most met the needs mentioned by the users. As for the pages that we were not so sure where they would be in the sitemap, we decided to validate them as they were used, considering that the maintenance and versioning cost was lower than a dynamic card sorting.
Content Structure
A basic standard content structure has been defined for all components. Before, the documentation of some components was incomplete and it was not clear what contents would be found within the detail of each component. This was resolved with the structure below.
5. Build and measure
Once our architecture was define and the content structure designed, it was de moment to start migrating contents from DSM tool to Zeroheight.
The result
With everything updated and the contents equalized, the new documentation went live.
As we were updating the documentation and drawing our structure, I realized that we would need to mirror Figma's library. Some components used to be at the same frame (left) in Figma making it harder to find. I reestructured Figma's library in a way to facilitate (right) the search and don't bring much impact for whoever is already using it the way it was.
Learnings
When talking about design system and scaling design standards, it is necessary that the documentation speaks for itself and the processes of interaction with the product and the team are clear. Each company has its particularities and that is why it is so important to understand exactly for whom the documentation is being designed.
We learned so far that...
→ We should have measured before changing so we could compare before and after and today we would know exactly how big the impact of this delivery was.
→ The design system documentation is a task force that involves all roles. Code specs are just as important as design specs.
→ Understanding the structure of the platform on which you will work is fundamental for the design of the information architecture.
→ The design system documentation is a task force that involves all roles. Code specs are just as important as design specs.
→ Understanding the structure of the platform on which you will work is fundamental for the design of the information architecture.
