What I learned from 6 months leading a design system for a leading e-commerce company

First peek of Bazaar — Bukalapak’s design system

In November 2018, I joined Bukalapak. Almost immediately after, we initiated a project to develop a new design system with me as the lead. The goal was to improve our product development approach to enable our 50+ teams in the company in a more scalable and efficient way.

In June 2019, after 6 months of working, we reached our first milestone; we launched an internal design system documentation site. We call our design system Bazaar. While we silently celebrate that, we’d like to share what we’ve learned throughout this process that hopefully can be useful for you out there who going through the same adventure.

#1: Learn from the past before start on anything

Before we started developing the new system, we dug around to see if somebody else ever attempted to make a system like this in the past. We were afraid that we might be “wasting” time with this investigation, but it actually unearthed a lot of common challenges that informed our future decisions:

• No single source of truth
  Every other designers collected their own sort-of UI kit and share it in their own circle or team. This creates a lot of duplication efforts and sometimes, there are a couple of different component to solve the same design problem
• Inconsistent standard
  Most developers created their own mini component library. They did this because it made their job easier in the short term. However, this contribute into a huge inconsistency and inefficiency within our product
• PDF documentation
  Some good folks actually attempt to make a documentation in a PDF format for others to reference. Unfortunately, this was not quite successful since people are busy, they have their own deadline, and the PDF is super hard to find, like, “In which folder was that again?”

Left: Documentation on PDF format | Right: Sketch UI Kit

And so you can see that learning what others tried was not a waste of time. It helped us validate and challenge various assumptions we had going in. The key learnings were that we had to define a “single source-of-truth” that was essential by all designers as part of their day-to-day work. Additionally, we had to make designers and developers work in sync via these centralized libraries.

#2: Make the invisible works visible

In the early stage of building design system, the team will often work in the background for foundational things that cricital to get them right so that they can be built upon. Basic questions like “What is our workflow when making a component?” or “How do we give update?” or “How do we prepare ourself with the new redesign?” or “Is the mono-repo better?”

While these are important to solve, but invisible to stakeholders. With that in mind, we tried to articulate all of this in a more tangible way by documenting everything on the doc. The feedback was positive. The team started to get more trust and gain more momentum from here. Takeaway: If you’re struggling with visibility, I’d suggest to give more tangible progress and articulate them while giving updates to stakeholders.

#3: Create a workflow and articulate it

You want your team to be autonomous and empowered. As a lead, all I can do is to make sure the preparation and the strategy are clear. Then, take the step back.

Well articulated workflow will help your team to be one. Generally speaking, start by asking these questions:

• What is the primary way of working for my team?
  You can determine this through a 1 week sprint and document the overall process. Don’t forget to constantly iterate on this!
• What are common situations my team faces?
  If you watch closely, you will notice a frequent and recurring questions that occur within the team. If it’s keep coming back, you need to do something about it. Find a way to solve those situations in more intentional way; e.g. by determining key principles on how the team should make decision
• What is the definition of done?
  Due to the complexity, some tasks can end up being quite vague. Articulate the definition of done clearly to reduce uncertaininty and inefficiency.

#4: Start with centralized team to pave the foundation

Strictly speaking, this point may not always be true. However, we decided to use a centralized team model to get things moving and clear government first. In our case, we see a few benefits:

• There is a clear ownership, so there is someone to be accountable to move things forward
• The team can see a bigger picture, so when we make a decision, it is deliberately to benefit the whole organization
• The team have more time to think about small things, like standardization and how to communicate them
• People in the organization know where to go if they have issue or idea about design system

On the other hand, it comes with a cost. A few downsides you may want to consider:

• People outside of the design system team don’t always think contribute to design system is part of their job. “Yeah, it’s somebody else’s problem.” Solving this challenge requires a proper change management approach to embed it in the DNA of the company
• It’s challenging to transition from a centralized team model to more a distributed one as it is required to evolve the system
• The core team run to a risk of working in sillo, althought this can be mitigated by constantly reminding them of the big picture and prepare an environment where people can collaborate
• Potential to be a bottle-neck for the whole company if not given the proper resources

#5: Cohesive not consistent

We introduce a snowflake component. We actually embrace them! This term come from my previous colleague, when there is something off he will goes, “It feels like a snowflake experience.”

In short, snowflake component is to allow team to make their one-off component.

So I thought, well, I need to embrace this notion in our situation because there is no way the design system can accommodate the need of 20+ product lines. In the beginning, I feel like this is a counter-productive solution. However, it has to be more like a cohesive concept rather than an exact and consistent specification. Allowing teams to create their one-off component can be useful in a few situation to the team can keep moving their project forward.

The intention of design system is not to stop people from doing. Design system is exist to help people work faster. Sacrifice control and embrace chaos when necessary

To tame down the chaos, we will do an evaluation periodically to see which snowflake components can be replaced and which can be promoted as a general components.

#6: Observe, communicate, collaborate with teams

Yes, it is not as smooth as I would like it to be for now. But optimizing collaboration among teams is always a continous process.

To be honest, the people who use your system are mostly available for you to access. So, we constantly use this opportunity to talk to them and observe how they use our system. This provides us with the feedback to determine and prioritize what changes we need to implement next.

Your users, just like the users of any product, are the best source of information about your product. All you need to do is to talk and be empathetic with them!

#7: Get buy-in from other functions and work together

I have always worked under the belief that design shouldn’t only be done by designers. Everyone working on a new product or service plays a role in shaping the design!

Designer design. But a good design is almost never created by a designer working in a vacuum.

We have to work together with the other functions to not only get their buy-in, but their feedback and opinions as well. This helps shake us out of our bias and forces us to look at something from a different perspective. Pumping out designs from the “design” organization alone won’t work. Once we have conversations with other functions and align on what are the important criteria and why, we feel the distribution of design ownership starting to spread.

What’s next for us

We are very happy with what we’ve produced in these first 6 months. But for us, this is just a 10% of the whole picture and we can’t rest on our laurels! We still have a lot of work to do, but it is important to take breaks every now and then and recognize your accomplishments and how far you’ve come.

Next up: distributing the design system, continuing to develop the big picture strategy, ensuring continued operations of all the various bits and pieces of our current design system, and striving to evolve it in the right direction.

It’s impossible to have done this by myself. Credit for the talented people in Bazaar team as well. In no particular order — Dani Mahardhika, M. Ishaq Zainuddin, Dwi Karya Maha Putra, Barata Tampubolon, Ahmad Zakiy, Nurul Furqon, Laila Mauhibah, Krisbianto Cahyo Sumarto, Reza Faiz A. Rahman, Adwin Dwitaufani, Muhammad Hasby, Shellafuri Biru Mardika and Yoel Sumitro

Get in touch

You can reach me out on Twitter or via email to budi.tanrim@bukalapak.com
We are hiring for senior positions: Senior Product Designers, Senior Content Strategist, Senior iOS Developer, Senior Android Developer, and Senior Researchers to build a stronger team, further develop our human-centric approach, and better product quality at speed. Join us on this journey!