How we leveraged our lean team of passionate cross-functional partners to build the Mercari design system from the ground up.
Hi, I’m Michelle from the Product Design team at Mercari. My hope is that by showcasing our process in building our own design system, you may get some ideas or inspiration of your own. Let me start by talking a little about the background and challenges we faced before getting into the steps we went through and where we are today.
Along with our engineering partners, our product design team decided to invest in building a design system from the ground up a little over a year ago. Our team had recently expanded to a team of five, and our company was growing at an unprecedented rate (Over 50 million downloads, 350,000 new listings every day). This combination of rapid product and team expansion inevitably revealed issues with the way we organized our component libraries. We quickly realized that the processes and methods which may have been sufficient for a design team of one would inevitably break down as our product and team continued to grow.
At the time, all we had in our design arsenal was a barebones branding and style guide with minimal upkeep or documentation. Oftentimes, what was labeled as a “reusable component” was in reality a piece of project component copied over to a shared Figma file titled “components” in the hopes that it could be reused elsewhere. Understandably, newer members of the team had no idea how to use this library; this style guide became more of a design “recommendation” than actual building blocks to be used in all our projects.
This culminated in a Frankenstein-like experience where designers designed at their own discretion with loose resemblance to the so-called “Mercari language”. There were no clear guidelines, and newer members of the team were supposed to share their work with an older member of the team so that they could confirm that the design is within the acceptable bounds of the “Mercari’s style”. As you can imagine, every project looked different, and even work produced by the same designer never looked exactly the same.
This struggle extended to the engineering team who were quick to realize that large and small inconsistencies in the designs created burdens for engineering in both communication and implementation costs. Engineers tirelessly coded from scratch or attempted to modify existing components to meet design specifications and increasingly grew frustrated over the lack of consistency in the screens that were delivered by the design team. Their code base expanded unnecessarily, and many of the created components were only one-offs for a particular project. Not only did this pose the problem of an inconsistent product experience for our users, but it also incurred tech debt that made it increasingly difficult for the team to maintain and scale the codebase.
Due to our shared struggle and common desire to achieve a consistent and scalable solution going forward, pitching and evangelizing the idea of our need for a design system was smooth sailing.So, with the overwhelming support from our cross-functional partners, we rolled up our sleeves and got to work.
Step 1: Forming the team
First came the question of resourcing. Even with our expanding team, due to the number of projects we had in the pipeline, our designers and engineers could not afford to have a dedicated team who could solely focus on building the design system. We are a rapidly growing company with business goals to achieve, and it wouldn’t be wise to invest in a design system at the expense of product delivery. That said, teammates across engineering and design remained determined to make this project happen and volunteered to take on the design system as a side project that everyone would contribute to.
In hindsight, what was initially a constraint became a strength: as everyone who worked on the design system was simultaneously working on different parts of the product, this allowed us to leverage the collective knowledge of the entire team and thus have a clear picture of our practical needs. As a result, we were able to avoid creating a siloed design system that was ignorant of the actual needs and use cases within our product.
Step 2: Determining the process
One of our biggest considerations while building our design system was that our product is already out in the market and is actively being used by millions of users. Considering this, our initial goal was to avoid creating a completely new product or overhaul that could potentially disrupt our user’s existing experience. Instead, we wanted to leverage, consolidate, and refine what already existed in our product. We also didn’t want to wait for the entire design system to be completed before applying it across the whole product as that would take too much time. We needed to be practical and create a strategic design system that would help the entire team while bearing results as soon as possible.
We decided to adopt an agile methodology of prioritizing, designing, developing components one at a time, and then continuously iterate on them as we move along. The components we created were pushed to production, creating a cycle of forward progress and measurable results. We bet on the idea that the more components we built, the easier it would be to implement new features — and, with this, the more validation our project would receive from various stakeholders across product, design and engineering.
Step 3: Prioritizing the work
Next, we needed to find an efficient way to prioritize our work so we weren’t wasting any opportunities or resources. Our design team conducted brainstorming sessions to collect key screens from our product, break them down into multiple components, and prioritize those components based on their importance and frequency of use. Once we identified them, we reverse engineered these components and adopted the atomic design system methodology in order to parse out what atoms or molecules needed to be created in order to form these components. From there, we were able to create a prioritized list of items that we wanted to tackle and shared it with the engineering team. This made sure that the first 20% of the design system we built would come to life in 80% of our active product use cases.
Step 4: Finding our flow: Design, iterate, handoff
As we got to work on these atoms and molecules, everyone in the design team shared their progress constantly. We met weekly to give regular updates and feedback to one another as we iterated and refined our work. We collaborated closely with one another and made sure that everything that was handed off to the engineering team had been evaluated by all product stakeholders and stress-tested on all the known use cases of that particular atom or molecule. Once we reached this stage, we would then draft out the specs and share our work with the engineering team to get their review. Only after we received approval from all our team members would we move forward and hand off the atom or molecule to be built.
Step 5: Building and documenting
After the initial handoff meeting, designers and engineers would continue to partner throughout the development process in order to make sure that the atoms and molecules we designed were implemented in the correct and intended way. Some nuances within the components were not easily captured through text and images, so it was often helpful to have follow-up conversations and an open channel of communication across the two teams. It was also an opportunity for engineers to catch any additional items or edge cases that the design team may have missed and needed to address.
At the same time, the design team would build out the master components as part of our shared Figma library so that any designer could easily use them in their individual projects. This way, our components would be truly reusable, consistent, and easily identifiable by any engineer who was looking through our design files.
Step 6: Applying everything to the existing product
The final part of this process was implementation. Considering the way that our product was built, swapping out entire components across the product in one go was not possible. Doing so would mean that an engineer needed to go through the tedious process of identifying and replacing every single instance of a component in our existing codebase. This would have taken time and resources that we did not have available to us, so we opted for an implementation strategy that was less disruptive to our team’s existing workflow: updating our components as we touched different screens as part of feature or project implementations.
Engineers had added flexibility and control over their process — they could either start feature implementation by building out the new design system component that we had available or assigning the design system task to a peer so that they can do the feature work in parallel. Alongside this, we had migration efforts going on as well. This meant that if there were old pages or features that lacked the new components, engineers could go back and refactor the code to utilize our new design system. Being pragmatic like this sped up adoption and gave us a string of early victories for the project.
Looking back, we have made a significant amount of progress with our design system efforts in the past year. There is a lot of work still to be done, but even today we are already beginning to see the fruits of our labor. Not only is there greater consistency in the work that is being produced by the design team, but it takes us significantly less time to assemble high-fidelity screens using our component library. This benefits not only our designers and engineers, but most importantly our users. The visual language across features and platforms has become more coherent, and we are able to use the time that we save to focus on raising standards of accessibility and looking more closely at user flows and micro-interactions among other things. Instead of worrying about perfecting pixels on a screen, our hands and minds are free to think about valuable ways we can improve our user’s journey throughout the entire product experience.
That being said, there were also several things that we realized we could have done better along the way. One example is how we could have better viewed our new components holistically before handing them off for development. Due to the rapid pace at which we were moving, multiple new components were always being designed at the same time, and they were oftentimes only stress-tested against our existing screens and older components. Development was also naturally a few steps behind, which meant that we never got the full picture of how our product would look like with all of the new components combined. It wasn’t until we started seeing these components surface together in projects when we realized that there were some components that may look good individually but were not optimal when combined with other components in our design system. As a result, there were a couple of instances where we had to go back into a component and iterate on it to resolve these newly discovered issues.
In retrospect, it is easy to oversimplify, and there were several U-turns and dead ends along the way which I don’t have time to cover. But all in all, these experiences were not setbacks but learnings that helped us grow and continually evolve the way we approach this project. In the same way we iterate on our design work, we continually iterate on our processes, communication, and execution to improve the workflow and efficiency of the team. We tackle challenges and celebrate our victories together as a team. No one person can take credit for the progress we’ve made so far — it was a collective effort that everyone contributed to. It truly took an entire village to make this design system possible.
We are committed to continuing on this journey to create a design system that can truly function as a valuable toolkit for all relevant stakeholders and take our product experience to the next level. It’s still a long and bumpy road ahead, but if I were to take away one learning from my experience building out the Mercari design system so far, it’s that with this small but dedicated team of passionate cross-functional partners, we can conquer mountains.
