Commerce Cards
More and more, we’re using apps to facilitate real world actions. Our smartphones are becoming bridges between our personal wants and needs and the physical world. Button is connecting the growing app economy to help users discover their next action, and help mobile businesses grow.
When we launched our first product, Actions, the user flow looked like this.
A user tapped an Action in the Publisher app, like “Ride there with Uber” and was deeplinked into the Merchant app. Contextual information, destination in this case, was stored and then populated once the user arrived in the Merchant app creating a more seamless experience.
Challenge
Looking at conversion data, we noticed that this flow worked well for users who recognized the Merchants, but failed to attract new users. Since both Button and its Publishers earn revenue from app installs, we needed to get new users to engage.
Goal #1
Help people understand what this action does and why it matters now.
Additionally, this flow didn’t excite Publishers who already had partnerships or integrations with our Merchants. We struggled to answer why our third-party integration was better than going directly to the Merchant. Third-party integrations were, and often are still, considered risky and expensive.
Goal #2
Enhance the existing deep link experience and provide more value to the Publisher.
Install Cards
Our first approach was to look to the physical world at what types of experiences people used to help others learn about new services. After brainstorming we arrived at gift cards. Gift cards use a monetary incentive, branding, education about the service, and one action, redeem. Could we use those same principles to accomplish our goals?
I put together lots of iterations playing with levers like including Button branding, hierarchy of elements, and how to represent the Merchant’s brand. External user testing showed that people didn’t care about Button and that showing another logo only caused confusion. It also gave us confidence that putting the Merchant identity (app icon, name, description) first let new users remember what the service provided.
We rolled these Install Cards out to an early Publisher, Resy, in their Uber integration. Install rates improved when compared to the non-Install Card flow. However, Install Cards failed to convince bigger Publishers to let Button take over existing integrations.
:white_check_mark: Help people understand what this action does and why it matters now.
:x: Enhance the existing deep link experience and provide more value to the Publisher.
Back to the Whiteboard
After our first solution failed to accomplish the second goal, we went back to the whiteboard. Our solution was going to be constrained by the information available from partners. When we created Install Cards, we had begun to research our Merchants’ APIs and a large part of what was provided dealt with inventory. That made sense as any time we talk about buying goods or services there’s a requirement of inventory.
To fully understand the complexity of inventory, we had to deconstruct it into single components. Each component would, in time, become fields to be populated by Merchant partners’ API endpoints. We started by identifying the “lowest common denominator” of inventory.
What do hotel rooms, ride sharing, food delivery, and restaurant reservations all have in common?
It’d be easy to design a different category for each use case but as startups have limited time and resources, we needed a scalable solution that would work for every type of Merchant.
We recognized an overlap early in the process. Venues, times, and categories can be both items and qualifiers. Times, locations, and price can be qualifiers and quantifiers. Button assists its partners in creating their commerce cards — helping select the ideal structure of data. However, Commerce Card configuration is available in our dashboard for Publishers who want a custom setup.
Static Commerce Card
The Static Commerce Card is the foundational interface for displaying in-app actions from the Merchant in a Publisher’s app or website. Below is an example of how the data can be configured to correspond with different inventory components.
Notice that with the Airbnb Commerce Cards, the qualifier can be changed from location to a description of the item. This is selected by the partner and provides us the opportunity to test how the content surfaced affects user behavior. An existing Airbnb user might convert better knowing the location where somebody who’s unfamiliar with Airbnb might appreciate the description of each type of accommodation.
Depth is another interesting aspect of the Commerce Card. Here, an “Item” isn’t an individual property but rather a category of properties. Due to this, we can’t show price and instead use the icons provided by Airbnb to represent each type of accommodation. When a user selects one of the list items, they’ll land inside of the Airbnb app on a search results page filtered to that particular property type and location.
In the future if Airbnb wants to surface individual properties inside of the Commerce Card, that’s possible with our design system.
Dynamic Commerce Card
Static 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.
Groups are the foundation of Dynamic 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, pasta, and pizzas.
Here are two examples of how the Merchant’s API and location of the Button determines what information is displayed in the Commerce Card.
We tested several iterations of the Dynamic Commerce Card with both new and existing Button users. In almost all of our tests, users were tapping the “See more” button on the bottom of the card. It took me longer than it should to realize that using a bold color when everything else was neutral encouraged this behavior.
As a new interaction, it was necessary for us to teach users the behavior. We used familiar system-level elements, pagination dots for iOS and tab sliders for Android to help lessen the learning curve.
Just like Static Commerce Cards, the system scales regardless of vertical, inventory type, and APIs. Below are cards for Ticketmaster, Airbnb, Groupon, and more.
Static and Dynamic Commerce Cards cover a wide variety of inventory use cases in a seemingly endless number of verticals, but as Frank Chimero said in, “The Shape of Design,” “Design isn’t problem solving — it’s problem moving.” Sometimes inventory shouldn’t be shown in a list.
“Design isn’t problem solving — it’s problem moving.”
-Frank Chimero, The Shape of Design
Product Commerce Cards
With the signing of key retailers like Amazon, Jet, and Walmart, our team was tasked with creating a familiar shopping experience inside of Publisher apps.
Doing research, we recognized a few “best practices” from leading retail apps and websites to include in.
- Focus on the product’s image with an option to display multiple images
- There’s often two qualifiers (rating and # of ratings)
- Optional text for qualifier (In stock, color, sizing, material)
- Secondary image as a new “proof” component (Prime, Sale, Free Delivery)
We experimented with several other experiences than just cards. One of my personal favorites was a sheet that’d slide up from the bottom of the page and would allow the user to scroll. This would give the Merchant more real estate to put item descriptions and even feature reviews. Yet, when we tested it users were confused as to which app they were in. With cards, that was never an issue as you can see the app behind it.
Launch & Customers
Our first Commerce Card featuring Uber’s ride inventory inside of the Foursquare app launched on March 15, 2015. Since then, dozens of the largest mobile merchants have used Commerce Cards to distribute their inventory across apps and website like Huffington Post, BuzzFeed, and more.
Results
Commerce Cards were a great success for Button. They helped people understand the Merchant Action and learn about their next favorite app in a way that didn’t disrupt their experience. Publishers loved Commerce Cards as it felt like they were offering a new feature to their users. The additional affiliate revenue and install commissions were a nice bonus too.
Looking to the Future
While Button focuses on making mobile commerce easier, Commerce Cards could be used to preview content from a Merchant inside a Publisher. We played around with how these cards might showcase Netflix’s newest show or letting users listen to their favorite Apple Music playlist.
Thank You
Design is a team sport. The following people, along with a talented Partner Success team, brought Commerce Cards to market.
- Nelle McDade, Designer
- Siddartha Dabral, Backend Engineering
- Chris Maddern, Executive Stakeholder
- Max Bulger, Product Manager
- Wes Smith, iOS Engineer
- Sveinung Bakken, Android Engineer
