Designing a modular UI system to enable a personalized marketplace experience.

OVERVIEW

Within Mercari’s mission to create value in a global marketplace where anyone can buy and sell, I lead UX across core key product areas, one of which is Home - the most frequently visited destination of Mercari, as it is the first screen that every user sees when they open the Mercari app. In this case study, I walk through about how I approached designing with modularity in mind in order to build a UI system that can support dynamically-driven home contents towards a more personalized marketplace experience.

TIMELINE

July 2021 - Sept 2021

ROLE

Senior Product/UX Designer

METHODS & TOOLS

Content Audit, Design Systems, Information Architecture, Blockframes, UI Design

TEAM

Haga Masaki (Client Engineer & iOS Tech Lead)
Ando Keiko (Supporting Product/UX Designer)

PROBLEM

At the time of this project, Mercari’s design was still young; we did not have a proper Design System to consume; our Figma environment was only ported over from Sketch roughly a year ago, so the “Design System” was simply a Team Library consisting of Symbols carried over. Our design team simply used these to continue growing and scaling Mercari, with little time to organize what was our “design system” (dubbed DS1.5) at the time. At one point, there were over 30 shades of red buttons!

Throughout the evolution of Mercari’s Home over the last few years, many designers and many UI components have been introduced, retired, and tested. Across my areas of responsibilities (Home, Search, Seller), at best, some components consume DS1.5 where possible, but a lot of variations in the individual execution and implementation of each component feature results in an unorganized overall look & feel for the user.

OPPORTUNITY

As part of this growth, Mercari as an organization has begun a complete replatforming/rewrite of iOS, Android and Web, to include common features such as the new Design System 3.0 (DS3.0), i18n, a11y, and more, in an effort to enhance performance and extensibility, upgrade productivity and unify UX for future Mercari products and services.

Concurrently, as our product becomes smarter through improvements in machine learning algorithms, we have reached a point where content modules on Home are driven dynamically through a back-end micro-service called “Layout Content Optimizer”, which controls what components are served to each user and in what layout order.

GOAL

We needed to build and define a UI policy to ensure a consistent UX for our users across core areas of Mercari (Home, Search, Seller Home), and refactor the UI such that we could scale the experience of Home. This meant designing a more flexible variety of components, a flexible UI system, and ensuring current & future components would all be compatible. The ultimate end goal is that this Modular Home UI policy could be absorbed and supported by DS3.0 (our next generation Design System under development).

DISCOVER

Inventory Audit

In order to account for all existing UI patterns, I began by conducting an inventory audit of all components in use across Home tabs and Seller Home

As I went down the list of components, I began identifying both unique or common attributes that each of these components were built from. A lot of these components were built in a similar way, and so for consistency, I would classify them as per their DS3.0 label, so that their component family could be related easily in the future. For those components, I added a DS3.0 tag for quick reference. Completing this exercise helped me understand at a high level what commonalities all these components shared, which components held high importance (as a commonly used component), and draw any conclusions about how I might be able to define the appropriate guidelines or rules around the frequency of use of certain components.

DEFINE

A consistent UX meant a consistency in design across UI components, including attributes such as headers, fonts, position of buttons/links, etc. Also, guidelines needed to be determined in order to prevent particular elements from taking too much “importance” in weight from other neighboring components, so as not to create interest bias in our users.

So with that in mind, and base contents defined, I then began building blockframes based on the above attribute groups to better visualize the information architecture of how each individual atomic and molecular part could construct contents.

Foundation

Home components were deconstructed into molecular level parts in order to enable modular construction of contents, as necessary.

Component Types

There are two types of components: Single and Group.

Grouped Components can have a GuideLink configured at the bottom of its group, if there are additional contents available. Since Grouped Components are expected to consume more screen height than Single Components, having a GuideLink on the bottom will improve accessibility, so that users don’t need to scroll up to the SectionTitle in order to access an AssistLink.

Titles

There are two types of Titles:

Design System 3.0 - Section Title components

The specification of SectionTitle and ContentsTitle is derived from a similar component already defined by Design System 3.0, though the extend of functionality in the design system variation was insufficient for the purposes of contents on Modular Home, so the variants defined here provide the additional flexibility needed to distinguish between typographic structures, information relevance, and context fidelity.

These changes mainly include:
- Variations on text styles for Title Labels and Subtitle labels
- Optional Thumbnail Avatar specification
- Flexibility in atoms/molecule alignment of components within a Title component

Separators

In principal, Separators should be included as part a parent component, and should not be used independently. If an arrangement of a layout results in overlapping separators, the top separator of the overlapping component should be hidden in Figma

Equal weight Consistency

In order to ensure that grouped components carry approximately the same weight regardless of how they are constructed, ensure the total height between other grouped components are roughly the same height

Content Component

In principal, the type of components that can be used for Content Component are flexible, though among the audit of contents of Home, this is typically an Item Carousel or Item Grid (in some configuration).

Content Components are typically paired to a Title component to introduce context pertaining to the nature of the contents displayed in a given Content Component.

After several rounds of drafts and iterations, I began to piece together these molecule-level components using the guidelines created with generic components to verify and test whether there would be any unwanted or strange UI artifacts. Here are several examples of Grouped and Standalone components using a variety of Content components.

DESIGN

Rebuild UI parts

With this framework in place, I began to rebuild each of the generic existing UI components from an atomic-molecular level, consuming the newly established Mercari Design System’s text styles, color styles, spacing, and typography wherever possible.

Thanks to the pre-work I performed in identifying common attributes, I was able to greatly simplify the variations in the design through the process of deconstruction and reconstruction.

Streamlining the design essentially involved a lot of fixing and repairing of how each of these components were constructed - a lot of designers had a hand in creating these legacy parts before the organization switched from Sketch to Figma, so there were a lot of inconsistencies. Also, none of the parts were built with newer design techniques such as Auto Layout within Figma, or configured with constrain rules for more responsive behavior. With the individual components standardized in design, the next was to put everything together, within the guidelines of component spacing in Mercari’s Design System (I liken this part of the design process to fitting a carefully built engine into the bonnet of a car frame).

Conforming to Design System 3.0

Per the guidelines of Mercari’s Design System 3.0, general spacing between two distinct sections should be 32px in principal. In order to stick to this rule, it meant that spacers of varying sizes would need to be inserted in between Component modules, since some parts within Component modules already included some padding/spacers, which needed to be accounted for when calculating the 32px separation.

Early on during a design critique, our design team agreed that the 32px spacing rule between the Wallet Dashboard component and Banner component placement was too much, so it was agreed that we would apply an exception for the spacing guideline between the top 2 components.

DELIVER

Challenges during handover

During the handover process, I was informed by the client engineering developer that there were some challenges in realizing my designs, specifically the usage of varied spacers in between components. It turns out the implementation logic for Modular Home is designed to allow the order of the components to be configurable from the backend, so the client always needs to assume that any order of components could be received. Essentially, what that meant was from a technical perspective, we needed to treat all Content components the same, such that if there is spacing between two Content components, the same amount of spacing would need to be applied between all components.

Deep-diving with Engineering for a resolution

So with this feedback, I invited my Client Engineer to deep-dive into Figma with me as we deconstructed and dissected the design; we worked in sync to help each other understand the logic of both the Design System’s spacing guidelines as well as the Modular Home implementation logic. After some back and forth, we were able to find a solution - since Designers had made an exception to use a 16px spacer, the implementation method required the fixed spacer to be consistently 16px.

I revised each set of Standalone component and Group Component to strip out any built-in padding, such that there wouldn’t be an excess of spacing caused by the automatic 16px spacer inserted between any given order of components. This meant that some Standalone or Group components may not look correctly when viewed on their own, but when placed in Modular Home, the solution worked.

RETROSPECT

Result

While the full public release of Mercari’s redesign leveraging Design System 3.0 is still under wraps (scheduled for latter 2022), the new Mercari with Modular Home has been made available on an Early Access Program for internal employees, where we conduct dogfooding. No errors or bugs had been reported in the transition, meaning that our users have been able to continue using the same experience that they are so used to from the legacy Mercari app.

Modular Home would actually go on to be revised a few more times, as we went beyond the scope of the redesign, and began testing other candidate components from other areas of the app in anticipation for scaling. In particular, components brought over from the Home / Topics tab had some unique designs (done by another designer on my team), and so in order to accommodate and adjust for this, we worked together to revise/refactor the designs of those components slightly in order to enable compatibility with the spacing logic determined within Modular Home. We ended up updating both the spacing logic, as well as tweaking the design of those Topics-based components, enabling us to be ready for future growth experiments on the Home experience, as we draw closer and closer to public release.

Mercari’s ground-up redesign, Modular Home as described in this case study, and Mercari’s new Design System 3.0 are currently still undergoing design and development. This case study does not represent the final product, but showcases examples from several iteration cycles throughout the design process.