Native Commerce (in progress)




In an effort to continuously optimize and provide a seamless shopping experience for our customers, we’re integrating the shopping functionality to our apps.


About the Project

Not only are we tasked to build a native commerce experience, we’re also building a core system in both design and code with flexibility to support all the brands in the enterprise. The challenge here is to build one baseline native shopping “template” that all the brands would be able to easily leverage, while providing them with flexibility to brand the experience visually.


The Work

A significant part of the project was spent in refinement meetings to figure out how we should think about the architecture of what we’re building. In the beginning, we weren’t sure that what we wanted to build was even possible. What adds another layer of complexity here is the consideration of the different capabilities in iOS and Android. The dedicated app product team (UX, product owners, app developers, and back-end engineers) spent considerable time sketching, talking through feasibilities, referencing the basics of a system made up of components, elements, tokens, etc.


The Solution

We’re building a component-based system that’s extremely flexible within and across brands. This means that we can build this system by establishing a few component supersets, which includes all of the possible elements that make up different instances, or displays, of that component superset. One example would be what we call a multi-text superset, a component that holds all of the elements to “generate” different uses of that superset—i.e. an offer in the shopping bag, shipping address in checkout, even a product description on the product details page. By building the superset using component- and instance-level options (something that can be changed), we’re able to provide brands the flexibility to make significant changes as they wish when integrating native commerce to their branded app. And what’s even more powerful is the ability to make changes to the baseline template—and have all the changes cascade through all the apps—instead of making tedious changes across the different brand apps.

An illustration of how our component-based design system works for multiple brands.

Another noteworthy approach is the use of variables. Instead of hard-coding a typestyle for a component, for example, we assign a more generic typestyle name, such as “medium body text” instead of Helvetica, so that every brand can eventually define what each typestyle means for them. Essentially, each brand would define all of the element variables (in the vein of a style guide, but more flexible), and when applied to each component superset, all of the instances can be displayed with that particular brand’s styling.

VS styling of an instance of a component superset

PINK styling of an instance of a component superset

Next Steps

After designing and building all the component supersets, we’d then take them and transform them into page templates, which would ladder up to the entire native shopping experience in total. These component supersets are used repetitively throughout, of course, in conjunction with one-off custom components.



While this project is still in progress, I already feel incredibly proud of all of the work our team has done. Building this kind of a system was a first venture for everyone on the team, and something that we haven’t really seen anyone else do. We really spearheaded the whole project by having immense velocity and amazing communication among all the team members. We stayed curious every step of the way, learning about and improving on the shopping experience that we’re building for the apps. It’s one of the most challenging projects I’ve ever been a part of, and a hugely beneficial experience for myself and everyone on the team.