Scaling recommendations to help Kindle customers find their next great read.

Role: UX designer
Team: 1 design tech, 1 design system lead, 1 PM, 2 TPMs, 20 engineers, 2 QA, and a huge number of stakeholders across the Books org
Surfaces: Desktop and mobile browser, desktop and mobile apps, Kindle e-reader

The Books org wanted to build a card pattern library to increase feature ship velocity and allow for personalized recommendation rankings across all 12+ Books/Kindle surfaces.

The goal: Build a card pattern library for the Books org, biasing towards speed, scale, and consistency

Post-purchase thank you page with card that recommends following the author

Parts of the Kindle experience—from discovery to reading—on different surfaces

Context

Background

If a Books team wanted to ship a recommendation card, it would take about 6-7 weeks of dev work per surface, per marketplace.

This one-off work would also often create design inconsistencies, because it was built by a different designer and engineering team each time, working off of very little documentation and an outdated design library.*

*Talking to other designers in our studio, I found that the process of creating a new recommendation card typically involved taking screenshots of existing CX and practicing “the Sketch pixel match”.

Problem

How might we create a card pattern library that achieves both design consistency (between cards and cross surfaces) and flexibility (to scale for different types of recommendations)?

Challenges

Scope / complexity of Books business

The card pattern library had to work for every one of Kindle’s 12+ surfaces, 13+ international marketplaces, and 3 subsidiaries (Audible, Goodreads, and comiXology).

It had to account for all types of Books content, regardless of format, and eventually scale to the use cases of a countless number of ever-changing workstreams/initiatives across directors.

Surfaces: Cards would appear many pages along the entire browse-to-purchase journey within:

  • multiple generations of Kindle e-reader devices

  • Kindle app (available for iOS, Android, Mac, PC)

  • Kindle store (available on the Amazon app and browsers)

Subsidaries: Cards would have to incorporate programs and content types from throughout the Kindle org and 3 subsidiaries:

  • Audiobook content from Audible

  • Curative recommendations from Goodreads

  • Comics and manga from comiXology

Process

Design

To recommend the next book in a series, I fit in over 12 different pieces of metadata*, each with their unique variations and constraints depending on program, content type, surface, marketplace, and other factors.

*The standard set of metadata included 1) card name, 2) program/status badging, 3) cover image, 4) book title, 5) series details, 6) author(s), 7) reviews and ratings, 8) edition, 9) price, 10) call-to-action, 11) legal text, and 12) footer action.

Cards for ordered series, unordered series, and comic/manga series

Call to actions for books with different ownership status and books that belong to a subscription

“Hero” cards could act as wayfinding cards for popular links in the Kindle store navigation.

I worked with 7 high-traffic Books programs to create cards, including visual asset creation and copywriting for teams who had no assets or design resources.

Examples of wayfinding card types: though there is no metadata, the the image needs to adapt across the dimensions of all surfaces and orientations

By following an author, customers could get new release updates, special offers, and improved recommendations.

Variations of the author follow card existed across many surfaces and marketplaces, so I tracked down all the variations and created one consistent, scalable format.

Like other cards, author follow had to work across many surfaces, marketplaces, and use cases (like multiple authors).

I worked closely with my engineering team to fix accessibility issues such as dynamic font scaling and tap target size.

We discovered during handoff that the team didn’t have the resources to launch with a fully responsive grid, so I had to create interim manual solutions. Our P0 cards had to work at wildly different widths.

Desktop had a fixed, 3-column grid that had to work at a wide range of screen widths

Future

Explorations

I noticed several popular widgets used across marketplaces in a wide range of patterns.

For instance, each marketplace had a unique way of displaying genres, ranging from book covers to icons to text only. Before transitioning off of the project, I shared explorations for a possible next phase of recommendation cards.

Different ways to capture customer interest about books that have inspired TV shows or movies

Taking the hodgepodge of designs across international marketplaces for category-driven browsing and proposing a card pattern that dynamically populates both the categories (e.g. top genres, price) and the top titles within each category

Outcomes

I launched first 3 design patterns of the Books card library, combining personalized recommendations with surface-specific UI and ranking for a personalized, delightful, and engaging books experience.

I also launched the first redesign to the Thank You Page in 8+ years, including 3 interim* card patterns to test the page as the first Books cards-powered surface.

Redesigned Books post-purchase Thank You Page with the Next in series, Author follow, and Wayfinding hero card patterns.

*Several recommendations on the Thank You Page couldn’t be incorporated into the backend logic due to tech constraints, but so we “wrapped” them into a card container for visual consistency. For all UX intents and purposes, these interim cards were subject to the same requirements and constraints.


Have any questions?

Contact me for the full, detailed case study