The AirBrush UI Kit
The AirBrush Design System Project.
Platform: iOS & Android
My Role: the only designer
Design system might not be a perfect solution for everyone, but I found it could be a lifesaver for the AirBrush team. So I started with some test bits from my side, applied them to a couple of our projects. When the component library idea was introduced to the team, the test components in our projects were being helpful already. The system saves us a huge amount of time and increased the efficiency significantly - for me, I'd say it doubled or even tripled my productivity.
The team reached to a point that both me, the designer, and the dev team were so sick of copying and pasting things over and over again when we were to release a new retouch feature in the AirBrush app. And I was, and still am, a huge fan of design systems - I just like to organize things and streamline work processes to simplify repeated jobs and save brain power for more high level jobs, so I decided to make a design system.
Here are the problems we had to solve:
A lot of copy & paste (design & engineering & even the docs)
Lack of universal, standardized in-app communication components
Inconsistent interactions that were built by different teams
Smoother and more human design-dev communications, less back and forth double checks.
More efficient design process, no more redundant copy pasting.
Why It Works for the AirBrush Team
Take a look at the screenshots of some AirBrush features below. AirBrush releases new features regularly, with consistent brand style and visual layout and interaction standards. Design templates could save the team a huge amount of time and effort. And it's way smarter and more eco-friendly than simply copy pasting designs and code each time.
Also I was doing an audit for the brand style, interaction and communication of the app then, the guidelines should be a great addition to the design system.
Figure 1: AirBrush Feature Pages
Figure 2: Feature design template in AirBrush UI Kit
Integrate the Components into Zeplin
There're plenty of great tools out there. But our team uses Zeplin, and it happened to have just released the Components feature by then, so I integrated the AirBrush components created in Sketch into Zeplin. I actually liked this combination cause Zeplin made it so easy to look at where else this symbol has been used at, and I secretly guided our developers to look at that and turn them into real components rather than "design components".
Figure 3: Used in feature in Zeplin
The Documentations & The Experience
I like making docs. I think it weighs more than the build of the component library. Because docs are communications. And it's the experience I am delivering to the team - the docs, and the components library, and the actual use of them.
Unlike the other projects, I didn't talk to the "end users" at first. I actually built something first and used them in one of our project, to pitch to them that there could be something like this to save our lives. And when asking the team members to use it and work on it with me, I talk to them a lot - I actually talk to them throughout the project, just to make sure the experience is comprehensive to its end users. Because I believe it's nothing but some broken libraries if its real end users find it not usable at all.