Different users: job comprehension versus solution experience
To design an ideal onboarding experience, you have to make some assumptions:
- The goals of the user.
- Their experience level with the subject matter.
- Their awareness of your application.
Knowing this, you can decide what message and experience will function the best for that user.
To make the best guess, you try to get as close to your users as possible. Through market research, interviews, surveys and analytics you can see how users interact with your application.
The closer you get you’ll realize there is more than one user group and there is more than one goal. One user may be completely new to the sector you’re operating in, and in need of more hand-holding. Another user may be switching from a competitor’s product. That type of user would be experienced with similar applications and bored by excessive explanation.
Unlike many products, software is one that could respond to someone’s prior experience levels. For example, software can take into account someone’s level of “job comprehension” and “solution experience” as described by Alan Klement in Design for switching. Alan proposes that if a user is switching, their prior experience will be different to a user who is new to that type of solution.
Alan Klement manages JTBD.info where you can learn more about the Jobs-to-be-Done framework and how it can help you understand ‘the why instead of the how.’ That is, why people make buying decisions, and using that to design products.
However, he highlights this is a potential pitfall: “from a software complexity point of view, it’s rarely a good idea to have different UIs for multiple types of users.” Rather, he suggests revealing features to customers when they need it.
Marketing teams develop buyer personas to understand who they are selling to, and what the right message is for those users. Product developers and interaction designers spend extensive time trying to understand users to make the most informed decisions about users needs.
This creates a dilemma. In the process of developing one product, you discover you have a variety of different users with different goals and prior experience. There isn’t necessarily a one-size-fits-all solution.
In terms of marketing messaging, companies have become ever more granular in their targeting specific messages to specific user groups. All of that communication generally happens outside the application, such as in targeted email marketing. There’s increasing investment in personalization at the application-level, yet this is also complicated to develop and maintain.
In terms of interaction design, progressive disclosure can hold back more sophisticated functionality as a new user gets familiar with a system. There are a few negatives, though. You run the risk of over-constraining users who later don’t need to have advanced features hidden away.
Both of these solutions are not straightforward or ideal, and they can create a maintenance headache and misdirect your product development.
Onboarding in an adaptive layer with Inline Manual
If you want to start now to respond to different user groups and buyer personas, you can do this with Inline Manual.
Merely offering a list of tutorials won’t provide the right kind of onboarding experience. A Job-to-be-done isn’t a task or activity because that doesn’t address the motivation of the user, nor their prior experience.
To respond to “job comprehension” and “solution experience” as Alan Klement suggests you can create unique onboarding experiences for specific user segments.
Here are three ways you can build in this adaptive layer with Inline Manual.
If you’d like to see how to build an interactive and adaptive user onboarding experience watch this demo of using Inline Manual.