Onboarding Design for Switching

Written
  • Source: https://jtbd.info/design-for-switching-create-better-onboarding-experiences-306c6d5b412a
  • Author: Alan Klement
  • I realized that the onboarding process for the product was inadequate. Naturally, I then thought about how it could be better. I decided to look at this problem through the lense of Jobs-to-be-Done. When I did this, I started asking my self new questions — questions that are not usually associated with designing an onboard process. After some thought, I had an answer for this puzzle: This product hadn’t taken into consideration of my understanding of the Job and my past experiences using solutions for the Job.
  • Solution Experience is how familiar a customer is at using solutions ( products ) to solve a Job. It’s a combination of two things:
    • A. How many solutions the customer has used in the past.
    • B. How proficient they are at using a solution. In this case, I had a low Solution Experience because I only had used one solution in the past ( spreadsheets ) and I only had used it in a very basic way ( a few text columns and one number column that added numbers ).
  • Here some examples of moving across the Solution Experience axis, using tracking expenses as an example:
    • A. Tracked expenses, in a very basic way, with one or two solutions: e.g. a spreadsheet or pen & paper.
    • B. Pretty good & experienced at using one solution ( spreadsheets ) to track expenses.
    • C. An expert at using one solution ( spreadsheets ) to track expenses in complicated ways.
    • D. An expert at using many solutions (spreadsheets, various online & offline accounting software, pen & paper ) to track expenses in complicated ways.
  • I didn’t know much about expense reports and how to use them, so I had low Job Comprehension — how well someone understands the Job-to-be-Done. The opposite of this, high Job Comprehension, might be an acc
  • I didn’t know much about expense reports and how to use them, so I had low Job Comprehension — how well someone understands the Job-to-be-Done. The opposite of this, high Job Comprehension, might be an accountant who had formal training in expense reports and has had years of experience creating them.
  • These can be combined into four quadrants:
    • Q1: I’ve done expense reporting for years, in all types of contexts : I’ve also used many different products over the years and know them all well.
    • Q2: I’ve done expense reporting for years, in all types of contexts : However, I’ve only used one product the whole time , or, I’ve tried several different products but nothing stuck to me.
    • Q3: I don’t know much about what an expense report is or how it’s going to be used : I’ve never done this before — I think someone told me to use a spreadsheet.
    • Q4: I don’t know much about what an expense report is or how it’s going to be used : But i’ve been using one or more solutions for a while and when I do, I usually just use a few features which I know really well.
  • The first thing we need, is to learn a little bit about our customer. Since we can’t interview each customer who tries our product, we can ask a few, non intrusive questions when they start the app.
  • Also, keep in mind that that as quadrant 3 switchers become long-term customers, they will be migrating to quadrant 2 as your tool becomes their solution of choice. To facilitate this, consider slowly revealing features to them as they use your product or hit particular interaction milestones

Thanks for reading! If you have any questions or comments, please send me a note on Twitter. And if you enjoyed this, I also have a newsletter where I write about tech thoughts, interesting things I've read, and project updates each Thursday.

You can check out a recent issue, or enter your email below to subscribe.