The inDriver design system: don’t try to leave Oymyakon
In this article, iOS developer from inDriver Alexey Kakoulin shares his experience in design system processing.
Our app is a super app with a variety of services and resources: intra-city, inter-city, and freight transportation trips, as well as courier delivery, handyman services, and many more. Separate dedicated teams are deployed to work on each service, and they are free to make decisions or consider almost any product development options.
But let’s imagine what would happen if they were given complete freedom in design. What result would we get here? Chaos (most likely). That is why we have a system design team in place, and we would like to tell you more about it. Below, our iOS developer Alexey Kakoulin talks about this in detail.
Background
Let’s assume we’ve got an abstract task, for example, to design a “Create order” button. Team 1 is tasked with this job. They get the job done, and the new button is now added. After a while, Team 2 also needs a button. They looked at Team 1 but decided to design theirs their own way. But there are also Teams 3 and 4, which looked at this situation but thought, “That’s all cool and dandy, but we’ll do that our own way.”
But since they all operate within the same application, we will get a jumbled-up mix of inconsistent design elements:
To prevent this from happening, inDriver has come up with a design system called Oymyakon in 2021. It’s named after one of the “Poles of Cold.” That area is known for severe frosts and low-temperature records, but it also boasts beautiful and unique scenery.
The name selection process was long and intense, involving several iterations. The initial efforts included a survey within the development community, but nothing useful came of it. Then we came up with the name DesignSystem, which sounded too trite and corny.
Finally, when a full-fledged team was formed, our guys conducted a company-wide poll, picked out the best suggestions, and ran the vote where Oymyakon came out as the winner.
The design system team currently consists of four mobile developers, two designers (for the web and mobile devices), a tester, and a lead responsible for dealing with the most challenging questions. All of this is part of our mobile cluster.
There is also a web cluster with a platform team that, on top of the platform tasks, works on design tasks as well. These guys supply the “building blocks” for our product teams.
What is a design system?
Everyone describes a design system in their own and different ways. One of the reports included this cool and apt description likening it to a multi-layered cake:
Because people are the essential ingredient here. Next come the processes built around people and then the components that these people create and use. All are covered with a thick layer of documentation to make it all the sweeter.
The goal of the design system team is to quickly find components, change them promptly, increase brand awareness, and bring users joy and happiness. Users are not only end-users who download the application but also the developers and designers who work with components.
Everything is divided into two components to accomplish the goals, i.e., tools and processes.
Tools
Designers draw and work in Figma as one source of truth. Figma works as a full-fledged document, complete with its own templates, design rules, and task setting examples.
Everything is automatically unloaded and synchronized with Figma. Different tools are used for different platforms. For example, Figma Export is used for iOS and Android, an open source library that is coded by an iOS specialist in Swift. This allows you to quickly make edits and participate in the open source community.
The next problem-solving tool to use is the component gallery. For mobile apps, it’s a demo app, whereas for the web, it’s Storybook. The tool allows anyone to quickly look at the components: the designer, the developer, the product manager, or the Technical Lead. The tool can be used to view the components, code samples, or to check the layout, as well as to do pixel-perfect testing, etc.
To make sure no-one accidentally damages a component, they are all covered by snapshot tests.
Of course, the team writes documentation, there’s a lot of it, and this is an important process. Few people like to do this, but when the team grows very quickly, this approach makes it much easier to further develop the company and complement the processes.
Processes
Documentation is important, and it can be classified as processes as well. But communication is even more important.
It all starts with onboarding, when a new team member first comes on board and joins the team. They are told what the design system consists of, where it’s at, where to find what you’re looking for, how to read up on a topic, as well as who to turn to for help or with questions to resolve an issue or concern.
The design system team takes an active part in internal conferences. For each platform, they are different and held once or twice a week, depending on the initiative shown by specific people concerned. There we talk about what we’ve learned, or we review previous learning to keep it from fading from memory.
Designers conduct a weekly review of layouts created. Over there, the design community reviews new candidates for addition to the design system, as well as vets and asks awkward questions. For example, if a component looks like a component from the design system, but is not taken from there for some reason. Or argues about their gizmos, the rounded corners of buttons, and what have you.
The team works in two-week sprints. Once finished, open sprint reviews are held to evaluate the results, which anyone is welcome to join and ask questions. There all participants report what they accomplished or failed to accomplish and why, as well as what difficulties they encountered along the way. If someone couldn’t make it, a video is posted in the internal chats and on the corporate portal Teammate.
Since a design system presupposes open processes, interaction between the teams is essential. Once every six months, the team gathers feedback, evaluates its performance and results, as well as draws conclusions as to whether or not it is moving in the right direction.
Is there a need for a separate design system team?
To answer this, ask yourselves these three questions:
1. How quickly are you growing? If you get to have multiple teams who have their own designer, product manager, Tech Lead, vision, and you do want them to deliver features to their users without being distracted by routine tasks, it’s worth it to give this matter plenty of thought.
2. How often do you have design changes? The design changes occur quite frequently. If you have problems replacing basic components, ponder well this question and possible solutions.
Over its 10 years in business, inDriver has gone through the redesign process three times. If the first two times it went more or less smoothly, as there was only one team and the process involved no problems, the third time was rough. As the number of teams was increasing, epic efforts were required to achieve the intended outcome.
3. Do any disputes arise between developers and designers? Sure thing, with the design system and the team in place, they will become less frequent, but they will not disappear altogether. An important point to consider: If at first the developer works for the designer, then the designer will work for the developer.
This is extremely important: If the designer has made a mistake and overlooked a layout error involving a departure from the design system, the developer can always stop by and point out the flaw. And then the designer will rework it, this really works.
A quick recap
At the end of this article, we’ll share quick insights into what’s happening to inDriver’s design system in the near future.
1. An increase in the number of shared components. By the end of the year, there will be 50 of them. Among other things, there are plans underway to use the new frameworks provided by Apple and Google, i.e., Swift UI and Compose.
2. Improving service availability. The goal is to make the application accessible to people with disabilities. Part of the screens have already been adapted, and we’re working to make sure the application is fully adapted by the end of the year.
3. Freedom of experimentation for teams. The design system is all cool and dandy, but the teams want freedom. The design system team wants to give them that, but monitoring checks need to be carried out as part of some process.
4. Another redesign campaign coming up in the offing, the fourth of its kind. We would like to add that in about six months the inDriver app will be renewed beyond recognition.
