Roles:Led user experience, wireframing, prototyping, HTML/CSS design & implementation, analytics, project management.
Outcomes:Boosted checkout conversions 15-20%, decreased submissions with errors 70%, increased guest checkout conversions 15%, identified and fixed a six-figure lost revenue opportunity.
Learned:Evolved our squad-based development process, improved our iterative rollout strategies, custom instrumentation at the beginning of the project was key in guiding development.
The checkout process at Goldstar has evolved several times over the years. This would be my second time redesigning checkout to adapt to evolving business needs. I like to compare it to fixing an airplane full of passengers in mid-flight. No pressure.
The first redesign was to better accomodate mobile devices. (At Goldstar, a huge percentage of our purchases take place on the mobile web.) This time, we needed to accommodate expanded payment methods, guest checkout, and a general cleaning/organizing of the cruft that accumulates over the years.
We had reached the limits of what an accordion-style checkout process could handle. It was time to move to a more flexible screen-based flow.
Checkout presents some unique design challenges. Because of its complex business logic, we couldn't afford to A/B test a separate flow. Instead, we collected analytics and built a dashboard that was emailed to the team daily. This provided a "canary in the coalmine" of sorts, keeping us informed of any unusual changes in conversion.
Additionally, we needed to break down the changes into very small iterations with minimal complexity, so we could push them out quickly with minimal risk of disrupting checkout.
The first stage in the redesign was to map out a screen flow that would accommodate both our business model and the additional functionality. This meant digging into the codebase and talking with key staff to record all the various checkout scenarios. I took this research and built a flowchart and a Framer prototype that I reviewed with the team and stakeholders throughout the company.
With a green light to proceed, we started in on the work to convert the long accordion to a screen flow. The toughest part (as a designer) was that for about two weeks, checkout was undergoing a public remodel as we extracted sections of the process and moved them into discrete screens. It was completely functional, but also a bit of a hot mess. But once we got all the screens built, we could tell that we were on the right track — screens were dead simple, single-purpose pages and conversion had stabilized upward of where we began.
We ran into several large issues during development that ate up tons of time, although we still ended up finishing within the expected timeframe.
First, in order to add PayPal, we had to make significant back-end changes. This took time away from checkout development, but because we'd organized around small iterations, we were able to continue front-end polish without any back-end resources.
Once the back-end was ready, we were ready to turn on the front-end for consumers — but wait! There were administrative loose ends that needed to be resolved before we could launch the feature. I felt a bit sheepish about this one, not having double-confirmed that all the admin tasks had been completed. It would have been nice to have started on that earlier.
Our new checkout tracking also discovered a lost revenue opportunity. We were able to deploy a relatively simple fix that removed the friction. This was one of the more satisfying wins during this project, since we'd discovered an issue that had been unknowingly degrading conversion performance for years.
The thing I liked best about this project is how well the small team functioned. Over the course of about 6 months, 4 of us (me as lead, UI designer, front-end developer, back-end engineer) worked closely together to push out features and improvements continually. We huddled daily in the mornings, always making sure everyone had what they needed and no one was blocked. Roles and titles really fell away, and we just focused on getting things done.
We used feature-flags wherever possible to get code into production as early as possible, making it easier for us to iterate on it (nothing worse than having to get massive pull requests approved). For a critical flow like checkout, this was instrumental in letting us develop and fix issues quickly with minimal risk. We also found ourselves learning new things all the time once features made it out into the wild.