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 system in both design and code with flexibility to support all the brands in the enterprise. The challenge here is to essentially build one baseline native shopping “template” that all the brands would be able to easily leverage, while being visually on-brand. What adds another layer of complexity here is the consideration of the different capabilities in iOS and Android. Since this is a first venture for everyone on the team, we started by doing research for a useful reference point. Perhaps both surprisingly and unsurprisingly, we couldn’t find much helpful information online. Most design systems are built for one single brand, and even when used for multiple brands, the flexibility is quite limited.


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 even sure that what we wanted to build was even possible. A group of us (UX, product owners, app developers, and back-end engineers) spent considerable time 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 superset. One example would be what we call a horizontal product card component superset that has all of the elements to “generate” different uses of that superset—i.e. a product card that has countless different combinations of prices (regular, sale, clearance, bundle, individual, etc.). 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.

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 “text body medium” 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


While this project is still in progress, I already feel proud of all of the work that’s been done. We really spearheaded the whole project by having immense velocity and great communication among all the team members. It was one of the most challenging project I’ve ever been a part of, and it has been a hugely beneficial experience.