Revamping Checkout

Lead Product Designer · Custom SAP Commerce Cloud

Context

Off Broadway Shoe Warehouse is a footwear retailer that had just relaunched on SAP Commerce Cloud. The new storefront looked current. The checkout underneath it did not, and the funnel showed it almost immediately.

I came in as lead product designer to rebuild the flow end to end: research, data analysis, restructuring the steps, mobile-first UI, prototyping, and usability testing. The platform was not up for debate. Every field, state change, and payment integration ran through SAP’s checkout logic, and anything I drew had to survive contact with it. That made this a systems problem as much as a design one. I spent as much time working out what the stack would allow as I did designing screens.

Problem

Analytics told me where people were leaving. Two numbers framed the whole project: 64.2% of carts were abandoned in checkout, and mobile completion trailed desktop by 28%.

Finding out why took three sources: Hotjar session recordings, twelve support tickets tagged “checkout issue,” and five unmoderated tests I ran on the live flow in Maze, with think-aloud prompts. The same three complaints kept surfacing.

“I thought I had already paid.”

Page transitions gave no signal, SAP's payment API was slow to answer, and the loaders in between explained nothing. People sat watching a spinner with no idea whether their card had been charged.

“Why do I have to enter my address again?”

Choosing an express option like Apple Pay, backing out, and switching to a credit card flushed the address already entered. SAP's form state logic treated it as a new session. Several support tickets said the same thing in different words.

“I couldn't tell if the order went through.”

The confirmation screen had no real hierarchy. No large thank-you, no order summary worth the name, no delivery expectation. People lingered on it, unsure whether to close the tab or keep waiting.

What the audit turned up

• No progress indicator. Nobody could tell how long the process would take, or how far in they were.
• Unlabeled error states. Inputs failed silently, or failed in technical jargon.
• Delayed loading states. Moving between address, shipping, and payment was slow and unannounced.
• Inflexible input formats. Phone numbers and ZIP codes were rejected over formatting alone.
• Broken mobile layouts. The address step fell apart on small screens, where most of the traffic was.

None of this was a bug list. Every item was a gap between what people expect a checkout to do and what this one actually did, and the gaps were widest exactly where the money was.

Approach

I worked mobile-first and designed against the constraint rather than around it. Adding or removing a single field meant backend logic changes, so I needed to know early which fights were worth having.

Benchmarking

I scored competing retailers on the three things our recordings kept catching people on.

• How they write microcopy, especially shipping expectations
• Where they use autofill and one-tap payments
• Whether they use modals or multi-step screens

Who I was designing for

Two personas came out of the support logs and the test sessions. Both were shopping on a phone, and both expected checkout to behave like the DTC sites they use every day, DSW and Famous Footwear included.

The decisions that followed

• Replace the rigid three-step wizard with a condensed smart form using progressive disclosure
• Show live shipping options as soon as an address is entered, with no page refresh
• Optimize for autocomplete and keyboard-first input on mobile
• Detect Shop Pay and Apple Pay early and offer a fast lane
• Validate without blocking, with instant feedback on postal codes and card inputs
• Build every component against SAP's B2C extension framework and site accelerators

Prototyping and testing

I started in low fidelity so the SAP developer could flag unmovable logic before I invested in anything, then built a high-fidelity Figma prototype that simulated real validation and real loading states. Testing the loading states mattered as much as testing the layout, since that is where the original flow lost people.

• 8 users ran the prototype end to end, moderated and in Maze
• Tasks: complete a purchase, switch shipping method, recover from an error
• Average completion time fell about 23%
• 6 of 8 preferred the new flow to the existing one

Three things came out of those sessions that I had not planned for. Shipping clarity was the strongest trust signal in the whole flow, so delivery dates moved earlier. Apple Pay needed to appear sooner than I had it. And mobile keyboard behavior, auto-capitalization and numeric keypads, mattered far more than its size on the screen suggests.

Solution

The flow shipped as three mobile-optimized steps. Inline validation catches errors as they happen instead of on submit. A live cart summary stays fixed on screen so the total never goes out of view. Entering a ZIP triggers shipping options in place, without pushing anyone to a new screen. Every change was aimed at the same two things: fewer steps, and never losing the thread.

I did not write the production code. I aligned my components to SAP’s SmartEdit structure, handed over annotated specs and responsive layouts, and stayed on through QA across devices so the build matched the design.

View user flows →

Impact

Measured 30 days after launch, against the same window before it:

What I took from it

• Designing inside SAP is system design, not pixel work. The job was balancing what people needed against what the architecture would allow, and knowing which of the two to push on.
• Every field is a trust decision. A missing ZIP format hint is enough to lose a sale.
• Mobile parity is not a nice-to-have. If it is not built for touch, the traffic that matters most bounces.
• Bringing the developer in at the wireframe stage is what made the timeline possible. The blockers we found in week one would have been rework in week six.