Redesigning Checkout Experience

The project aimed to revolutionize MongoDB's checkout experience by adopting a dynamic, full-page payment approach, informed by industry analysis and progressively implemented to enhance user flow and satisfaction.

Lead Product Designer




In response to feedback from both internal sources and our customers, MongoDB's Growth and Billing & Payments teams embarked on a journey to reimagine the checkout experience. This initiative coincided with MongoDB's commitment to enhancing Atlas, its developer data platform, with the invaluable guidance of the external agency, CXL.

Through thorough competitive analysis, we discovered that industry leaders in the SaaS realm were embracing full-page payment experiences. Recognizing the potential of this approach, we envisioned a seamless transition from our Cluster Builder to the payment stage, aiming to minimize any friction along the way.

By leveraging MongoDB's experiment infrastructure, we gradually introduced this enhanced checkout experience to our website visitors. Our goal was to create a dynamic and contextual process that would effortlessly guide users through their purchase journey, presenting relevant information precisely when needed. This narrative underscores our dedication to continually improving the user experience for our customers.


Design the ideal checkout experience for our new and existing customers that is scalable for all payment flows. Take into account the moment of their journey they are in: first time, upgrading, purchasing support or consulting, etc.


  • To improve customer perception that MongoDB is expensive and not transparent around pricing.
  • To improve long-term retention of paid customers.
We hypothesize that expanding the payment experience to be full screen to be contextual and dynamic will improve checkout conversion because it will be more personalized to where the user is in their MongoDB journey.

Success Metrics

  • Primary: Checkout conversion from checkout started to checkout completed
  • Secondary: Checkout completion timePercentage form completion


  • Lead Product Designer, myself
  • Senior Product Manager, Growth
  • Product Manager, Billing & Payments
  • Engineering Lead, Growth
  • Engineering Lead, Billing & Payments
  • UX Researcher
  • Data Analyst
  • Full-Stack Engineering team


  • VP of Engineering, Billing & Payments
  • Director of Engineering, Billing & Payments
  • CXL (third-party agency): design and UX research consultants

Target Customers

  • Customer Type: new and existing customers
  • Company size: all sizes
  • Persona: Full Stack Developers

User Stories

  • As a Full-Stack Developer, I want to create and pay for my first cluster, so that I can utilize the features and advantages of a cloud database.
  • As a Full-Stack Developer, I want to upgrade my free cluster, so that I can utilize the features and advantages of a cloud database.
  • As a Full-Stack Developer, I want to purchase a support plan, so that I can get the technical knowledge and advice need to move my development cluster to production.
  • As a Full-Stack Developer, I want to purchase a consulting package, so that I can get targeted advice on my upcoming migration to cloud.


Initially, the concept of creating a full-page payment experience for our checkout flow was something we as a team discussed based on the initial competitive audit that another designer on my team created. Following the audit, I set off to understand the landscape of checkout experiences and define UX Best Practices that I could refer back to in the design process. These UX Best Practices became my guiding principles in the design process.


User Flow Diagraming

After I had some best practices to refer to, I dove into mapping out the user flows for each payment flow the new Checkout experience would need to support. Since we are a remote-first team, I created these in Miro and shared them with my cross-functional team for feedback.

View full size image on
View full size image on Dropbox


Based on the current MongoDB Atlas platform I had a clear sense of the page structure and templates I wanted to pull from once getting started. For cognitively heavily configuration flows we tended to use a fixed header that focused the user’s attention and grounded the content below. This page template was used pre-payment in most of the payment flows, so it felt like a natural continuation of the visual language to borrow it for the payment flow.

Design Principles

  • Dynamic and contextual
  • Transparent pricing
  • Simplistic and delightful

UX Goals

  • Ensure users know what their estimated monthly organization cost is
  • Match user's expectations for a checkout experience
  • Eliminate user’s perception that MongoDB doesn't have transparent pricing
  • Ensure users feel appropriately informed about how much they will pay for this cluster

Design Workshop

I created two different concepts and presented them to the team of engineers and product managers and invited fellow designers to a Design Workshop. During this, I asked them to write down each concept's strengths, weaknesses, and edge cases. As well as build upon the flushed-out concepts with their own ideas, questions, and suggestions.

While Concept #2 had more Strengths, we were not confident that a drawer UX was the right approach to scaling the designs. Therefore we proceeded with Concept 1 and adopted some of the UX details from Concept 2 into the next iteration.

Workshop Goals

  1. Align stakeholders on a single concept
  2. Answer open questions

Concept 1

Full Page with fixed header and side panel

View the full size image on
View the full size image on Dropbox.

Concept 2

When no payment on file use a full-page experience; when payment is on file use a drawer overlay

View the full size image on
View the full size image on Dropbox.


From there, I created a clickable prototype in Figma of the refined concept from ideation, shared it with the team for feedback in a team design review, and prepared it for user testing. To get a feel for the whole flow, I mocked up the key user flow: a net new user signs up from MongoDB from our marketing site and, purchases a paid cluster, then deploys it.



Once the prototype was in testing shape, I worked with our own internal UX researcher, Andrea, and our UX research partner at CXL to create a testing plan to understand how user’s reacted to this new design and if it met the user needs we identified early on in progress. For the test, we used a task analysis method along with likert scale questions at the end to measure the impact on the defined UX Goals.

Round 1

For the first round, I provided a prototype, testing plan, and tasks to our consulting agency, CXL, to test with a group of MongoDB users that they had supplied. They ran the test for us and provided video recordings of the users. We ended up running into quality issues with the participants, and I made the case to test the designs ourselves using MongoDB’s usertesting.com account.

Number of Participants: 5

Round 2

We ran the same test for the second round but with identified MongoDB developers from the company’s usertesting.com account.

Number of Participants: 8



Overall the participants responded positively to the designs and confirmed that the layout and UI matched their expectations for a SASS checkout flow. Based on the results of the user testing, I created a research summary report and shared it with our stakeholders for review. From the results, the team felt confident that we could ship the designs as an experiment to MongoDB’s Atlas users in the next phase.

Top Findings

  1. Overall the Checkout experience met users’ expectations and showed the information they’d expected, including Cart, Payment Method, and Billing Address expect.
  2. Users easily found the monthly estimated cost.
  3. Users appreciated that we displayed the Included Free Features in their Cart.

Areas for Improvement

  1. Add information around the Cloud Provider and Region of the Cart summary
  2. Make the Monthly Estimate larger
  3. One user assumed they would have to set up their billing details on an account settings page.
  4. Users expect a confirmation screen after purchasing that includes a summary of their purchase, order number, and details about how to connect to their cluster.
  5. Show details or payment certifications to show that their payment and transaction will be secure and safe.

Iterate & Refine

After validating designs through user testing, I refined them based on feedback from testing and team design reviews. Weekly collaborations with the Cloud Core Design team helped align the final designs with MongoDB’s design system. Simultaneously, I tested component scalability for each payment flow and created reusable components in Figma. This investment of time paid off when presenting the designs to key stakeholders invested in various payment flows.


See the figma


Since the UX was intended to be rolled out as an experiment, the team wanted to be intentional about how many variables we introduced in the experiment so that we could measure the impact. Given the complexity of our existing Payment UX across multiple flows, we collaborated with the Growth team to ease the engineering process.

With the Lead Product Manager, we created a proposal for a phased-roll out of the experiment and presented it to Engineering and our stakeholders for buy-in. The Engineers felt this was a sensible approach and agreed to implement the phases of work over the next quarter. For each phase, we released it as an experiment, measured the impact, and moved on to the next phase for implementation.

Phase 1 - “Full-Page Checkout” 🚚

  • Adapt the existing payment modal stepper form into a full-page experience using the cluster builder page template.
  • Add in the back button when a user is on the Payment & Confirmation step so they can go back on the wizard.

Phase 2 - Basic Shopping Cart  🛒

  • Left align embedded form, add in the right pane and create simple cart “cards”. Include hourly and monthly estimates.

Phase 3 - Cart - Estimate Additional Fees and Card Details 💸

  • Build a basic shopping cart cluster description bullets and cluster "feature cards". Include an estimated monthly total, subtotal, and additional fees.

Phase 4 - Sequential Payment Form 🎉

  • Update payment and address components - build the new form.


After Phase 4 reached statistical significance, our Data Analyst produced a report on the findings. Surprisingly, the experiment yielded neutral results, showing no change in paid tier cluster conversion rate. One observation was a higher average gross revenue in the treatment group compared to the control, attributed to a few large deployments in the treatment group. Despite this, compelling qualitative findings prompted us to rerun the test in smaller phases to determine each variable's impact on our funnel. This rerun was underway when I left MongoDB.

“ From a CX perspective, the full page checkout allows MongoDB to combat the POV that we are not transparent in our pricing, in that we now include much clearer pricing estimates. Additionally, according to qualitative UX Research, the anecdotal evidence is really compelling. Simply put, people feel more comfortable checking out with more transparent price info and clear next steps.” — Analysis: Full Page Payment modal V2


This project was a significant learning experience for me, as up until this point I had only ever shipped small targeted experiments using the experimentation framework. I am very grateful to have had the opportunity to lead such a large redesign of MongoDB’s checkout experience and be able to utilize the experimentation framework to roll it out in succession.

Looking back here is what I would have done differently:

  • Start with a more similar 1:1 comparison for the UX from the control and the treatment.
  • Reach out and schedule interviews with a handful of users from the treatment group to gather qualitative feedback.
  • Spend less time focusing on visual elements like icons and illustrations in the mid-fidelity phase. Ultimiately those were removed as I believed they didn’t add anything to the experience.