Rebuilt stethoscope product pages around how customers actually shop.

Stethoscope product pages for a global medical brand, where customers shop by color but had to read data tables.

My role: Lead UX designer
Team: 1 PM, 1 design lead, 1 analytics/IT partner, plus the development team
Timeline: 2026 · Feb–Jul, launched July
Platform: Web: Littmann.com product detail pages (Adobe Experience Manager) (opens in a new tab)

The short version

Problem: Customers shop for stethoscopes by color and finish, but the product pages buried those differences in dense spec tables spread across separate variant pages.
Approach: I led the UX for a selector that puts color chips, finish buttons, and a live-updating product image directly on the page, designed mobile-first.
Result: In the first 30 days after the July 2026 launch: 78% more page views per visit, a 17.7% higher Where-to-Buy click rate, and 15% less scroll depth on product pages.

Context and stakes

Littmann customers browse visually, by color, finish, and tubing. The product detail pages presented variants as table-style data spread across standalone pages. The differentiators buyers actually care about sat buried inside long product names, so comparing options at a glance was impossible. On mobile, finding the right color and finish meant endless scrolling. And “Where to Buy” only resolved once a customer had landed on an exact SKU, which most never confidently reached.

Mobile wasn’t an edge case here. It was the main case. In the quarter before launch, phones drove 78.5% of visits to Littmann.com, 1,593,678 out of 2,029,748. The worst version of the experience was the one most customers were getting, which is why the mobile layout got designed first.

An Adobe Analytics breakdown of Littmann.com visits from April 1 to June 30, 2026: 2,029,748 visits in total, split by mobile device type into Mobile Phone at 1,593,678 or 78.5%, Other at 309,233 or 15.2%, Tablet at 126,678 or 6.2%, and Media Player and Set-top Box at 88 and 60 visits, both rounding to 0.0%. — Adobe Analytics, April to June 2026, the quarter before launch. Phones were 78.5% of visits, so mobile set the constraints for the whole selector rather than inheriting a desktop layout.

Constraints

Four constraints set the shape of the solution before I drew anything. It had to be implementable inside AEM with no platform migration. It had to scale across the broader Littmann portfolio. It had to stay within business-approved scope. And every configuration had to resolve to a single Where-to-Buy destination.

Research, and the reframe

Algolia search data for Littmann.com, November 2025 through February 2026, said it plainly. The two most-searched terms across the entire site were colors: pink, with 2,902 searches, and brown, with 1,778. Seven of the top eight terms were colors. The only non-color term in that group was “stethoscope” itself, at 1,085 searches: less than half of pink’s.

Top on-site search terms · Littmann.com, Nov 2025 – Feb 2026

1 pink 2,902 searches
2 brown 1,778 searches
3 stethoscope 1,085 searches the only non-color term
4 chocolate 760 searches
5 green 454 searches
6 purple 417 searches
7 black 392 searches
8 copper 371 searches

Algolia on-site search. Customers weren't searching for the product, they were searching for a color, which is why color leads the selector as visual chips instead of sitting inside a product name or behind a dropdown.

That reframed the problem: color isn’t a spec attribute to be listed, it’s a primary buying factor, the thing customers decide on first. Everything downstream followed from that, starting with leading the selector on visual color chips rather than hiding color inside a dropdown.

I pressure-tested the interaction and URL decisions against leading e-commerce product pages, then validated the harder calls in UserTesting sessions before locking the design.

Explorations

Three directions I tried and changed.

The “see more colors” reveal started as a text link. Testers didn’t notice it and rarely clicked, so I stopped hiding colors altogether: the shipped selector shows the full tube range up front.

Reordering tube colors by availability was meant to surface what was still in stock, but it made the page jump while people were mid-decision. Benchmarking against modern e-commerce product pages pointed the same way, so I shipped a static order.

The launched version auto-selects available options to reach “Shop Now” fast. Early feedback pushed me toward a customer-led model where customers make every choice themselves, trading speed for confidence in the exact product they’ve built.

The reveal as a text link. Testers didn't notice it and rarely clicked, so the shipped selector shows every tube color up front rather than hiding any behind a reveal.

Reordering tube colors by availability made the page jump while people were choosing. Benchmarking and user testing agreed, so the shipped version keeps the order static.

The solution

A single dynamic selector, living on the product detail page. Customers browse by color, finish, and style. The sticky image carousel updates live as they build a configuration, so the connection between choice and product is never broken. Unavailable options grey out but stay clickable, so nobody hits a dead end, and the selected option carries a clear outline.

The new product page: a red Cardiology IV stethoscope with a thumbnail gallery beneath it, beside a Find your stethoscope panel where twelve tube colors sit as labelled color chips above Chestpiece Finish, Chestpiece Color and Tube Finish buttons, with Red and High Polish selected and a Shop now button below. — Drag to replace the spec table with color chips. Search data showed color was the primary buying factor, so it leads the selector instead of sitting inside a product name. View spec table full size color chips

The old product options page: seven filter dropdowns above a table listing five stethoscope variants in rows, each row a product name, product ID, tube color, chestpiece finish, chestpiece color and tube finish, with a Where to buy button under every name. — Drag to replace the spec table with color chips. Search data showed color was the primary buying factor, so it leads the selector instead of sitting inside a product name. View spec table full size color chips

The selected option carries a clear outline, so a half-built configuration always shows what has been chosen and what is still open.

On mobile the carousel is static: it doesn’t follow the scroll, though the image still updates with every choice. Tube colors lay out in a two-column swatch grid, and options wrap as tap-friendly buttons.

The selector on mobile: twelve tube colors as a two-column grid of outlined buttons, each a color dot beside its name, from Alabaster and Black down to Red and Rose Pink, followed by Chestpiece Finish, Chestpiece Color and Tube Finish as rows of wrapping pill buttons. — Tube colors lay out two-up rather than in a row, because mobile was the worst part of the old experience and got designed first.

The top of the product page on mobile: a black stethoscope in the carousel with prev and next arrows either side, a row of four thumbnails and a 1-4 of 5 counter beneath it, then the Find your stethoscope heading and the start of the two-column tube color grid. — The carousel is static on mobile. The image updates with every choice, so scrolling back to it always shows the current configuration.

Behind the scenes I converted the brand’s Pantone values to HEX so the on-screen swatches match the real product. A small detail, and the one that makes a visual selector trustworthy.

See it live on Littmann.com (opens in a new tab)

Shipping it

The hard part wasn’t the interface, it was the data behind it. Stem color, chestpiece color, and HEX values weren’t available in the product API at all, so getting the front end the attributes it needed meant coordinating across PIM, MuleSoft, and Algolia.

When a single available stem color started blocking “Shop Now,” I discovered the fix didn’t live in my design at all; it traced back to gaps in the PIM attributes feeding the Adobe data layer, so instead of hard-coding a UI workaround I scoped it out of the front end and routed it to the data team as an upstream correction. Drawing that line meant accepting that some product logic belongs in the pipeline rather than the interface, and it kept the launch on schedule instead of stalling the build to patch around bad data.

Results

The selector shipped to production in July 2026 aligned to the functional requirements: variant selection, dynamic updates, image synchronization, and Where-to-Buy integration all delivered and live. Thirty days of analytics are now in, and all three headline measures moved the way the search data said they would.

78% more page views per visit

Customers browse more products once they no longer have to sort through variants to shop.
17.7% higher Where-to-Buy click rate

Customers reach where to buy faster, and take the purchase action when they get there.
15% less scroll depth to variants

Customers no longer scroll a spec table to find the product they already had in mind.

Adobe Analytics, the first 30 days after the July 2026 launch.

I’d read those as one finding rather than three. Customers who can see color as color don’t need to scroll a table to find a variant, and not having to decode a table is what leaves them free to look at more products. The Where-to-Buy figure closes the loop: every configuration now resolves to a single destination, so a customer who has built the stethoscope they want has exactly one thing to click.

Engagement and click-through are what I can publish here. Absolute figures for this client are covered by NDA.

What I’d do differently

I optimized the first release for speed: auto-selecting available options to get customers to “Shop Now” in as few taps as possible. That was the wrong thing to optimize. Customers want confidence that they built the exact product they wanted, which is why the next version hands the choices back to them.

Let's connect

Email me LinkedIn (opens in a new tab)