Spicy take: Product education exists because the product is too difficult.
The hypothesis here is that product education is a stopgap for one of two things:
The product is too difficult to use, not intuitive, a disconnect with user behavior
The users don’t know how to use the product (ie: expertise)
This isn’t to say that some products are very customizable and to the expert, would require additional information and guidance on how to unlock those in-depth features.
This is more along the lines of continuous education on core functionality due to lack of user adoption. It manifests through help articles with screenshots, video tutorials, webinars, and FAQ sites.
The Value in Education
From a cost perspective, any time product questions can be self-served or resolved by a user, that’s saving a communication to customer support. There is a balance between a very complex workflow to reach a human vs. the ease of a quick response.
Travelocity reduced customer effort just by improving the help section of its website. The company doubled the use of its “top searches” and decreased calls by 5%.
In the scheme of things, 5% is a massive reduction in CS interactions, but the development and maintenance of these materials can be daunting. Plus, we’re not solving the core issue of feature adoption when released.
What are the operational challenges in maintenance?
Considering the balance between help and supportive education versus a dependence on adoption due to required training.
From a tactical perspective the program starts building:
Create education / help center
Bake in tutorials for new product deployments
Consolidate UXR and CS questions into prioritized self-help materials
Biggest Forgotten Challenge: Maintenance
How to keep the content relevant to the current version of the product, with the correct user journey and applicable screenshots (not to mention if all these assets are also localized, how is that routinely updated)?
With the development or evolution of an education hub or help center, strategies on how to create the necessary maintenance required and budget resources towards this effort. I mentioned earlier about baking into launches (bill of materials includes updating help/edu content with any implicated content) -- but also considering company-wide efforts that could impact any of these efforts. If naming of a feature is changed, that could impact user journey and screens. If a feature is moved, that has the same domino effect. Determining how this group is funded and kept relevant is a fundamental consideration that often goes overlooked.
Maintenance is key for self-serve success
I personally came across an issue when I had purchased a Fuji X-E4 after it had recently been released, and was looking on how to live-teather the camera for in-camera shooting operations with a computer.
All of the help articles showed me menu flows with different verbiage, because it was all citing the previous model’s designs. Online libraries hadn’t been updated. Youtube didn’t have unboxing where people showed how to find this feature. In that instance, I spent hours trying to self-serve, when all of the “help” and “FAQ” were irrelevant. Guess and check by testing similar features, downloading multiple types of firmware – it didn’t work out.
The Bottom Line
Creating a cost-benefit analysis of the cost of CS versus self-serve (development and maintenance) – may be the solution to best serve customer needs.
But what if the question is higher up in the course of this journey. The product itself - is it optimized for the intended user?
Inputs = customer testing and feedback
Heat-maps / Tracking = see where users are getting caught up / repeating etc
Stress test = max out constraints to see what breaks
General QA = including end-users in evaluation and not just technical bugs
In discussion with a colleague about generalizing the lack of user adoption and industry implications, their response was very telling = “You mean to say, without adoption, it’s just shelfware?*” I couldn’t have phrased it better.
* = slang for a product for a perceived need or demand but is never used
