For the first two years of Kickbooster’s pledge manager, the app existed without a proper onboarding flow. Pledge manager allows crowdfunding creators to create a checkout for their backers, in order to collect their shipping information and to upsell additional campaign products. In the early days of pledge manager, the onboarding experience was a call between the user and a support person, guiding them through each step of a tedious setup. If there was no call, users would have been left to their own devices to figure out how to setup their pledge manager themselves. This task, though not impossible, was daunting for a new user because of the numerous steps needed to set up a pledge manager.
This was overall a poor experience for all parties involved. For the user, this was a poor experience in navigating the many steps of pledge manager, and assessing what’s necessary. The frustration of this setup often led to new users dropping off, which of course, was bad for the business. As well, the current way of onboarding was a drain on our support staff (and even other members of the team, as we were a small team) so making pledge manager self-serving would free up our team’s time.
| 🤔 Problem | ⛔ Why it’s bad for users | ⛔ Why it’s bad for the business |
|---|---|---|
| Pledge manager didn’t have a proper, self-serving onboarding flow. | Users didn’t know what to do next nor how to go about setting up their pledge manager. | The setup of pledge manager turned a number of potential customers away; and onboarding was taking up a lot of time from the team. |
<aside> 🗒️ This case study will only cover the design phase of this project: how my thinking went about the problem, and how I came up with a solution.
</aside>
| Role | Product Designer |
|---|---|
| Responsibilities | Facilitating design, exploring concepts, loop users into project |
| Duration | 2 Months [Design phase] |
| Other members involved | - product manager |
Prior to the project, I discussed with my product manager metrics we could use to measure the success of this project. As the scope of this project grew to be quite large, affecting many parts of the app and user experience, we felt that no single metric could be used to reliably used to measure success. As we worked through this problem, we knew it would continue to be a work in progress (there’s always something to improve in any onboarding experience), so we established a set of particular metrics to track over time in order to have some measure of its impact.
| User Metric | What this tells us |
|---|---|
| User Activation Rate | |
| Users who activated their pledge manager vs. users who signed up for pledge manager | Over time, an increase in this metric tells us more of our users who sign up, end up activating their pledge manager. |
| Setup Completion Time | |
| Time between user signup and pledge manager activation | Ideally this metric would decrease over time, but we decided it’d be good to have an overall sense of the setup time. We could use this in the future to compare pledge manager setups and assess why a setup took more or less time than the average. |
| Intercom Inquiries | |
| Number of support inquiries with the pledge-manager-help tag in Intercom | Quite simply, a decrease in this tag tells use less users are experiencing (immediate) difficulty with their setup |
| Customer Effort Score (CES) survey | |
| A quick survey asking users to rate their setup experience and provide a text field should they have anything they want to comment on about their experience. | This gives us a general idea of the overall setup process, and provides a medium to collect qualitative feedback about the onboarding experience. |
To kick off this project, lots of discussions were had with my product manager, support staff, and other team members who were aware of pledge manager’s onboarding issues. Those members had plenty of one-on-one’s with users, walking them through the app and understanding firsthand the pain points of our product. With this collective knowledge, I felt that additional user interviews weren’t necessary at this stage.
Outlining issues with our current “onboarding”.
From these chats and my own audit, the main problems with the current (lack of) onboarding flow were:
| Problem | How might we fix this |
|---|---|
| ⛔ No introduction to the app; nothing telling the user where they are nor what to do | ✅ A welcome screen of some sort |
| ⛔ Nothing showing users what to do next, or what is left to do | ✅ A list of actions to take (or opt not to take) in pledge manager |
| ⛔ No indication that any step of pledge manager is “complete” | ✅ A means of checking off a step from the list |
With the “fixes” above in mind, many ideas were generated for what a solution might look like. In a FigJam board with my product manager and lead developer, we walked through screenshots of pledge manager and sketched some ideas of what could be helpful to users. As well, we kept in mind that some parts of the app could be repurposed to solve some of these problems and thought about how those would factor into the long-term vision of pledge manager’s onboarding.
The pre-existing activation page containing the master checklist, which we wanted to be able to use throughout all of pledge manager (and not just on a singular page).