The next part of asynchronous design I mentioned previously was about questions.
Questions are simple to fix aren’t they? Craft a FAQ document and away you go. This is where we get much learning design so very wrong. The worst examples of poor design mean we have FAQ documents that:
- Go on for dozens of pages
- Have no index, tagging or search
- Are too general in the question and answer
- Are too specific
- Are used to dump content that doesn’t fit anywhere else
We end up building NAQ documents – Never Asked Questions.
The alternative is to make the trainer the all knowing oracle that centres the questions and responds in a binary way; one to one, usually by e-mail.
If people are learning asynchronously, they will have questions at different times, days, and on different elements you’ll not be able to predict. There isn’t a better opportunity to be more creative and collaborative in answering questions that users might have if you’re designing asynchronous support.
Some options might include:
- You might want to establish a wiki – build a topic directory and create the space for people to add and edit their own content. You’re handing over the responsibility to the group while retaining the accountability.
- Community Q&A – use Yammer, LinkedIn or a Teams space for people to share their questions and, if they’re able, their answers. If questions don’t get answered your next synchronous content writes itself (see the SME example here).
- Comment spaces on blog posts – use blog distributed content to frame space for questions and encourage people to ask and answer each other.
Questions are the most valuable currency for learning; don’t devalue them by resorting to cheap and poor value answers.