Have Amazon, Dropbox, Microsoft and Google got their information design wrong?

On an API documentation course we ran for a client yesterday, we showed a number of developer documentation websites, including ones from Amazon, DropboxGoogle and Microsoft. One common theme the delegates noticed was these sites contained a in-page table of contents, or a set of related links, on the right hand set of the screen.

Dropbox API documentation page

You will often hear Information Designers talk about F shaped reading, and that the right edge of the screen is ignored by users. If you put content there, they say, it probably won’t be seen by the readers.

So have Amazon, Dropbox, Google and Microsoft all got it wrong, by using the right edge of the screen to provide navigation? Have the improvements in screen technology and the introduction of tablets and smartphones changed which areas of the screen users notice?

What do you think?

A technical communication user’s hierarchy of needs

At the TCUK 2015 conference, Rachel Johnston mentioned the idea of a content maturity model. We thought we’d take this idea and ask:

Could we develop a model that illustrates a hierarchy of needs for users of technical communication (and in particular, User Assistance)?

A model of what?

We suggest calling this model a technical communication user’s hierarchy of needs. This is because we’re considering the different points where a user interacts with technical communication content, the information they need, and value it gives to them.

It takes a similar approach to the content maturity model Rachel suggested (shown in the photo below), with the least mature organisations providing just the legal minimum, and most mature content systems contributing to branding and evangelism.

content maturity model diagram

A user’s hierarchy of needs also enables us to compare this model to similar models from content marketing and product design. For example, the categories in our model’s hierarchy roughly correspond to Peter Morville’s “User Experience honeycomb”, as well as the key elements in product design.

Continue reading

Squares v circles on screenshots?

We were asked:

“Do you know whether it is better to use squares or circles to indicate something on a screen shot? I use circles with thin border & compliment with an arrow. My colleague uses squares & the Subject Matter Expert prefers circles. I was  just wondering whether there is a best practice for this or not.”

It’s a good question.

Gestalt theory states:

“Elements with a point of interest, emphasis or difference will capture and hold the viewer’s attention.”

This indicates the reader’s attention will be drawn towards contrast, which means the element that is different from others in some way. So there is an argument for having a different shape if that element doesn’t stand out. However, shadows, colour and thick borders can also create contrast effectively.

We would say if you are highlighting a button, or some area that is roughly square or rectangular (such as a window or a field), use a square or rectangle. You can add emphasis by making the surrounding area darker (so the key area is in a spotlight) or perhaps an arrow.

You could use a circle if you wanted to point to a spot or an area that is small in size. Circles require less space, so they are good where you need to have a number of elements highlighted within the same screenshot.

Arrows are often affordances, something that affords the opportunity for that object to perform an action. They are good for highlighting an action. They can also work to help the user focus on an area of a screen, and are often used for that purpose.

It also depends on the graphics tool you are using. If it’s easier to create circles than squares, you’re more likely to use circles. If it’s easy to add an arrow, you’re more likely to use arrows.

What do you prefer: squares or circles? Do you have standards for which to use, and when?

Issues for developers moving from on-premises software to Software as a Service.

On Monday, I spoke at the Visma Developer Days conference in Riga, Latvia, about some issues software companies have to address when migrating from developing on-premises software to Software as a Service.

One of the of the biggest changes is that the revenues are spread over the lifetime of customer – they pay on a monthly basis rather than an initial up-front payment. It becomes vital customers don’t give up on using the software after only a short while, because you won’t have earnt much income from that customer. If the software is difficult to use, and if users cannot find the answers to questions when they need them, there’s a good chance they will stop using the software, and stop paying their subscription fees.

We’re seeing a number of software companies changing their approach to providing user assistance (user documentation). More companies are thinking about it at the start of the project, so they can do a better job of delivering user documentation than they’ve done for on-premises software. They’re seeing documentation as part of the customer journey, and part of the design process.

This is welcome news, although it requires development teams to combine product design with information design. I wonder if there’ll be similar trends emerging at the next conference I’ll be attending – MadWorld 2014.

Topic-based authoring: The undiscovered country

NT Live Hamlet Many software companies, when they start out, provide user documentation as downloadable PDFs or as web pages. As they develop more products and versions, and as they expand into countries that use different English spellings, the amount of documents can grow until it becomes hard to keep all of these documents up to date.

It’s at this point that they tend to call a specialist technical writing company (such as Cherryleaf) to see if they can fix the problem for them. We find they’ve usually had a brief look at a Help Authoring tool, such as Flare or RoboHelp, and can see that it would solve a lot of their problems. However, they’re often not really sure how to use these tools in the best way.

Although topic-based authoring has been around for over twenty years, for many people it’s a completely new concept. It is, to quote from either Hamlet or Star Trek VI, an undiscovered country. Our meetings with them often end up focusing on the benefits of topic-based authoring.

Topic-based writing is an approach where you write a piece of text (or topics) that typically contains a paragraph or two about a single topic. These topics can be combined to create a page in a PDF document, and they can be organised in a sequence to create an online Help system ( See topic-based authoring page in Wikipedia). It’s a modular approach to creating content. The main advantage of this approach is the topics are often reusable; you can save time by reusing topics across different documents, and you can publish the same content to different media. For example, you could use a topic in training courseware, in a user guide and in marketing information.

As each topic is usually about a specific subject, and has an identifiable purpose, it can also help the writer write more clearly. If you need longer articles, you can build these up from the topics you’ve created.

It’s easy for professional Technical Authors to forget sometimes that many people have never come across this approach to writing before.

Why your Web content is like Doctor Who

Doctor Who logoDoctor Who is a popular British TV science fiction series that is celebrating its 50th anniversary later this year. So why is it like your Web content? Let us explain.

Regeneration is a part of life

The many faces of Doctor Who - WikipediaOne of the reasons why Doctor Who has managed to be popular for so long is due to the ability of the Doctor to regenerate: if he is old or mortally wounded, he can transform into a new physical form with a slightly different personality.

Similarly, your content may need to take on different forms over time. You may need to change the way it looks to suit different devices, or modify its personality (the tone of voice).

The basic fundamental story, or content, probably doesn’t not need to change greatly, as its purpose is likely to stay the same. However, it’s important to recognise and accept changes to the presentation format are now a fact of life for your Web content.

The Doctor’s companion

Clara Oswin OswaldIn most Doctor Who stories, the Doctor has a companion who travels with him and shares his adventures. The companion asks questions, often gets into trouble, helps the Doctor, and on occasions, rescues or challenges the Doctor.

The companion shows the importance of explanation – acting as the surrogate audience, asking the questions they may have, giving them important information and providing a persona they can relate to.

The readers of your Web content may also need a companion – someone who can assist them, enable them to have their questions answered. In the world of technical communication, we call this “User Assistance” or “online Help”.

Even the Doctor, one of the most expert of people needs an assistant. There are many times when he is overconfident, makes the wrong assumption, and is helped out of his predicament by his companion. This is also true for your expert users.

The sonic screwdriver

Whenever the Doctor wants to learn about a new world, a new creature or machine, he whips out his trusty sonic screwdriver. It gives him data that helps him understand how to solve his current problem. We need our own sonic screwdriver for our Web content – ways to measure its performance (i.e. if it’s meeting the users’ requirements), discover where the problems lie, and so on.

The Tardis of content

Tardis at BBC TV centre

The Tardis, as nearly everyone knows, is bigger on the inside than it is on the outside.

Unfortunately, only the Doctor knows where everything is located, and we generally only see a glimpse of what’s inside. We know there’s a swimming pool and a library, but often people get lost within the Tardis and end up where back they began.  There’s no official map of the Tardis, as far as we know, and it seems like there’s no logical structure to the corridors and rooms.

This is often the case with your web content. There’s lots of information, but it can be hard to find. If you know it’s there, you can search for it, but often you need a person to guide you to it.

Access to the Tardis is generally limited to those the Doctor invites in (or to those who are given a key). Many organisations take the same attitude to their online Help content: they hide it away from public view and, as a consequence, prospective customers.

The Whovians

Doctor Who fans Flickr image by Jason RiedyWhovians is the name given to fans of Doctor Who. Doctor Who has a huge and passionate following, which means they, in a way, “own” Doctor Who has much as the BBC and its writers.

Today, Doctor Who is a “Second Screen” experience: as people watch the TV show, they also converse on Twitter and Tumblr. The user generated content is an important reason why Doctor Who is so popular today. This can be true for your website as well: your users are part owners of your site and its content; their user generated content can be as important as the content you provide.

What have we missed?

Let us know if we’ve missed out any other links between Doctor Who and your Web content.

(Doctor Who fans Flickr image by Jason Riedy)

New design models for providing end user Help

Ray Gallon has recently completed a series of webinars looking at new models for providing end user Help (A Cognitive Design for User Assistance).

In the third webinar, Ray looked at how people learn today and he suggested a new approach for the future. He used The Common European Framework of Reference for Language‘s description of people’s levels of competences to outline the different ways organisations help people to learn.
Continue reading