Bidding Modality

The Challenge

Placing a bid is more than entering a number—it’s a moment of commitment. But our initial implementation treated it like a form to complete, scattering required steps across isolated flows that pulled users away from the auction they were invested in.

For mobile users (85% of our bidders), this was especially disjointed: verifying ID meant losing sight of the item, adding payment required navigating away, and bid confirmation felt disconnected from the auction’s momentum.

To bid in an auction, users must complete several steps:

• Enter a valid bid amount (above the current highest bid plus minimum increment).
• Acknowledge and accept terms and fees, including a payment authorization for the buyer’s fee.
• Have a form of ID verification.
• Have a valid payment method.

Each of these flows were built independently, often requiring users to go through isolated flows removing them from the auction context. For mobile users especially, this created a disjointed experience with difficult navigation and wayfinding. I needed to design a comprehensive bidding experience that guided users through the necessary steps while maintaining focus and clarity.

Outcome: First-time bidders completed the flow 60% faster with measurably lower abandonment rates—critical for a new platform where trust is everything.

Principles

To design an effective bidding experience, I adhered to several core principles:

• Transparency: Clearly communicate fees, status, auction rules, and what to expect.
• Modality: Bidding is a focused task as part of the auction lifecycle. The interface shouldn’t take users out of the moment.
• Progressive disclosure: Present only what’s needed at each step to avoid overwhelming users.
• Single action focus: Each part of the bidding flow should focus on one primary action, eliminating decision fatigue or distractions. Guide users through the process.
• Wayfinding: While the interface is minimized and progressively disclosed, users should always know where they are, how they got there, what’s next, and how to backtrack.

States and User Flow

Before designing screens, I needed to understand the journey. I mapped every state, edge case, and transition to guide the initial design, creating a foundation that could flex as the platform evolved and new requirements emerged.

Early ideation

With 85% of bidders using mobile devices, the first prototype used a sheet component to mimic the patterns of native mobile apps, which suited the “micro task” nature of bidding. Because there is no native sheet component on the web, I initially used Vaul to emulate native sheet behavior, with a responsive fallback to a standard dialog for desktop.

For simple interactions, Vaul worked well—but as we introduced more complex states, the fundamental constraints of emulating native patterns in a web context became apparent. Unlike native sheets that sit above the keyboard layer, web-based sheet implementations exist within the browser’s layout flow. This created cascading UX problems: when users tapped to enter a bid amount, the virtual keyboard would push the sheet upward, causing jarring layout shifts that obscured the input field they were trying to interact with. The sheet would snap and resize in ways that felt broken compared to the smooth, predictable behavior of native mobile patterns.

These weren’t bugs in Vaul itself—they were inherent limitations of trying to faithfully recreate native OS-level behaviors within the constraints of web browser architecture. The browser simply doesn’t provide the low-level control over viewport and keyboard interactions that native platforms do.

Ultimately, we decided to stop fighting browser limitations and pivoted to a solution that worked within the web’s constraints, freeing us to focus on the interaction patterns that mattered.

Initial bid entry

The bid entry state is designed to allow users to experiment with different bid amounts. It provides real-time feedback on bid validity and total cost, with a clear breakdown of fees.

If additional steps are required, those are listed as prerequisites and the primary action adjusts accordingly, with Single Action Focus and Progressive Disclosure principles in mind.

ID Verification and Payment Methods

Once a bidder has committed to their bid, the flow guides them through any necessary steps without leaving the bidding context.

Completing one step seamlessly transitions to the next, maintaining focus and clarity.

Confirmation

The final confirmation state shows a receipt of the bid, including the bid amount, buyer’s premium, and controls for which card to charge for the buyer’s premium. It also reaffirms the terms and authorization amount.

When ready, the user can confirm and submit their bid with a unique interaction pattern, “hold to bid.” This reduces accidental submissions and adds a tactile element to the bidding process, introducing a small amount of friction to give bidders confidence and time to make their bid.

Bid confirmed

Submitting a bid kicks off a series of backend processes, from validation to payment capture and notifications before successfully placing the bid. Originally, the UI showed some of these system states, which provided a clean transition from bid submission back to the auction context.

This would later be simplified to immediately close the modal upon a successful bid after usability testing. Visual feedback on the auction page, along with haptic feedback (vibration) and audio cues provided sufficient feedback that the bid was placed.

Impact and Learnings

The new flow reduced time-on-task by 60% for first-time bidders, with measurably lower abandonment rates. As a new platform where many users joined specifically to bid on a single item, this tight first-time experience became critical to building trust and retention.

Key insights that shaped our approach

More friction, not less: Despite our transparency efforts, bidders were surprised by payment authorization holds appearing on their statements. The design balanced speed with clarity, but future iterations may introduce slightly more friction around payment authorization to set proper expectations.

Success is suspected, not announced: Usability testing revealed users don’t care about backend processing states—they want confirmation their bid landed and immediate return to the auction. We eliminated the “processing” states entirely, using modal dismissal itself as the success signal. This pattern now applies to all Summimarket modals: close means success, explicit error states for failures.