First peek of Bazaar — Bukalapak’s design system

Budi Harto Tanrim

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.

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!


When I joined OneSignal just over 6 months ago, I was a design team of one so part of my job was establishing the toolset and workflow.

I had been tinkering with Figma on and off for about a year but had resisted going all in. On my last team we were comfortable with our design stack of Sketch, InVision, Abstract, so the thought of switching to another tool, moving things across, and having the team move across, wasn’t appealing.

With a clean slate at a new company, it seemed like the perfect time to start using Figma in earnest. This is my experience so far.

My Design Tool History

First some background on the tools I’ve been using. Like a lot of us, I was originally an Adobe Photoshop guy. Photoshop 4 was my first version (shortly after Geocities) and I used it exclusively for web design for a number of years. Over the years Flash would get used as well (for awesome splash screens and such).

Adobe Photoshop 4.0
Macromedia Flash 8

I also started using Axure for prototyping when I got a bit more serious about interaction design. I tried other tools like Fireworks and Keynote for prototyping over the years, but mainly stuck with a combination of Axure for interactive prototypes and Photoshop for visual UI.

Axure RP 6
Macromedia Fireworks 8

Then some time around 2013/2014 I tried Sketch. It was a game changer. Less bloated, more cost effective, vector based, one file with multiple art-boards, symbols, plugins. How did we use Photoshop for all these years? Sketch was great for visual UI design. But it did lack the power of prototyping. Combining Sketch with InVision for prototyping made a powerful combination.

Sketch 3
InVision 2

However, there was still an issue of conflicting file changes when working on a team and where/how to store files. Abstract came along and solved the problem of version control and “where are the latest designs for X?”. Abstract became the place for storing files (making team collaboration easier), Sketch for UI design and InVision for prototyping.


Sketch, InVision and Abstract is a great combination. But those are three separate tools. Giving people access to three separate things can create a dependency on plugins (e.g. InVision Craft) that need to work seamlessly together.

? Hello Figma


When I first heard about Figma the main feature I would hear about was live collaboration. Which honestly didn’t sound that appealing to me (aside from maybe running remote workshops). But that aside it has so much more to offer.

Sharing a Figma file across Slack with the company

Figma is browser based. That means you can open it in your browser. That means there is no installation needed. That means any platform that has a browser can access it. That means design files are easily accessible by anyone.

This for me is the number one game changer with Figma. Accessibility and shareability. Design files are now accessible to everyone. Marketing, engineering, product, executives, anyone on the team. You don’t have to export and figure out a good way to send it. You don’t have to ask them to download an application or sign up for a trial.

Free To Get Started

Their generous free plan makes it easy to try and also easy for other team members to access. When you do decide to scale and have team members join for things like access to your design library, there isn’t a huge upfront cost. We work with a lot of design contractors and I can easily add/remove them to our monthly plan.


Zoom in / zoom out

I thought that with a browser based design and prototyping tool there were bound to be performance issues. Turns out this is not an issue. In fact in a lot of ways it is faster. I don’t see any lag.

Funding and Growth

Like with any new cool tool you want to make sure you don’t invest in something that is dying or won’t be around for long. Figma shouldn’t go away anytime soon. They’ve raised a lot of money and are making a lot of progress on the product.

No “Files”

Figma files

Figma files are stored in Figma so you don’t have .PSD or .Sketch files getting lost on your system, or in Drive or Dropbox. The latest and greatest is always in Figma. You can export .fig files but it’s rare that I have to do that.

All-in-One Design Stack

Figma has tools that enable UI design, illustration, prototyping, version control, feedback and developer handoff. Having one tool means no switching between applications, or exporting from one to another, or installing plugins to get something to work. It also makes budget management easier as I’m just paying for one tool and managing heads/licenses for that tool only.

Design, prototype, code functionality

Friendly Support

Figma has great and fast customer support. Typically you can find an answer to your question online but there was one time I reached out to support about some unexpected library behavior. They quickly responded with screenshots and gifs that explained the issue within the hour.

Sketch Import

Knowing that their target market is currently fully invested in Sketch, Figma has done such a great job with the Sketch import and export features. You can even copy and paste from Sketch directly into Figma.

Figma vs Sketch Differences

There aren’t a lot of differences and anything that is different I had forgotten about after a couple of weeks. Some of the more notable differences I noticed:

  • Placing images — in Figma this acts like a mask which is nice when you’re constraining an image to a certain area.
  • Frames vs Artboards — a frame is the primary object that you design within. You can have frames within frames, enabling you to set constraints and grids in child frames.
  • Symbols vs Components and Instances — components are more flexible as you can edit things in place. That being said, one of the things that confused me earlier was that it’s not always obvious where the master component is (where as Sketch auto creates the Symbols page for you).
  • Plugins — Figma just announced plugin support last week ?

How to Get Started

Watch these video tutorials. After ~1 hour going through these I felt very comfortable with Figma.

Open some freebies. See how others are doing things and copy that.

Of course it’s not the only design tool out there. It’s always worth keeping up to speed with what tools are available and the pros and cons of each.


Figma is great. Biggest differentiator is shareability. Share a URL with your team and they can see your source design file. Given it is free and doesn’t require a download, every designer should at least try it so you’re familiar with how it works. Switching from your current design stack depends on context; your team size, your budget and any contracts you’re tied to. But Figma does make it as easy as possible to make the switch.

p.s. we’re hiring designers and frontend developers