Author Archives: Sarah Maddox

Catering for novices and expert users at stc17

This week I’m attending STC Summit 2017, the annual conference of the Society for Technical Communication. These are my notes from one of the sessions at the conference. All credit goes to the presenter, and any mistakes are mine.

Laurian Vega presented a session titled “Novices AND Experts, Not Novices OR Expert Users”. I’m very interested in this topic, as it’s a problem that most creators of documentation face: the people coming to your docs may be new to the topic, or seasoned users looking for help with one specific task/concept. How do you optimise the docs UX (user experience) for both types of audience? Laurian’s talk focused on user interfaces. I figure a doc set has its own user interface, and as tech writers we’re responsible for the information architecture of the doc set too.

Laurian is a UX engineer. Her team writes all the words for the user interface (UI) and documentation for around 30 products.

Experts and novice users

Should we have two difference pieces of software to support the two types of users? No, says Lauren.

She showed us Adobe Photoshop as an example of a tool made for experts: graphic designers. But a number of people who are not graphic designers need to use it, and it’s flabbergasting.

People move from being novices to experts. They do this for various reasons, including necessity and initial simplicity of the task. There’s a spectrum of people, from novice to expert. By designing for the extremes, we also cater for the people in the middle.

Novices do well if the UI is simple, and there’s a single, clear call to action. They benefit from tutorials.

Experts know the task they want to complete, and they know how to do it. (Remember, we’re talking about UI here, not the docs.)

Laurian showed the Google search page as a good example of a design that caters for both novices and experts. Note the large expanse of white space, which focuses the user on the main task. The search box is right in the middle, so the eye is drawn to it. There are only two buttons, and you don’t even need to use them. For the expert users, there are extra controls at top and bottom, which you can find if you’re looking for them.

Expert users tend to have extensive domain knowledge. They may not necessarily have knowledge of modern UI design, because they’ve been doing the same task for so long. Expert users tend to take less time to complete a task, and often perform multiple tasks.

If a user doesn’t like your UI, they’re less likely to do well with it. They also don’t tend to spend much time attempting to learn it.

How to design for both experts and novices

Create separate personas to represent novices and experts, and use those personas to step through each task. Aim for 5-7 personas. Laurian walked through some sample personas for novice and expert, using the example of a UI for an online shoe shop. The novice in this case had high domain knowledge, but was a new visitor to the site. The expert had low domain knowledge, but had browsed the shoe shore’s site often.

Make sure you have a persona for the people who hate your UI!

Take a look at for useful resources.

Design patterns

Do’s and don’ts in design:

  • Don’t make separate user interfaces. Design the right tool from the beginning.
  • Don’t ask your users if they’re experts. You won’t get a useful answer. Look at your analytics instead.
  • Don’t use different tones for the two types of users.
  • Don’t test with only one segment of your users.
  • Do provide default options, as they help novices as well as experts, particularly for complex features.
  • Provide both a quick and an advanced search.
  • Provide help text and clear feedback. Avoid big blaring red text. Be helpful without being angry.
  • Allow users to skip or dismiss the help features.
  • If you have a lot of jargon in the UI, which assumes domain knowledge, link to a place where that jargon is explained.
  • Provide advanced options as part of the interaction flow. Use progressive disclosure.
  • Add labels to indicate advanced features. Consider hiding the advanced features until the user has gained enough experience to handle them, but make sure users can see those features if they want to.
  • Take care with custom icons. Icons can offer a quick way for users to find what they need, but remember that novices don’t know the icons. Provide tooltips.

Thanks Laurian for your useful insights into designing for a variety of user experience levels and behaviours.

Emotive analytics at stc17

This week I’m attending STC Summit 2017, the annual conference of the Society for Technical Communication. These are my notes from one of the sessions at the conference. All credit goes to the presenter, and any mistakes are mine.

Allie Proff‘s session had the intriguing title of “My Android Dreams of Electric Cats: Are You Capturing Your User’s Emotive Analytics?”

Allie took us through a fast-paced view of analytics and emotions. She started by looking at traditional analytics: bounce rate, time on page, number of views, etc). But this measures the “what”, and not the “why”. The “why” is emotions: how the readers are feeling when they come to the docs.

She talked about emotions, why they’re important, and the science of emotions. She told the story of Phineas Gage, who had a staking pole punched all the way through his brain, and lived to tell the tale. Later studies have shown that when you damage the areas of the brain that connect your emotions to your logic, you can’t make decisions. You can list pros and cons, but not make the decision.

We actually use the emotional part of our brain to make a decision, then use our logic to justify that decision. Emotions engage more of your brain than logic: 7 areas as opposed to 2.

Significance for technical documentation: Story telling engages emotions, which makes it very powerful. User experience focuses on delight. Gamification is a specific example of engaging emotions.

Emotive analytics

Also called emolytics, or emotional analytics: The ability to measure emotions of your reader, for example through their face, voice, wearables, bio-feedback, or text. For example, Facebook infers emotion from people’s updates.

Affective software is software that can analyse a user’s emotions and provide appropriate responses. As a simple example, you might display radio buttons asking how the user is feeling, then provide textual help based on the answers. Allie gave the example of cheery text delivered when the user is filling in a tax return, if the user says they have children.

A more complex example is voice to text software, which can analyse your words and meaning as it processes the input. Beyond Verbal does voice analytics. Their main focus is health care. You talk into the app, and it tells you how you are feeling, based on your tone, with a view to telling whether someone is well or sick.

Also face detection software, which discovers a face in an image. CV Dazzle is a website where you can find out how to trick face detection software. For example, cover up the bridge of your nose between your eyes, and add asymmetrical patterns. Sunglasses dont work. Affectiva provides software (Affdex) that can quantify emotion, such as joy, surprise, anger, based on your face as you watch a video. There are SDKs available for developers to use. A cat scored 99% disdain.

There are a number of companies providing affective software. Allie’s presentation deck lists a number of them.

Allie also showed us some companies producing robots that show or teach emotions to some extent.

Thanks for a fun and informative session, Allie!

APIs, maps and apps at stc17

This week I’m attending STC Summit 2017, the annual conference of the Society for Technical Communication. This post is a summary of the session I presented.

My session was titled “A tech writer, a map, and an app”. I told the story of my odyssey into app development, and used my own journey as a way of teaching attendees about apps, APIs, code, maps, open source, and hackathons.

The slides are available on SlideShare: A tech writer, a map, and an app.

We explored some technical details:

  • The nuts and bolts of a web-based application like Tech Comm on a Map: where it’s hosted, where the data is stored, the JavaScript code and the APIs that create the map and the app’s functionality.
  • How the app’s data is crowd sourced.
  • What open sourcing your code means, and why you may want to do it.
  • The difference between a web-based application and a mobile app. Tech Comm on a Map is available as a native Android app as well as a webapp.
  • The information sources that I used when developing the app.

And we examined how such a project can help develop your soft skills:

  • My engineering colleagues helped me kick off the development of the app, and made ongoing suggestions for refinement. The resulting interactions increased mutual understanding and respect.
  • Fellow technical writers all over the world help compile the data. A project like this is a good way of connecting with your peers.
  • Developing an app can help you better understand your subject and your audience of software engineers and other specialists.
  • Such a project gives you confidence in your own abilities, even if you’re just skimming the surface of code complexity.

There’s more about the app on this page: about Tech Comm on a Map.

Thanks to everyone who attended the session!

Adapting content for usability expectations at stc17

This week I’m attending STC Summit 2017, the annual conference of the Society for Technical Communication. These are my notes from one of the sessions at the conference. All credit goes to the presenter, and any mistakes are mine.

Kirk St.Amant presented a session titled “Prototypes of Use: Adapting Content to the Usability Expectations of Different Contexts”.

Kirk has recently been working on “the auto manual phenomenon”. Think about opening up an auto manual and using the instructions on how to change a tire. Auto companies get plenty of complaints from customers about these particular instructions. At first the auto companies were puzzled, because user testing had showed the instructions were correct and easy to follow. After further investigation, it turned out that people couldn’t use the instructions, packaged as they were in a 450-page manual. Such a large book isn’t designed to be ready on a highway, in the dark, in the pouring rain. It doesn’t lie flat.

In other words, it’s a question of context. Where do readers actually use the doc? We need to focus on the delivery mechanism.

Consider how people use and process information. We associate a particular verbal representation with a physical object. Taking this further: The prototype that we use when we identify something may cause us to deliver the wrong product.

Kirk asked us to play a game, based on Physics or Maths textbooks. He asked us to describe such a book. The audience was unanimous about how such a book would look: Big, hardcover, blue or grey, with atoms drawn on the cover. We concluded that if we saw a thin pamphlet, we wouldn’t identify it as a Physics textbook. Similarly, we described the concept of a classroom.

When someone asks you to create a manual, you’re predisposed to create something that looks like a textbook, and probably something that fits into a classroom.

Instead, we should think: I need to create something that shares information on a particular setting.

We tend to use this formula when thinking of usability:

Content+audience = design

Instead, we should focus on:

Content+context[audience+setting] = design

Kirk now did a deep dive into defining the context of use, using a series of formulae and process maps to define the concepts and flows, illustrated by real-world examples.

Some cool terms:

  • a prototype jam – what you experience when you get stuck because some part of a familiar workflow is suddenly absent.
  • context mapping – a process for describing the objective, setting, and sequence of actions, for various contexts (objects, individuals, access points, exit options).

In response to a question about applying the results of a usability study: Kirk described how his team adapted the instructions for measuring blood pressure, based on the patients’ experiences using a blood pressure cuff and attempting to read a heavy manual simultaneously in order to report the results. Instead, the team substituted a voice-activated mechanism for reporting results.

The idea is to get engineers/designers to think about context at the start of the design process, so that content conforms to context.

Thanks Kirk for an educational, authoritative look at modelling usability and context.

What readers want at stc17

This week I’m attending STC Summit 2017, the annual conference of the Society for Technical Communication. These are my notes from one of the sessions at the conference. All credit goes to the presenter, and any mistakes are mine.

Yoel Strimling presented a session titled “So You Think You Know What Your Readers Want?” He presented the results of a study that measured and compared how writers and readers define documentation quality, as well as how writers assume readers define it.

Yoel started by quipping that the most important word in the docs word starts with an F and ends with a ck: … Feedback.

The most important thing for good documentation is to know how well our docs work. For that, we ideally need direct, actionable feedback from readers. We have personas, user stories, use cases, journey maps – to make educated guesses. That’s not the same as actionable, direct feedback.

The definition of doc quality must:

  • Come from a reader’s point of view.
  • Be based on empirical, research-based feedback.
  • Use clear and unequivocal terminology.
  • Cover all possible aspects of quality.

Yoel found a study from 1998, based on 100s of interviews with information consumers, to find out what they wanted from their information. They came up with a framework for defining information qualities based on 4 categories: intrinsic, representational, contextual, and accessibility. Those categories were subdivided into 15 dimensions. Yoel talked us through an amusing illustration of these dimensions, to determine the relative quality of two pens. Part of this illustration involved losing his pen, which was tucked behind his ear!

Conclusion: To be of high quality, docs must be intrinsically good, clearly represented, contextually appropriate for the need, and accessible to the reader.

Yoel then created a survey, asking readers to rank the docs based on the 15 dimensions. He sent another survey to writers, asking them how they thought readers would rank the docs based on those same dimensions. The top results were very similar to each group:

  • Top qualities as judged by readers: Accurate, easy to understand, and relevant.
  • As judged by writers: Relevant, accurate, easy to understand.

But Yoel found 5 dimensions where writers significantly underestimate the value of the dimension to readers. In particular, writers underestimate the quality named “value to readers”. “Valuable” means “beneficial and providing advantages from its use”. Readers want us to give them docs that help them do their job better!

How do we help users to do their job better? Yoel asked the audience. These were some of the suggestions:

  • Make the tools and the docs easier to use.
  • Provide tips.
  • Give the users the simplest flow, and avoid bombarding them with options.
  • Pare down the information.
  • Base the docs on the readers’ goals.
  • Provide videos and graphics.
  • Give the wider context when relevant.
%d bloggers like this: