Knowledge Base (Wefunder FAQ)
The knowledge base is not comprehensive enough but inaccessible to non-engineers, so difficult to improve. It is also not doing its job since users are emailing support to ask questions that are covered by the FAQ. It’s time consuming to navigate if you have specific questions you want answers to.
Actually answer user questions!
Thus reducing number of support emails that should be easily answered by the FAQ
Better maneuverability to promote further reading
Empower non-engineering team members to contribute
Founders (who are fundraising or have at some point, in addition to primarily founders looking to fundraise) & Investors (who have questions about their investments or looking to invest).
One designer (me). One storyteller to help with content. Two weeks.
How do people use the FAQ anyway?
Before I can set out to design a knowledge base, I needed to know how people use FAQs. So I sampled my entire office, as well as used myself as a data point, and found that generally there are two use cases:
They know their question and want the answers now. They want a fast and easy way to that answer so they can continue on their merry ways.
Just Sort of Lost About Everything
There are just too many holes to plug and searching one by one just doesn’t make sense.
Another task was understanding the sort of content we currently had in our knowledge base and clean house. We audited our content and cut down on unnecessary or duplicative info, while creating a list of new knowledge that needed to be put in writing. With this I was able to think of a few hierarchies that made sense for us.
The current FAQ had two major issues:
Poor navigation: It is difficult and time consuming to access the precise topic area the user is looking for. Causing frustration and distrust.
Disjointed architecture: We don’t make it clear how parts of the FAQ relate to each other. Nor do we give users a way to navigate between the parts. This makes deep diving into the content difficult. This leads to users not being as educated as we’d like; this could result in lower conversion with investments.
Some possible solutions to test
To address the pain points of navigation issues, ease of finding answer quickly, and providing comprehensive guides on big picture items, we tried a few possible solutions:
Search Bar for speed of discovery
Central menu for maneuverability and ease of access
Breadcrumbs to prevent getting lost
Surface popular articles or comprehensive guides to the generally confused
Third party service with engineering support and admin dashboard
One thing that my CEO insisted was that the content should retain its long form format. He had wanted to emulate a medium-type style and wanted to prompt users to read beyond the answer they were looking for. Also, since we have two distinct user types that may not often overlap, we needed an UX that supported this split. I tried a few different information hierarchies with my team, as well as some possible ways of displaying search results.
After a few tries we were able to decide on a layout.
Let’s see the final thing
We opted for a two level navigation: the four categories of content (on top) vs table of contents within each type (on left). This helped us organize and declutter the knowledge base and also created a clearer sense of hierarchy. We also added a search bar that is always present, regardless of where you navigate to.
As you scroll down and reach the end of each answer, you are taken to the next question without interruption. The left menu is sticky to provide context and easier navigation.
Some other details include the ability to link to specific sections within each category. This is to make it easier for support members to directly link an answer if needed.
We decided to add two new sections: The Glossary and Stuff to Read. The latter contains comprehensive guides for those who are looking for a one-stop solution to their questions.
Hopefully by the time they get to the bottom of the page, they’ll have answered their questions already. In that case, they’ll be able to move onto next steps like find a company to invest in, or start their own fundraising campaigns.
We decided to go with a third party service due to the fact that we were tremendously short on engineering resources. A third party service provided a dashboard that allowed each Wefunder team member to edit and contribute to the knowledge base without needing engineering help. This dramatically improved accessibility and empowered team members to take charge of the content. We have been able to improve on the knowledge basely the past few months because of this.
We keep track of what users are consistently viewing and voting as “useful”. This provides us feedback on the resource type that is most effective and the method of presentation that is most easy to discover. Anecdotally, the number of support tickets in the specific bucket related to investor education and FAQ-related requests decreased slightly, though it’s likely an unreliable measurement.
If you’d like to play with the final product, you can go to help.wefunder.com.