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.