Overview

Raisegiving was a startup focused on building a fundraising platform targeted at non-profit organizations. Slickage was brought in to provide engineering and product design leadership to their existing team (a handful of mid- to senior-level engineers and a junior designer.

Challenges

Our initial goal was to assess and mitigate the tech debt over the previous 3-4 years. After reviewing the existing platform, we realized the user experience was holding back end-user engagement.

Raisegiving’s CEO identified the Campaign pages as the highest priority experience to rebuild—since this is where organizations promote their fundraising campaigns and convince people to donate.

During the redesign of the campaign pages, we felt that the checkout view was the biggest obstacle to donation. Discussion with the Head of Customer Success confirmed our assumption—he recounted many customers reporting confusion with the checkout form. The site analytics further reinforced the problem—more than 60% of donors were abandoning the checkout process midway.

I reviewed the checkout form and confirmed that the process was too confusing. There were numerous checkout options, all exposed on a single long page without enough guidance for donors.

The process

The flow diagram shows multiple ingress points from the Campaign views, many possible actions in the checkout flow, and several branches based on donor choices.

The first step in my process was mapping out donors’ flow through the checkout process. The flow diagram revealed the massive number of options that overwhelmed donors and prevented them from completing checkout.

After several rounds of iterations on the flow diagram, we were confident we had captured all the actions and organized them into the optimal flow. I then decided to focus the redesign effort on:

• Masking the complexity of the form—it contains many options, but 90% of them were required
• Encouraging users to complete the checkout process

After validating the flows, I created mockups of the mobile user experience. We started with mobile first since analytics showed that +70% of donors were on mobile. It was also easier to extrapolate a mobile layout into desktop.

The design was based on a simple design system I created for the product. Colors, typography and button styles were based on the marketing web site built by an external marketing agency. The form styles—fields, lists, and validation states—were all designed from scratch.

Breaking up the checkout process

I broke the flow down into multiple screens rather than a single long form. This helped reduce users’ cognitive load—allowing them to focus on the smallest set of decisions and actions before moving on to the next step.

Campaign and Team details

The first view in the flow shows Campaign and donation details. The top of the view displays a Card with the campaign’s cover image and name to maintain continuity with the campaign view.

The campaign card also displays the current progress of the campaign—amount donated, percentage towards goal, and the campaign end date—to motivate users to complete their donation.

If the user arrived on the checkout view from a Team page, the team is automatically selected and displayed. If not, the donor can click the button to open a modal and select from a list of all teams.

One-time vs Recurring donation

The next section prompts the user to select whether they want a make One-Time or Recurring donations.

Selecting the Recurring donation type opens additional fields for scheduling options. Hiding these fields for the One-time option reduces clutter and the number of fields the user must fill out.

Donation plans

Fundraising organizations can also setup their campaign with donation plans. If enabled. Donation plans are shown as large cards with images, description, and selection options. Users can swipe through the cards to view all the Donation Plan options.

Payment options

Once users have chosen their donation options, they proceed to the Payment Options view. New users can add a payment method by selecting the payment type buttons and entering their credit card or checking account details.

If they are a returning donor, they can select from one of their Saved Payment Profiles—making it much easier to complete the donation.

Donation summary

After selecting a payment type, the system displays a summary page highlighting the donation details, donor’s personal info and their payment details.

I also decided to use this view to display validation errors that may have occurred on previous screens. Donors can jump straight to the section with errors to easily update the information.*

Confirmation

After the donation has been submitted, the system will display a confirmation message thanking the user for their donation. I experimented with a few animations for the “Thank You” header to add a bit of fun and celebration for donors. I used Figma + After Effects + Lottie to create the small and performant animations.

Confirmation and "Don't Forget..." emails

In addition to displaying the confirmation view, I specified that the system should send a confirmation email with the donation info and links to share the campaign. If the user has not created an account on the fundraising platform, the system includes a sign-up link on the confirmation email.

If the donor makes it past the first step where they enter their email address, then abandon checkout, I suggested the system send follow up email a day later, reminding users about the campaign and encouraging them to come back and donate.

Deferring options

I simplified the checkout process by deferring optional information until after users complete checkout.

Donation dedication & message to the Organization

The system also allows users to complete two optional steps: 1. Dedicating the donation in honor of someone else, and 2. Sending a message directly to the fundraisers

I moved these optional steps after the checkout process is completed to reduce the number of steps donors must go through to finish their donation.

Review

I led a few rounds of design and review with internal stakeholders—the CEO reviewed alignment with business goals, the Head of Customer Success assessed how well this design solves customer pain points, and the Engineering team reviewed feasibility and level of effort—I involve engineering teams in the design process as early as possible so we can quickly get on the same page and all agree on what we are building.

We then presented the mockups to a handful of close customers, and the feedback was overwhelmingly positive—customers found it to be much clearer and easier to use than the existing checkout process.

Unfortunately we don’t have objective metrics on how much this redesign improved checkout completion, because the company ran out of money before we could finish implementing these new views.

The views we did implement went quite well—I worked directly with the engineering teams to build the UI. Most times, the engineers would stub out routes and a basic view, and I would go in and add the markup and styles to build the UI. In other cases, I would start the view and any basic components needed, and the engineers would wire them up real logic and data.