How it all started
In the beginning, there was only chaos…
Well, it wasn’t that bad, actually. 😊
Early last year, I started working on a huge project for a financial company. They had a niche web application that was big & complex, with a lot of sections and managing thousands of documents. Understandably, a lot of visual components were duplicated, looking similar but not the same, or having different styles for the same popup or button in different parts of the app.
When I joined the project, there was only one UX designer, which was already great as before there were no designers at all… The Product Owners simply used to draft some quick designs on PowerPoint or use screenshots with a lot of notes. They would explained the new features directly to the developers, sometimes without clear directions and disregarding guidelines on look & feel.
Selling the Design System to the client
It was clear for the UX team that in an application of this size having “one central source of truth” was imperative. The lead designer then prepared an awesome presentation for the managers at the client company, explaining what a Design System was and how it could help. He said that this “source of truth” will document everything, not only styling but also behaviors, new features, etc.
Luckily for us, the client said YES! I suspect that, besides our Lead being pretty convincing, they were also already aware of the many inconsistencies appearing across the app.
Building the Team
Once we had gotten the green light from the client, it was time to build the core team that was going to work on the Design System.
At the time, we were a two-people design team: the lead & me. After a while, another senior designer entered the team. While the other designers were focused on some new projects inside the app, I was in charge of building and maintaining the new design system.
We worked on close collaboration, consensing & validating the components. All designers could also build some components when they had the time.
Finally, we also teamed-up with the client-side product owner; she was in charge of validating the new components & communicating the design system within the organization.
First, some research!
Before starting to work on the Design System, we did several interviews with Product Owners, developers & QA members to discover how they were documenting at the time and what they thought a design system could help them to do.
We continued with an inventory of all the visual components in the application and where & how they were used. To define what a component was, we followed Atomic Design principles: Atoms, Molecules, Organisms, and Templates.
Building the Design System: our Sketch Library
Each audited component was studied and refined within the Design System team. Then, it was carefully documented in a single Sketch file that we could link to other files as a library. All the main components were there: from buttons, tabs & tooltips to popups and table rows, including also icons, colors, and font styles.
Launching the Design System
Ready to Launch! With the library then ready, we built a CMS website where the team could check the different components. The website included documentation & recommendations regarding styling, usage, spacing, and more.
The details of each component could also be found in a Zeplin library. For the components that had their counterpart in the React repository, we included links to each one in Storybook.
The website also contained technical documentation for developer’s usage, such as environments, coding best practices, and more.
But then… the decline started
With the Design System updated & launched, it seemed that we have gotten our happy ending… but then, several things happened.
First, some designers left the company. Then, some new & high priority projects started. There was much less time & resources, and it was clear that the design system was not a priority for the client. Even if the designers continued to use it & somewhat maintain it, the developers did not care about it and didn’t really check it or use it. The same thing happened with the QA team and the Product Owners. The design system was still there, but nobody cared…
Fast forward almost a year later, the Design System was remembered again. The design product owner from the client-side announced that there was interest in relaunching the design system, as it was part of the management goals for the current year.
The UX team was delighted and excited to work on the DS again, so we quickly came up with a relaunch roadmap.
As it was evident that the Design System was not used, we decided to investigate:
- Surveying the whole team: Product Owners, Developers, and QA.
- Performing regular meetings with some key collaborators.
- (Re)defining the tools that should be used to host the DS that everybody will like & use.
After the surveys, meetings & discussions, we confirmed that:
- Most team members didn’t use the Design System.
- Many were not aware that it even existed or where to find it!
We also discovered that the devs were not really interested in the details of the design & documentation, they just wanted to have a central code repository with the appropriate components there. It was understood that the React components should have the right styling built-in. After discussing it in the meetings, we decided to use Zeplin as the main tool for design specifications and the React repository for developers.
As there were differences between the React component and the Sketch documented version, we decided that we needed some devs hours to work on the repository and check the components.
And the story ends…
In the end, even if the client expressed interest in working on the Design System, when pushed to assign developers hours, they were not ready to allocate the needed resources … It was still not a priority for them.
…Or not? What can a UX Designer do?
Even amid this disappointing outcome, we decided to keep pushing for the Design System implementation. Its time will come! Our current action plan is to:
- Keep maintaining the Design System so it will be ready to be applied to the React components when needed.
- Document it in an easy-to-find and consume way in Zeplin (for now).
- Keep pushing to get some dev hours when and if the urgent projects are finished.
Quite a few lessons learned
It was a long rocky road… And we learned so much!
- A design system can’t survive if it’s only in the mind of the designers.The whole team must know about it and understand the benefits, whatever job they do (QA, developers, POs, Managers…)
- The Design System must be created by a multidisciplinary team and not only by designers! All areas must participate in the creation and maintenance of it, as all players have valuable inputs that designers may ignore. This will also create buy-in.
- The Design System must live in a place that’s easy to find and maintain for all members Instead of creating a new site or introducing a new tool, it may be better to add the documentation to the tools the team is already familiar with, and uses frequently: Zeplin, Jira tickets, Confluence…
- Communicate, communicate, communicate!The team must be aware of the Design System changes & updates. Use a channel they already use & trust. Be present but don’t spam!
This is the end of our story. I told you it wasn’t that bad, right? Now, tell us a bit about you! Have you experienced similar cases? What’s your story?