The Story Behind FIAT: DANA’s Design System
Today, design systems have been a hot topic around UI and UX practitioners in Indonesia. There are a lot of stories in Medium or podcast that shares about the benefit of having a design system. Yes, we know a design system brings a lot of benefits, but making a successful one isn’t an easy task.
Our main reason to build a design system is simply that we need consistency across our designs and to speed up the design process. Using a design system can save a lot of time so our designers can focus on the solution rather than the visual. Here’s how we in DANA build our own.
Disclaimer:
This is my first writing, so I apologize if there are many grammatical errors in it. This article is just for sharing my experience in building a design system with my colleagues. There is no right or wrong in it. Things might be worked for us, but it might be not for you.
The Problems
Oh no, we don’t have a smooth sail in building our design systems. Many problems came at our faces even at the starting point. But yeah, as people said, a smooth sea never made a skillful sailor.
The right timing
So when we kick-off the design system project, it perfectly at the same time as our app v1 launch. Imagine how our developer if they heard that we want to revamp the app because we are starting a new design system just a couple of weeks after they have done the v1 version. it will be war in our office for sure.
We need our beloved developers to make our design system a reality and no, we don’t want to have a war with them. So we must compromise in designing new components. it can’t be too far from the live version, but the most important is to be consistent across all pages.
Many sources of truth and cowboy habit
You maybe have heard a term, a single source of truth. Nope, we don’t do that here, at least before we have a design system. This v1 is built based on several design kits that overlap one and another. Design kit A has buttons, so does design kit B. Design kit B has text styles, so does design kit C. And what we do if we don’t find any suitable component for our needs? We detached them. Yep, you heard it right. It’s been like a habit for us and we even have a term for it. We call it “cowboy” (came from a cowboy in the wild wild west where they didn’t obey the rules).
A habit like this will surely kill your design system in a month after they went live. We can’t change a habit in just one night. It either needs to be trained over and over again or we need to make a system that can accept that habit while making sure that our design system will survive.
The Solutions
Here’s how we tackle our problems with our brains and tools. Anyway, we use a combination of Sketch, Abstract, and Zeplin to help us.
Identify the foundations
We agreed to identify and build the foundations first. Colors and typography are the first and second things done by us and can be used by others. We decided to use one font for titles while we use system font for the bodies and captions.
Right after that, we develop the icons and illustration library. We also implement the guidelines in these two libraries so anyone who will make a new one will have a similar result with the previous one.
Collect, adjust, and execute
So like I said before, we’re unable to create a whole new design. We need to use what we have. And yes we have so many design kits, used in dozens of Sketch files, and showed in hundreds of pages. We decided to collect some of the basic components (buttons, inputs, etc) and compile it into a single library. We also do some adjustments into the components so it will feel similar across all pages.
We use the atomic design approach to build our component library. It will make our designers easier to find suitable components for their needs. So now, we have 5 libraries:
- Color library
- Typography library
- Icon library
- Illustration library
- Component library
We put all of those libraries in one Abstract project and linked it to every active project. We also upload a style guide in Zeplin so the handover between us to devs will be easier. We also have a communication guideline like the tone of voice and writing principles used by our UX copywriters.
UI audits is a must
When the design system is ready (both from the designer and devs), we started auditing our pages. It means we scan through our designs to find inconsistent components and replace it with the one in the design system. Thanks to our start-up pace and culture, we often don’t need to audit a feature because it will be upgraded to the new version, and this new version can use the design system components.
We also implement UI audit before launching a feature so we can assure the live version will have a similar UI with our design. We inform our PMs, devs, and other stakeholders to take this thing seriously.
Let it grow
To slowly change our “cowboy” habit, we implement leveling in our design system. It means designers, can build their components and use it for their purposes as long it not violated the basic foundations (colors, typography, and spacing) and put it in their local project files or their Abstract project if they use it in multiple files. There are 3 levels in our design system:
- Global
The single source of truth for basic foundations like colors, typography, icons, illustrations, basic components, and communication guidelines. This design system applies to all design files. - Project
It’s like a template used in multiple design files with similar UI. For example, UI in internet biller and telephone biller has a similar component that used together but this component is not widely used enough to be put into the global level. - Local
If you using Sketch, you must be familiar with Symbols in your design files. It only used in a single file, not sharing similar use cases with pages in other design files. Usually, we use this to solve unique UI problems. For example, I need a custom widget for the DANA Surprize entry point in Pocket. It only used there, therefore we don’t need to put it at the global or project level.
A component doesn’t always stay at their level. They can climb up if necessary. Even if they need to skip a level. This flexibility makes our design system stronger to survive.
Obey a simple rule
We suggest our designers to always obey the consistency-over-personal-preference rule. Don’t reinvent the wheel if the basic component can solve it. Only craft a new component if the one from the global and project level doesn’t help you.
The Result
Right now, we can get near our goal to deliver consistency across our pages and ship design faster by implementing the design system. Designers now accustomed to using it. The “cowboy” things are now rarely found.
And yes we know, it’s not perfect, and it was built not to be perfect, but to be grown by us.
As the writer, I want to say kudos to all of my colleagues who participated in building FIAT. Gun, Dyda, Vara, Elvira, Bima, Kaleb, Nando, Kennyzi, Krisnandi, Akbar, Jefry, and others who help us indirectly. There will be no FIAT without you guys!
