Design system boosts efficiency up to 7* times
This article uncovers the metric of saved time that applies to Desing Systems and to many other systems built within the organization.
How well is UI code structured in your current project? How often do you clarify mockup’s edge cases with the design team? How often do you duplicate existing screens to achieve slight distinctions making the code look ornate?
I haven’t seen a better approach to unifying UI than a design system. I’ll be talking on behalf of developers because I have been working as Software Development Manager for 4 years in a team that currently maintains the design system. It is used by a group of about 100 mobile developers.
Skip to “How to do the user testing of the library?” if you know what a design system is.
A design system is a set of components and rules(including restrictions) on how to use those components to simplify project development and make UI consistent.
Essential parts of design system:
Design library — which designers use for mockups creation.
Development library — is a design library turned into code. Divided into 2 parts: Primitives and Components.
Documentation — guidelines for developers, designers. (source of consistency)
Process — helps to benefit from the design system and improve and evolve it.
Functions and perks of using design system
First of all, the design system removes a massive layer of communication between Development and Design teams. In the case of the nearly perfect design system, a designer has to provide only:
An ordered list of components with strings on it
Instructions for components with interactive elements on it
It will be enough to deliver a production-ready feature. Mockups are needed more for feature visualization on the design side and communication between the product team. The development could be done without mockups at all.
Everything from fonts and colors to behavioral patterns is documented and implemented before a feature development starts.
The design system gives us the following benefits:
Development moves way faster. Feature developers build the screens from blocks with minimum configuration.
UI does not have bugs in any configurations. Talking about product quality — it’s nearly impossible to achieve such a level of quality within limited resources. Each component autonomously handles content resize, theme, accessibility.
We got a pixel-perfect UI for the whole app or group of apps on both platforms.
Nearly minimized UI code. Without a point of synchronization, a huge project will produce duplicated non-maintainable code.
A team with a goal to provide a consistent reusable UI framework has more chances to succeed than a feature team with a goal to deliver functionality. But there are drawbacks: in order to grow and evolve together with a product, a design system requires resources that should be taken from the feature development. It could not be the central priority for a small team. The way to measure that will be covered in the topic below.
Product and Team
We develop native iOS and Android app with 1 million lines of code each. It is a SmartHome or IoT app containing lots of screens that are dedicated to a broad range of devices. They could be narrowed to a fixed set of patterns and components. At the very beginning, consistent UI for new screens was the primary goal. These days design system is handled by a team consisting of Product Designers, iOS SDEs, Android SDEs, QA, Technical Product Manager, Software Development Manager.
The design library is located in Figma now. It was moved there from Sketch about 2 years ago. Figma fits well for building such a system due to its ability to work with auto layout, similar to how developers make components.
How we started
The story started with a desire to have new mockups and UI unified. First, we got resources for such a vision. Then, we started getting positive feedback from development teams who had tried the first releases right away.
It was a success — many developers were tired of the same repeating UI code working on every new feature.
At that point, we got the first data showing us how much the library changed the performance of developers. For example, the library allowed us to estimate iOS tickets with 3–5 story points while Android took 8+ for the same work due to the absence of the library on this platform. So after that, we made an Android version.
Why design system work
Before each mockup is delivered to development, it passes a design review that guarantees its full compliance with a design system. That will ease things for the development team because all the needed components are predefined in advance. Also, developers know how to find the right one. And it works in all the boundary conditions.
As of today, our primary metric is the amount of custom UI in each team’s area. To do that, we have an automated daily report that shows the complete picture of added and removed UI code.
User testing of the library
We got a lot of positive feedback from developers(but big companies are pretty much data-driven). Typically design systems are assessed by surveys. And we did one with good results like 50% of developers think our design system saves more than 50% of their time. But we made another step forward. We organized an internal Hackathon and found out how many UI development hours we saved for the company to get more concrete results. Below, I would like to talk about developers as our library’s main clients’ group.
We asked a group of developers and designers to implement a single application screen using two approaches — with and without a design system. To make its results fair, we asked half of them to start with the first approach while the other started with the native approach. Also, the task was designed to require maximum effort from developers to get it done in time. In about 4 hours, each participant had 2 solutions and felt that the design system heavily impacted their performance.
We had 10 developers and 10 designers who participated and about 10 people from the organization side. It was an offline event, and we occupied a huge conference room for all Friday.
First of all, developers told us that time restrictions were challenging, and they do not work at such a pace in everyday routine. However, the timing had been previously tested internally on our own team, so we knew it was doable.
The design system allows writing UI code 3 times faster on average. *Some developers did it 7 times faster. Also, there were 70% fewer bugs. Also, we got one result without bugs at all, thanks to the design system.
Let’s assume that only 20% of developers’ effort is dedicated to UI. Then using the tool for monitoring added UI code, we can easily calculate how many developers’ efforts are saved.
Also, we can tag and count bugs related to UI. And estimate QA and Dev effort saved on fixing another 7 bugs for each 3 given.
With those results, we can easily justify the existence of our team.
Efficiency comes with complexity
We are trying to mitigate the complexity of having a system with automatization, onboardings, and teaching sessions. For example, the flow of adding icons into the library is pretty complex but almost automated. Moreover, our team is always accessible in dedicated iOS, Android, design slack channels. Also, efficiency depends on people’s readiness to follow the system and the system’s flexibility. While we are not always empowered to change people’s desires, adding more flexibility to the system helps speed up new features development.
Challenging the library in live scenarios was an excellent idea. Task appeared to be very inspiring and developers started to generate various new ideas. The second important goal of the Hackathon was to collect live feedback.
After all, we assessed the library and found a couple of counterintuitive interfaces. That was useful to unblur eye on some decisions. Also, we found a few gaps in documentation. Some of those interfaces were about two years in production, and only with time constraints, we reveal their limitations. Mastering a design system is a funnel, and suitable interfaces make it faster for developers to walk through. The Hackathon confirmed that developers less experienced in our design system were less effective.
The library comes along with a sample app that is actively extended. And, at some point, we exceeded the reasonable number of components that can be easily found, so the idea was to add the search into the sample app.
As a bonus, we counted builds that were performed during the Hackathon. But there was no correlation between task 1 and task 2. It appears that each developer has their own manner of building the app during development: some build it up to 50 times during each hour, some build 3–5 times at all.
Let me know if you have questions — perhaps I can cover some other topics. Every big company makes design systems in its own manner, but there are common ground and everyday challenges. So I would bring this as main takeaways:
Make the process comfortable for clients.
Verify your solution with each involved group.
Back up yourself with numbers.
Use social capital to promote the library across teams (that might be worth another article on how to onboard a company on the design system)
Thanks for reading Second Job Newsletter! Subscribe for free to receive new posts and support my work.