WtD Prague: Mapping user experience

This week I’m attending Write the Docs Prague. It’s super exciting to attend a European Write the Docs conference, and to be visiting the lovely city of Prague. This post contains my notes from a talk at the conference. All credit goes to the presenter, any mistakes are my own.

Aaron Collier’s talk was titled, “Seeing your docs through different eyes: Mapping doc users experiences”.

Aaron asked the question, “Why do we document things?” He suggested the following answer: “To help people understand how to achieve their goals with specific tools”.

If we’re trying to help people, we need to understand their goals: what they want to achieve and how they express their needs.

The situation before running user experience (UX) research

Aaron explained how the docs team worked before they started the exercise in UX research.

Most of the input was from developers.

The tech writers were maintaining and adding to existing documentation.

The team didn’t have much direct contact with users or ways to get direct feedback on the docs.

They didn’t work with the product outside their own context. They knew how it was meant to work, and didn’t try to use it from other perspectives.

User experience mapping

The docs team initiated a process derived from the UX discipline. The user experience mapping process is based on customer journey mapping, but maps how people interact with the product. In this case, the product is the docs. The goal is to focus on the touchpoints – where the people interacted with the docs and what their goals were.

The team wanted to understand the entire experience, and how it made the users feel. The context of a person’s feelings can affect their reaction to the touchpoints and the situation they’re in.

Aaron showed some examples of experience maps. A map is based on a timeline, and shows the person’s feelings at each point in the timeline.

The experiences you have at the beginning and end of a timeline are the ones that contribute to a lasting impression.

How to do doc experience mapping

Doc experience mapping entails the following steps:

  • Gather information about the readers. Break the data into categories.
  • Create personas for the readers. These are representations of the users, based on your data categories to help you work with the personas. The goal is to have empathy with each persona, so you give them names, desires, and smiley faces.
  • Meet and go through the journey of each persona.
  • Take action based on the results.

The docs team had plenty of help from the UX team, and melded information from other sources such as analytics, support tickets, and the marketing and sales teams.

Aaron’s team came up with six personas for the docs. He walked us through a couple of the personas.

Next, the team created a map for each persona. The map is based on a possible scenario, and takes the form of a timeline showing what the persona is doing at each point, and how they’re feeling at that point. The timeline starts before the person comes to the docs. Colour coding shows the touch points with the docs.

Working through an experience map

After creating the experience map for each persona, the team worked through the map, discussing the touch points that were not related to the docs, and working through the docs in detail for the doc-related touch points.

While walking through the maps, the team learned a few things. For example:

  • The persona is unhappy before they come to the docs.
  • Every page is page one. The persona doesn’t start at the top and read through the docs. They go directly to the doc they want. The team discovered they needed to add more information to the page to take into account that it’s the first page the persona is seeing.
  • The first example is far too complex.
  • A “Try it” button is not easily visible.

Taking action

The team adjusted the pages to fix the issues discovered when walking through the maps. For example, they made the “Try it” button more visible, and made the examples more consistent.

Some articles started negatively: “You can’t do this”. That does not lead to a positive experience. So the team made sure the article started with a positive experience: “You can achieve something”.

The team also discovered they needed some less technical articles for people who were just getting started with the product.

Aaron noted that this is an iterative process. The team will be doing the UX mapping again soon.

Thank you Aaron for an inspiring insight into UX mapping for docs.

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 17 September 2019, in technical writing, Write the Docs and tagged . Bookmark the permalink. 3 Comments.

  1. Hi Sarah,

    I hope this email finds you well.

    What a lovely blog do you have with interesting topics! I have just written an article about the new standard on user instructions, the 82079: https://instrktiv.com/en/82079/

    Do you offer a guest post opportunity? I could summarize the article if you like.

    Good luck in Prague.



    • Hallo Ferry

      Thanks for your comment, and for the link to your overview of the new 82079 standard. The overview is very instructive, and the new standard looks like a solid improvement. I particularly like the change in the title from “Preparation of instructions for use of products” to “Preparation of information for use…”. It’s also interesting to see that they’ve incorporated the principles of minimalism into the standard.

      Since this is a personal blog, I don’t include guest posts. Have you considered becoming a contributor to TechWhirl? I think your suggested post would be a very useful addition to that blog.


  1. Pingback: Write the Docs Prague 2019 wrapup | ffeathers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: