Dopamine Shopping UX Pattern

Overview

The dopamine shopping pattern is a UX design strategy that separates the emotionally engaging part of a purchase (browsing and selecting items) from the logistically demanding part (entering dates, times, addresses, and payment). By deferring friction until after the user has built a cart, the design maximizes engagement, perceived value, and average order size.

The pattern is well-established in product e-commerce (Glossier being a canonical example) but applies equally — and perhaps more powerfully — to service booking flows, where the logistics step (date/time selection) is especially disruptive to browsing momentum.

How It Works

1. Browse freely. The user scrolls a services or products page and clicks "Add to Cart" (or "Add to Booking") on items they want.
2. Cart fills without friction. Each selection opens a side drawer or updates a cart counter. No date, time, staff member, or payment info is requested yet.
3. Price is hidden or minimized. The running total may show $0 or be visually de-emphasized, allowing the user to keep adding without sticker shock interrupting the flow.
4. Checkout triggers logistics. Only when the user clicks "Checkout" or "Continue" are they asked to select dates, times, staff, and enter payment details — once per service if needed.

The result is a sequence of small dopamine hits (each "add" feels rewarding) before any cognitive load is imposed.

Why It Works for Service Businesses

Service booking flows have a uniquely high friction point: every service requires a date and time, and selecting those requires the user to context-switch from desire to calendar management. If that switch happens immediately on each "Book Now" click, the browsing experience is repeatedly interrupted.

Deferring date selection until checkout means:

• Users can build a multi-service cart in a single uninterrupted flow
• The total price is not visible during the selection phase, reducing abandonment driven by sticker shock
• The emotional state ("I want this") is sustained longer before the rational/logistical state ("can I make this work?") is triggered

"You are allowing someone to hit all of their dopamine receptors, load their cart up with things. What they see is the price is so much less than what is actually going to be spent."
— Kimberly Gehrmann, ^[1]

Implementation Considerations

Custom Code vs. Off-the-Shelf Plugins

This pattern is not the default behavior of most booking plugins. Tools like Bookly trigger date/time selection immediately when a user clicks "Book Now" — the opposite of the dopamine flow. Implementing this pattern on a WordPress/Bookly stack requires either:

• Custom Bookly extensions — if the plugin's API supports deferring the scheduling step (requires documentation research to confirm feasibility)
• Custom front-end layer — a cart-like interface built on top of or alongside Bookly that collects service selections before handing off to the booking engine
• Alternative platform — if the plugin cannot be extended, a different booking system (or fully custom code) may be required

Glossier itself runs on custom code, not a WordPress plugin. The pattern is achievable in WordPress but likely requires meaningful custom development beyond standard plugin configuration.

Design Requirements

• A side drawer or slide-out cart that opens on each "Add" action, providing immediate visual feedback
• A cart that displays service names without requiring date/time at the item level
• A checkout flow that sequences through each booked service to collect scheduling details after the full cart is confirmed
• Optionally: a suppressed or hidden running total during the selection phase

Scope and Stakeholder Alignment

This pattern is visually simple but technically non-trivial. It is easy to misinterpret from wireframes or mobile-only designs — a side drawer in a Miro mockup can look identical whether it opens before or after date selection. Explicit desktop wireframes and annotated user flows are essential to avoid misalignment between client expectations and developer implementation.

When scoping a project that includes this pattern, ensure the SOW explicitly addresses:

• Whether date/time selection is deferred until checkout
• Whether the cart suppresses pricing during selection
• Which booking engine or plugin is expected to support the flow, and whether custom development is in scope

Related Patterns

• Add-to-cart before checkout (standard e-commerce)
• Progressive disclosure — revealing complexity only when the user is ready
• Anchoring and price framing — showing a lower perceived cost early in the flow

Client Examples

• ^[2] — The desired booking flow for the /services page. As of December 2025, the Bookly implementation does not support this pattern; feasibility of customization is under investigation. See ^[1] for full context.