Commerce Cards: Part 2

If you haven’t yet, read Part 1: Introducing Commerce Cards.

Cards have become a fundamental piece of the digital interface. Users have become familiar with the actions and behaviors associated with this popular way to display information. However, these cards only serve one function. Tinder’s cards display profile information and allow the user to tap and see more details. Google’s cards show a preview of data and keep the focus on one individual item or task. Recently Pinterest added the ability to “buy” on a few of their product cards but the user can’t directly interact until viewing the next screen.

From left to right: Tinder’s profile cards, Google’s data cards, and Pinterest’s buy cards.

Button’s Commerce Cards natively present actions and inventory, provided by a partner’s application, inside of the original app. Users get a preview of what’s available and can make a more informed decision before deeplinking into the recipient application.

In our last post, we highlighted the process used to dissect inventory, determine which components to show, and how those pieces were filled by partners’ APIs. The Un-Grouped Commerce Cards did an excellent job at showing inventory but it was limited to one view level. What if a partner wanted to show all reservations for a given night or all of the menu items from a restaurant? Displaying all of this in one scrollable vertical list would be cumbersome and a poor user experience.

This card would have the user scrolling until next Wednesday, but nobody has time for that. We’ve got meatballs to eat!

Introducing Groups

Groups are the foundation of Grouped Commerce Cards. They enable a partner to add another level of hierarchy in the card and surface more items for the end user. Groups are determined by the context gained from the screen where the Button is located. For example, if the Button is on a screen with numerous restaurants or a city page — the items (restaurants) would be grouped by cuisine. However if the Button is on a specific restaurant’s screen, the items would be dishes and be grouped by category like appetizers, pastas, and pizzas.

Grouped Commerce Cards changes based on the content of the screen that hosts the Button.

Just like our Un-Grouped Commerce Cards, the system scales regardless of vertical, inventory type, and APIs. Below are cards for Ticketmaster, Airbnb, Groupon, and more.

A showcase of a few Grouped Commerce Cards from select Button partners.

As cards interfaces become more popular, the interaction and expectations of what a card can do will change. Grouped Commerce Cards have already started this with on-card swipe. As a new interaction, it was necessary for us to teach users the behavior. We accomplished this by using pagination dots for iOS and tab sliders for Android.

Opentable’s Grouped Commerce Cards on Android and iOS.

Grouped and Un-Grouped Commerce Cards cover a wide variety of inventory use cases in a seemingly endless number of verticals, but design isn’t problem solving — it’s problem moving.

Our next problem? Not all inventory should be shown in a list.


Special thanks to my partner-in-crime, fellow Button designer Nelle McDade, who played a massive role in designing the commerce cards and all of our products.

Missed our first post? Check out Introducing Commerce Cards.