Posted by: communicationcloud | September 29, 2011

GUIs, technical communication and The Real World

After Technical Communication UK, a few stragglers were sitting in the bar, and somehow we got talking about interesting it would be to have a museum curator show us round an exhibition, and tell us about how they put it together and decided what to include. Yes, I thought – they’d love it. Why? It’s yet another example of the real-life parallel for the things that software technical authors and user experience designers do in their day jobs.

Here are some my thoughts about other connections between software user interfaces and The Real World. (Before we go further, a health warning: it’s not impossible that a perfectly good analogy is about to be painfully overstretched…)

Comparison #1: Finding things

Imagine you’ve just arrived at the station in a city you’ve never been to before, and you want to get to your hotel. What’s available to help you find your way there? You might have a map, or perhaps there’s an information board at the station, or maybe you know your hotel is in the city centre and you can follow signs to the city centre, where there are then signposts to the major hotels. Or you could just ask people.

I see parallels when you are using new software to complete a specific task or making use of an online support portal to find something in particular – such as information about what to do in response to an error message that’s popped up on your screen. You know your destination (completing the task or finding the solution) … but you have no idea how to get there. The typical aides to help you find out parallel those in the real world:

  • For “map”, read “product manual” (physical or online). It’s independent of the environment it relates to, and shows you a whole range of information – not just what you need to know.
  • An information point is like context-sensitive help (i.e. help pages that pop up when you click “help” from a particular point in the UI) – where you see information presented in a way that is relevant to your current position.
  • Signposts are like field labels, button names and informative text in the UI.
  • Asking people is like … well, it’s the same for software as for navigation, only the people you ask are the software company’s product support team.

Which of these ways of navigation is easiest to use and most reliable? Which of the software UI parallels are most commonly the focus of software company’s efforts? Do these match?

(Update: GPS in your pocket changes the options slightly for way-finding – with many mobile phones you can always get a map of your current location in relation to where you need to go, along with directions to get there.  When I set off writing this article, I was only thinking of the things the city does to help you find your way, so didn’t include this … but of course in some cities there are apps designed to help you find your way around.)

Comparison #2: Travelling

Imagine a slightly different situation: this time, you’ve arrived at the airport and somehow need to get from there to the city centre. You’re probably going to need some transport. At an information desk you find out that you can take a bus which will take 20 minutes … or you can take a train, and then change to an underground train – all of which will take 35 minutes. It’s clear what the fastest route is, but in my experience it’s much easier to be confident of travelling by train than by bus in a new city – because it’s often tricky to work out where to ask the bus to stop. (Then again, I once got lost changing trains in Vienna, because I don’t speak German and didn’t work out that I actually had to come out of the station and cross the road to another station.) So there are decisions to make when you choose how to travel: speed or ease? taking a direct route or taking the route you feel most confident about? Of course, in an ideal world the fastest, most direct route would also be the one that is easiest and makes you feel most confident…

In software, there’s a lot that the UI can do to make it easier to get to where you want to go. For example, using well-established design patterns and familiar terminology on buttons and field labels can help with confidence. Designing workflows that match the users’ mental models of what they’re trying to do can make for ease of use; and making those workflows straightforward – with no need to open several dialogue boxes and minimal need for complicated decision-making – can help with speed.

There’s a similar parallel in the design of help systems. When a user wants to find out how to perform a specific task, the easiest thing to implement, as a software company is:

  • You expect them to take the familiar but indirect route of opening a separate help system and find their way to the relevant section. The instructions tell them how to perform the task. They go back to the software, and do as the instructions tell them.

But that’s a bit roundabout. You can make the journey shorter by doing things like:

  • Context-sensitive links in the UI, to get the user straight to the right section of the help.
  • Information in the UI, rather than in a separate help system – e.g. text in the UI, pop-ups, or tooltips.

Or you can make the journey easier for users. Once they’ve found the right section of the help, instead of them needing to find the right part of the UI to perform the task, you can take them directly there. Microsoft do this in their Windows 7 help (and Vista too): Look at step 1 in these instructions: instead of telling me how to open a dialogue box, I can just click the link to open the box. Nice shortcut.

(screenshot from Microsoft Windows 7 help)

Desire paths

When it comes to travelling, the concept of desire paths is also worth thinking about. Desire paths represent the shortest or most easily navigated route from one place to another. People continue to try to travel these paths, even when the layout of a building or park makes it more difficult from them – e.g. they’ll climb over a low fence and walk across the grass, rather than on take the official path that’s been laid out around the area. The phenomenon is used in town planning and architecture, but I think it’s also relevant to information architecture – studying web analytics often shows up particularly well-travelled routes from one part of a site to another; and in usability tests it’s very common to see different people repeatedly look in the same place for a button or function – even when the UI tries hard to make the function highly visible in a different part of the screen. I suspect there’s a close relationship between desire paths and design patterns.

I wrote about the connection between desire paths and information architecture  in a previous post, too…

Comparison #3: Exploring

So, you’ve reached your hotel and had a good night’s sleep. In the morning, you decide to explore this new city… so you step out of the hotel to take a stroll. What helps you decide which direction to go in? I look for routes that are going to go somewhere (not dead-ends), buildings that look unusual, sign-posts to places of interest, streets or parks that seem to be nice places to sit. I avoid areas or streets that look dangerous or unpleasant. In short, I look out for signals that something is interesting – and balance that against potential risks.

And again, I see similar in the UI. In an ideal world, it doesn’t only support people who have in their minds a specific task (= destination, in my city analogy); it also needs to support the many users who like to find out what the software is capable of through the UI. In this context, it also has a job to do for the software company: helping to get users to fabulous functionality that they might otherwise not realise is there. To do this, the UI needs to offer enticing features to users, and make them feel confident they can click buttons or change settings without disasters occurring.

The UI can present interesting avenues of exploration through items on screen or on menus… or through embedded user assistance, such as showing tips on start-up or informative tooltips. Users can be reassurance that they’re not in danger of making any disastrous irreversible changes to their systems or data by similar information mechanisms, along with careful UI design.

Comparison #4: Learning

After lunch, you go to the city museum, where you hope to get some additional context for your current small amount of knowledge about the city. Taking the bus and following sign-posts (or whatever means of navigation and travel are available), you arrive there easily. The museum lays out the history of the city in different phases of time: prehistoric, classical, medieval, industrial, modern … Or maybe the museum explores the city’s past in a different way – with areas on living conditions over the different periods, health, commerce, leisure… Or maybe it does a combination of both: a temporal layout, along with special display boxes on health, commerce, and so on. Some museums guide you through passageways that take you past displays in a specific order; others let you move around the room in the way that you choose; I’m not sure which this fictional museum in an imaginary city does, but one way or another the curator has made some decisions about how the information is grouped and how far it’s up to you to decide how to move around it.

And this brings me nicely back to the topic that got me thinking about this article: I think the reason technical communicators would be fascinated to hear about museum design is that museums are quite like help systems. One of the functions of help systems is to enable users (or, just as often, potential users) to learn about the product: what can it do, what it looks like, what it’s like to work with it. I’m not sure how common this is, but I’ve seen plenty to indicate that this is one of the ways that help systems are used. This makes the help system not at all dissimilar to an exhibition in a museum (though I don’t mean to suggest that help systems are museum-pieces!) – a place that you can go to find out what there is to know. Not just for finding out something specific, such as how to complete a task or what to do if you get an error message. The choice of groupings of objects and information is very similar to taxonomy; the options of guiding people around are really quite like tables of contents, sets of links, or other information architecture objects.

And in case you’re finding my analogy a little stretched at some point: it’s not all my fault! The field of content strategy has picked up the same thread, defining the activity of “content curation”: managing “content” in a purposeful way – in the same way as you might if it were a museum exhibit.


To sum up…

I firmly believe the things we try to do in software UIs or help (which I see as an extension of the UI) have parallels in the things we do in the real world. I think there’s a lot we could learn in the world of software from the real world. I’ve read some articles and had occasional conversations with other people about this, but I’d love to talk to people more about how these similarities can be applied to improving software usability.

Are you a museum curator?

By the way, if anyone who curates museum exhibitions would like to come and talk to a group of technical communicators some time, do let me know. We’d love to have you.



  1. I’m not sure which I find more intriguing about this blog post–the fact that you are stressing the important overlaps between UX and tech comm (something I just posted on today), or that fact that you want to bring a museum curator in to talk to a group of technical communicators! I have been talking for some time here about how there’s a great opportunity for technical communicators in the field of public scholarship & museum curating. I would love to hear more on this in some future post.

    • Thanks for the comments. I read your blog post ( I agree that the connection between UX and techcomm needs exploring – for some of us it’s so obviously connected that we forget that for others the relationship is difficult to see.
      My own approach is to treat tech comm as part of the UX of software – part of the experience of using software is learning about it, making decisions about how to use it, and fixing it when things go wrong, and I don’t think that can all be done in the UI (see earlier blog post about this: – though a lot of it starts there.
      Of course help systems, support sites, and so on have their own UX to worry about too…

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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


%d bloggers like this: