Tri Nguyen

Introduction

Joining from the start, as a solo designer in a brand new organization, you know the drill. You have to wear multiple hats. Once you have more designers, you have to learn how to work with each other to create consistent output. I started seeing the need of a design system when our team has 3 members (me plus 2 other designers).

Due to the urge of an early startup, things got messy really fast, we started having different perspectives on spacing, font-size, primary colors, grayscale… countless debates about these. Nightmare also knocked in when we code our design (we didn’t have any front-end engineer back then), even with careful code review, we still end up having different hex code of a blue, different variant of a secondary button,… we even had different ways of naming css classes. We couldn’t move faster because of this.

I told the guys: “Guys, this need to stop. Let’s build something we can together reuse and scale as our product grows”. Suffered enough, they agreed. And we started discussing on what will be a good color scheme, what will be in our UI Kit, how to structure our CSS folder, how we naming thing…

ACL 1 is released

ACL1 was quite useful. With the Sketch file contains all the UI elements (yes, UI kit is a more common name), it helps us to work faster and more consistent. That's the main principle we had. Coding is now easier with naming convention and pre-defined classes for the same element we have on sketch. We wanted the element on web browser to look exactly like what we designed on Sketch. Pixel perfection syndrome, you name it.

We were pretty proud of our work back then. Our engineers were quite impressed with our primitive front-end works.

Contributions

• Plan on the direction of the project: what will be in there, structure, hierarchy, colors,...
• Set up working process for other team mate to join in: how to update the shared sketch file, how to do pull request and code review, keep tracking of issues on Github.
• Thanks to Cong Pham for working mainly on the UI and listened to my ideas. Thanks to Leo for building a great form component (whoever makes a design system for these form fields will understand how complicated they are).

The birth of ACL 2

We’re quite happy for awhile. Then the company grows, more designers and engineers joined. With ACL1, whenever we design a new screen, we still have to prepare html structure and add some custom css to layout the thing. I know we can be faster if more things can be reused. Now that we have a dedicated front-end team, it’s not hard to convince them to build a robust system because they already see the benefit we brought in before: to keep the UI consistent and to work faster for them.

What i didn’t satisfy with ACL1 was, it doesn’t have much character and no concrete principles back. It was a quick solution to unify us and heading toward a better interface.

Until 2017, we have 5 designers and 5 products to work on. Tons of work. We’re really close to launch our platform and don’t want to lower down our quality, i wanted the UI to look better. While the guys already have their hands busy, as a leader, you can’t always force people to do this and that. If you want the best quality of work, you have to make sure they understand you clearly. And if they don’t have time to listen to you, you have to show them what you want. So i spent part of my working time to help elevate the ACL and having my designers to be the QAs. I also had the support from front-end team to put more complex elements/components to our library.

We transitioned into ACL2.

ACL2's tremendous update is mostly about layer styles and text styles restructuring, provides designers an easier way to make mockup. Add in a layer, pick a style and you're done, no repeative clickings, or just choose predefined symbols with overridable values. Same thing happen. We also had better documentation and principles to back the system.

Snapshot of how i explain the updates to other designers

Read more about it here

I gave a techtalk to convince engineers this is a thing worth building. Together.

View on Google Slides

With front-end team joining the force, we let them take care of the code themselves as long as it's a 1:1 map with what we have in acl design.

Visit anduin.design

Abstract does help a lot to manage the shared works. We avoid lots of mismatched between updates

Wrapping up

ACL2 carries the same purpose as ACL1, that is to be a single source of how we communicate our interface to users. What i learn form working on a design system were:

• You should avoid to be trapped into the premature perfection. Live with the undone and keep tweaking it.
• There's no done done when designing a design system.
• The more you can make design:code a 1:1 map, the more you have better output. User will use the end product anyway.
• Documentation is a living things too. Make sure you can quickly update it.
• Keep observing for things that can be a symbol or component