Let’s set some context…

While onboarding at MongoDB it made sense for me to pick up a first project to help me learn the design system and learn all the inner-workings of my team at MongoDB. I loved that I could focus on improving the checkout process as my first contribution and I knew we would be successful in our goals we set.

The Problem

MongoDB University’s checkout should be better optimized for conversion.

Impact of this problem

Certification is one of our key monetized product offerings and contributes a large amount of revenue to University. The current checkout experience requires a redesign that will modernize the check out experience and decrease friction points at this most important part of the conversion funnel.

Modernization efforts are important:

• To maintain an industry standard ecommerce checkout experience that builds trust with users upon purchase

• To create a consistent visual experience in university and across other MongoDB products

• To create a checkout experience with less friction (easy to complete forms, less click steps, easy to understand price on checkout) so that conversion happens faster.

My Role and the team

Product Design lead and acting individual contributor.

In this project I was responsible for the end to end product design from research to handoff.

The team for this project was
Product Design and Research - Erin Essex
Engineer - Domino Weir
Product Manager - Tonya Edmonds

Field evaluation

Its pretty well known that in form design and especially check out that we only ask for the fields we actually need.

I started to look at all the fields we were collecting and starting trying to find the “why” behind all of them. I know from experience that sometimes when you go looking for answers there are almost always legacy reasons we collected information that isn’t relevant anymore and no one has come in and say "lets remove that.”

So that was what I did.

I Identified three main areas that I wanted to question.

1. Why were we collecting the address twice?

2. Did we need to collect all the company and title information? and if so who was using it?

3. Why are we collecting phone numbers if not for credit card validation? Do we use these phone numbers for anything?

Next I went to find the people that had answers to these questions. At first they wernt’t easy to find, but eventually I was able to find the right people to inform if these fields were necessary.

1 - Why are we collecting the address twice?
Turns out that when this form was first made they used the first address collected to physically mail things to the exam registrants. This was no longer needed however there was some hesitancy to get rid of this address as sales thought they “might want it some day” - however I explained that we were likely hurting conversions on this because this form was so long. The sales team eventually was convinced that collecting this information was not worth the risk of having people not sign up for the exam at all. So we agreed to eliminate it.

2 - Why were we collecting the company and title information and how was it being used?
For this answer I found a contact that worked in the directory (the listing of people that eventually pass this exam and how its listed). Turns out this information was being used for the directory after users passed the exam. Though its debatable if this information should be collected after a user passes the exam it was determined that its easier to ask before hand. So we compromised to keep these fields on the checkout form.

3 - Why are we collecting phone numbers?
The sales team told me that they did want to keep collecting the phone numbers in case they wanted them in the future. Not wanting to ruffle feathers I compromised to keep it on the first step of the form but offered to take it off the second step. Sales agreed to this compromise as the second number was likely not going to be used at all.

With this detailed investigation I was able to influence the number of form fields/inputs on the check out from 27 down to 17.

Result: Form fields reduced from 27 down to 17!

Explore across the company

I sit within the Education team at MongoDB but there are other teams across the company that also have a checkout. This was the first place I started when looking for a path to update our checkout. Turns out our Growth and Cloud team was already working on an updated checkout for our customers using our core product.

This could lead one to wonder “Why couldn’t we reuse the other team’s checkout component?”
Our teams were using entirely different tech stacks and different design systems (a tech debt problem that couldn’t be solved within the scope of this project).

Tech constraints

I was given one small tech constraint. My lead engineer informed me that we could not change the system needing 2 pages, aka 2 page loads, to complete both sections of the check out process. At first she was adamant we use a stepper to count step one and step 2. But I wanted to challenge that set up.

I ended up taking to the engineer and showing the direction I thought the design was taking (where it appears to be one page to the user with expanding and collapsing areas) and how we could perhaps have the page reload but to the user they might just think it was the expanding/collapsing action rather than a new page. She was happy to accommodate this change and agreed it would be the best UX in that it made the form seem smaller.

Ideate

As mentioned above, I had a starting point with the checkout that the Growth and Cloud team started. It had patterns that I felt were ubiquitous in a checkout process such as a 2 column style layout and accordions to hide and show information at the proper time.

However, there were some things that I needed to update and modify to work towards our needs on the Education team including some layout tweaks and making it responsive.

Our checkout process was previously 2 completely different pages, I felt that using the accordions on the left panel for checkout would be the best way to make it feel like a user has not left the experience to enter the next page in the checkout process.

Consistency Heuristic

One of the challenges I had from the team was that they were not convinced that a 2 column checkout was the best approach for us. What I decided to do is spend time educating the team about the Nielsen Norman usability heuristics and how they apply to checkout patterns.

I took it one step further by spending time showcasing several different sites that used the same pattern of checkout that I was proposing.

• Macys example

• Sephora example

• Goldbelly example

Fortunately, after sharing the heuristic and examples with the team they were more onboard to update the checkout layout.

Additional considerations

Coupon
There is a coupon area of our checkout that I also had to consider. I wanted it to be findable but not in the way. I considered patterns from Macy’s and other top e-commerce sites and saw that the coupon being in the right panel was a pretty standard placement. So this is what ended up in the final design.

Paypal
We saw in our research interviews that users were asking for a more universal payment option. Namely they were asking for a Paypal option. Almost 60% of the exam takers were from India and this was the easiest payment option for them.
I worked hard to have this included in the release as this is a big win for users. You will see the Paypal interaction in many of the designs on this page. However in the end it did not make the release. We hope to later include this option for our users.

User Validation

I felt confident on the direction this project took but wanted to have one last validation with users. I put up an interactive prototype of the checkout flow on UserTesting.com. To validate this flow we agreed a simple flow would help us find if there are any major blockers, as opposed to a fully interactive test, in that the UX of this checkout was attempting to adhere to industry standards.

I had 20 users go though the flow and note if they had any trouble in the test. In this case, the users had no trouble and we felt confident to move forward.

Measure

Decrease the Exit rate for all certification products in checkout.

May 2021: 9.26% of people exit checkout
June 2021: 5.53% of people exit checkout

Decreased exit rate by 3.73%

Increase conversation rate for certification products in checkout.

May 2021: 12.99% of people completed the purchase
June 2021: 35.3% of people completed the purchase

Increased conversion by 22.31%

Was the project successful?

For sure! We were able to show that some changes to checkout can make a big difference in building user confidence to move forward in completing the checkout.