Writing for user interfaces

A blog about UI writing, good and bad. By Beth Aitman, a technical writer in Cambridge (UK).

[uiwriting]

Information design for a Slack bot

One of our developers was trying to make it easier for our colleagues, after they’ve reviewed a pull request (PR), to keep updated on that PR’s status. This developer was building a Slack bot to do this. I offered to help - it seemed like an interesting information design problem.

Their initial design

This isn’t ideal. It needs a legend to explain what all the symbols mean: the concepts they’re trying to communicate are not simple, and just can’t be summed up neatly by an icon. It’s also hard to get information out of this at a glance.

It turned out that our developer assumed they needed to use a table - and because they were using a table, they had to use emoji-only headers, otherwise it wouldn’t fit horizontally.

(For those not familiar with Git and GitHub: the first bit in the pull request column (eg “platform”, “everything”) is the name of the code repository; the number is the ID of the pull request; and the rest is the pull request’s title.)

A quick fix

Firstly, I had a go at a minimal redesign. I felt like the table was causing problems, so I tried to find a different format for the information:

I wanted to do something that would be low effort to implement, making it really easy for our developer to improve the information design. It can be done totally with text and basic markup: doesn’t need any fanciness to implement.

I also wanted to keep some elements of their design. A total redesign can come across as harsh criticism, and I was basically rewriting all the text they wrote. So I kept some of the clearer emojis, and some of the structure (using “=” signs for the dividers).

This redesign takes up more space than the original. But that’s fine! Conciseness is important, but clarity has to win out. This design doesn’t require a legend, because it uses clear text labels to replace most of the emojis. It uses phrases (eg “5 new commits”) rather than numbers in a table.

And the whole thing is much more readable. The users of this bot are trying to find out what’s changed since their last review, so they know what they need to do. This design focuses on efficiently getting them that information.

Something a bit fancier

Then I discovered attachments! This was pretty exciting, because you can use them to format bot messages in a much nicer way.

I actually really enjoyed using Slack’s documentation around these. The Introduction to messages gives an overview of what’s possible with messages and attachments, and also gives a sense of what the features are for. There are some helpful Guidelines for building messages that look more at the UX side, and what best practice looks like - particularly if you’re implementing a more complicated workflow. Then the page on Attachments is what helped me understand the range of possibilities of the format.

But my favourite bit was the Message builder. It lets you really quickly prototype a message (including attachments), refreshing whenever you make a change so you can see the effect. I had a lot of fun playing around with it, it’s a great tool.

I ended up with this:

Just using the built-in formatting options means we could create something that was much easier on the eye. It has a few other improvements too:

The heading is now a link to the PR, which is obviously useful.

I moved the “build” section earlier - because if the build is failing, users probably won’t need to re-review the PR yet. An example of failing users faster.

Using the “short” format for fields lets it make better use of the horizontal space.

In the abstract, I think this is pretty decent now. The next step would be user testing - seeing whether we’re actually including the right information here, and checking which bits matter the most to users.

[uiwriting]

A nice piece of help for Instagram Stories

I came across this the other day when looking at Stories on Instagram (photos that play like a slideshow, and only last 24 hours). Stories take up the whole of your screen, and don’t have any obvious controls, so it can be a bit hard to work out what you can do, apart from sit there and watch the photos progress.

And there are actually a bunch of gestures you can use to interact with them - which, like many gesture-based controls, are very hard to discover.

So when this screen popped up when I opened a story the other day, I really appreciated it.

Why is this good help?

It’s at the point of need: I can see this and then immediately try out the features.

It combines visuals and text for clearer explanations: it’s not always obvious what the words used to describe gestures mean, so this reinforces the meaning.

It’s short and sweet: uses simple language and clear descriptions.

Any problems?

There’s no way to come back to this help - that I could see, anyway. Once you’ve tapped away, it’s gone. So you have to remember what you see on this screen.

So this screen helps a bit with the discoverability problem - but it’s a one-time intervention that doesn’t solve it entirely. 

[uiwriting]

Writing can’t fix bad design

This door from a train toilet is a great example of adding lots of information in an attempt to fix bad UI design.

What’s wrong with this design?

Usually, the way you interact with a door is signalled by cues on the door itself - for example a handle to open it, a bolt to shut. When these perceived affordances of how to use a door are obvious, you don’t need to add any words to explain how to use it. (Of course, badly designed doors are everywhere.)

For this door, instead of interacting with the door itself, you interact with these buttons. They’re labelled badly with unclear icons. (Icons are almost never as clear as you think they are, but that’s a rant for another day.)

You can tell they’re bad because the design had to add words *on top of* the icons to explain what they mean. And then also arrows next to the words, because the labels were badly placed, making it unclear which button the labels were for.

But even that isn’t enough to explain how to use this door.

The design itself communicates poorly

When you push the “Close” button, it’s not obvious that you need to do something else as well in order for the door to lock. (Which is reasonably important in a toilet door.)

You can tell this has been a problem  -  there are three separate places where extra text asks you not to forget to push the “Lock” button. There’s piles of information around this design, trying to help people to use it successfully.

Telling isn’t the right solution

The door design fails to make it obvious what its users need to do, and adding signs off to the side doesn’t help. Many won’t notice the signs because it’s not where their attention is at the time  -  they literally won’t see the text telling them what to do.

What’s needed is a design that guides users towards what they need to do, or even better, does it for them. It needs obvious signalling. Clear communication. Understanding of how people behave, and anticipation of what they’ll do.

When the problem is “people aren’t using this design as intended”, the solution isn’t “tell them to use it properly”. It’s “make a better design”.

[uiwriting]

A nice, simple login page

A page for logging in isn’t a complex idea, but often they’re overdone, overcomplicated, or confusing. So I wanted to call out a nice example with decent writing, from Trello:

Good things here:

A clear title, reminding you where you are and what’s happening.

Straightforward labels. Looking out for users who want to log in with a username, not an email. 

Good placeholder text reinforcing what goes in the fields. But it keeps labels outside the field too, so users don’t have to rely on it.

A clear, primary call to action. (I wish they’d used sentence case, ie “Log in”, but you can’t have everything!)

The secondary options are still here, obvious but unobtrusive. They’re cleanly and concisely phrased, targeting users with questions and giving them clearly phrased actions to follow up with.

I also liked the error message I got when I tried to log in:

For me, it’s a great example along the lines of the Voice & Tone guidelines on errors: it’s calm, serious and straightforward, and offers a next step. It shows you don’t need to be formal, stuffy or alarming in error messages. And actually, I’d argue that a conversational (if serious) tone here is exactly what a user needs in an error case.

I like the contents of the message: the information it gave me about what was wrong guided me towards what I needed to do next, and helped me understand. Not everyone agrees, and it’s true that it goes into possibly unnecessary detail about the implementation of Google account authentication.

An alternative, rephrasing the detail so it’s relevant to the user, is “You signed up with a Google Account, so you can’t log in with a password. Try using the Log in with Google button.” 

What would be super nice is if the message itself contained a link to the ‘Log in with Google’ page - so you don’t have to look around the page to find the link. But as the page is so minimal, it’s not too much of a problem.

[uiwriting]

How human do you want your chatbot to be?

I’ve seen a few examples recently of people frustrated with chatbots that just don’t understand what they’re trying to say. 

Because a chatbot’s UI is conversational, people building them want their bots to be bursting with personality - and to seem like real people. Conversation gives the illusion of humanity: it makes users feel like they can speak and be understood. But the more your users feel like they’re talking to a human, the more they’ll talk like they talk to other humans. 

And that’s a problem for bots. Most of them have a very limited range of what input they can understand, and aren’t very tolerant of variation:

My CNN bot already feels a little bit spammy. Cute emoticons don't really cut it in this case... pic.twitter.com/9EY7gBwyMQ

— Olivia Solon (@oliviasolon)

April 13, 2016

Natural language processing needs some work. pic.twitter.com/Sbm6HqKyq1

— Benedict Evans (@BenedictEvans)

April 14, 2016

It turns out the secret is to say "unusubscribe", but nothing else. That's a discoverability problem. The great advantage of a graphical (rather than conversational) user interface is that users can see what’s possible. To replicate this with a bot, you would need a list of options - sort of like a call centre. “Press 1 for today’s forecast, 2 for tomorrow’s, or press 3 to unsubscribe.”

Now, a bot like that doesn’t give you the illusion of humanity. What it does give you are decent odds of user success. Even if your user doesn’t reply “1″, and instead says “Today’s forecast”, you’ve given them language that they’re likely to mirror - language you can add to your list of things your bot recognises. 

In the CNN example, the bot had an unsubscribe feature - it just didn’t tell users that it existed, or how they could access it. Bots need to communicate their capabilities - and their limitations. It’s a trade-off between conciseness and usability, and between perceived humanity and user success.

To try to help, you can:

remind your users that they're talking to a bot, not a person

tell your users what the bot can (and can't) do

give your users the language you want them to use, to make them more likely to say things your bot can understand

If you're building a conversational UI, consider: do you want your bot to come across as human? Or do you just want to help your users get stuff done?

Other posts I thought were interesting:

Dan Grover on the limits of conversational UIs

Amy Thibodeau on other reasons to be careful about adding lots of personality

[uiwriting]

Don’t forget about empty states

Today’s post prompted by this helpful piece of copy from Fitbit:

Why are empty states important?

When you’re designing software, you spend most of your time thinking about what it’ll be like when users are interacting with it normally. It’s easy to forget about what it looks like when there’s nothing in it. But that’s often the time users need your help the most, because without any content, it’s hard to work out what something does. 

In the Fitbit example above, I have no idea why it’s not showing me anything (and clicking on the gear icon doesn’t give any clues). They haven’t thought very hard about the copy, either about how to explain why there’s nothing here, or what I need to do to add something.

If you’re not careful you can end up with this kind of depressing view, with no idea how to get some content in here (thanks screenshots of despair):

Something better

For starters, explain what the next steps are, like Google Drive does here:

WhatsApp goes one better, with clearer instructions on finding that button:

Even better, don’t make users go hunting for a button somewhere else - make them part of your empty state. (via emptystat.es)

In short:

Think about what your software looks like when there’s nothing in it 

Work out how your users can make it not empty

Make it really easy for them to do that

[uiwriting]

How not to do customer communications

It shouldn’t be a surprise that npower’s customer service is terrible. After all, it consistently gets the lowest customer satisfaction ratings of any UK energy company. 

But as I’ve just been on the receiving end of their service, I thought I’d share the experience, because their communication is incredibly poor.

The background

My partner and I recently decided to change the bank we use for our joint account. This should be an easy process: all the money in the old account, and the old direct debits, get automatically transferred over to the new one.

Which is why I was just a bit surprised when this appeared in my inbox:

The confusing, scary email

It begins:

Dear Miss Aitman

Your bank has been in touch to let us know that your account has been transferred to a different bank or branch. Unfortunately we’ve been unable to collect your regular payment.

“We couldn’t collect your payment” - that says I’ve failed to pay a bill. That could affect my credit rating. So that’s pretty bad, right? 

It’s also a lie. In fact, our payment date is in a week or so - so they haven’t even tried to collect the payment yet.

Contradictions galore

The email goes (extracts):

Unfortunately we’ve been unable to collect your regular payment.

This change has meant we may have been unable to collect your recent payment.

If this has happened we’ll try again within 5 days.

Hang on - “may have been unable”? “If this has happened”? So maybe they haven’t failed to collect the payment after all.

It continues:

In future we’ll continue to collect your payments as normal.

Because your current tariffs are only available if you pay by Direct Debit we’ll also need to transfer you to a new contract on our Standard tariffs shown over the page. 

This new tariff may cost you more and unfortunately you will also lose the discount you currently receive for paying by Direct Debit.

More contradictions: “We’ll continue to collect as normal” vs “We won’t use direct debit any more”. And more worrying information - this is going to cost us money.

The main bit of the email finishes:

We know it can be hard to stay on top of the bills sometimes. If you’re finding things difficult, please get in touch - we do want to help.

That implies, pretty heavily, that we’ve missed a bill payment, and we’re in trouble. Of all of the bits of the email, this scared me the most. 

(I’m not going to go into detail about the rest of it, which is 400 more words of contact details and information about changing suppliers. You can read the full thing here.)

What actually happened

I immediately got in touch with npower support. Who told me:

Yes, the direct debit has been cancelled, but a new one will be created imminently.

We haven’t missed a bill.

They haven’t changed our tariff.

So almost all of the information they emailed us was actually false. I didn’t need to contact them, because everything was proceeding normally. 

Conclusion

This email is full of lies, contradictions, and misinformation. It repeats itself in subtly different ways, so its meaning is completely unclear.

It makes me scared that I’m going to have my credit rating downgraded for missing a bill payment, and that something’s gone wrong with my bank account. God knows how it would feel to get this as someone vulnerable - how terrifying would this be for a poor pensioner?

The only sensible response when you get this email is to contact npower. That’s the only way to find out if you’re in trouble or not.

In essence: this email is shit. It has no consideration for npower’s customers, and is designed to scare them. It’s expensive - it increases npower’s support burden and costs them money. The only responsible thing for them to do is rewrite it to give their customers the (accurate) information they need. 

Seriously, npower. It’s not difficult to sort out. Get in touch, I’ll give you a hand. 

[uiwriting]

Are you sure? How to write a confirmation dialog

I came across a few terrible confirmation dialogs/“Are you sure” messages recently, like this one:

As they’re so common, I thought I’d go through some examples, and discuss what works and what doesn’t. 

Confirmation dialogs can be useful, in situations when a user chooses to do something that has bad or unexpected consequences. They aim to make sure that the user knows what they’re getting themselves into - or out of. 

Do you really need a confirmation dialog?

Be sparing with confirmation dialogs, because they’re only used when you think that the user didn’t really want to do what they just told you they wanted to do. If they did want to do it, and they can easily undo it, a confirmation is just irritating.

A better alternative is the option to undo an action, allowing a user to easily change their mind. Undoing means you don’t need to second-guess whether your users wanted to do a thing or not. Google apps do this pretty well, even letting you change your mind about sending an email:

But in some cases - particularly for irreversible and damaging actions - they can still be useful. So how do you write one?

The traditional Windows confirmation

Here’s an example of a classic confirmation dialog. The user opted to do something potentially damaging, so it checks that they definitely want to:

However, the action here isn’t actually that damaging. It’s not irreversible, like deleting something permanently, as it’s easily fixed by undoing. A confirmation dialog isn’t *really* needed here.

The wording, “Are you sure you want to do the thing?”, can be cut down. “Do the thing?” is shorter and (usually) just as expressive.

The button options are Yes/No, but using these can make it harder for users to make a decision. They might have to read closely to understand what they’re choosing, like here:

(To be fair, that dialog has bigger problems. The reason it’s unclear is not just that it’s a wall of text, but also that the question doesn’t have a Yes/No answer - it’s “Do you want this thing or that thing?”.)

Making the choice clear

A confirmation dialog is asking users to choose what they want to do - so you need to make sure that choice is clear. That involves:

Making sure the user knows what consequences of the choice are

Reinforcing the choice in the button text

Clear consequences

The best time to use a confirmation dialog is when the user might not know their actions could have bad consequences. (For example, when deleting a file could stop your computer working properly.) To make an informed choice, they need to understand those consequences. 

If you don’t make it clear, it’s very difficult to make a decision. Take this example:

It’s so badly phrased, it’s not clear what will happen when you choose either of the options. As a user, you don’t know what you should do. 

It isn’t easy to make technical information like this simple for users, but it’s worth it - it makes the user experience so much better. In this case, the message could be something like this:

To refresh this page, Chrome needs to resend the information you entered. Any actions you took (like making a payment) might be repeated.  Refresh/Cancel

Focus on the button text

Be wary of adding lots of explanation in the confirmation message, though. The more you add, the less likely it is to be read. And if you’re writing for mobile, you’ve got very little space to play with anyway. 

But if users read nothing else, they’ll look at the buttons. So instead, focus on the button text, because you can use it to make the choice you’re offering clear.

Using Continue/Cancel or Continue/Close is a good pattern for this. You can also go for “Do the thing”/Cancel, as per Google’s Material Design guidelines:

For particularly dangerous actions, you can use the button text to make them hesitate, heavily implying which one the user should choose:

Cancel cancelling?

Of course, that wording can backfire - when the action itself is cancellation:

In this case, there are a few better options:

Replace it with a Yes/No question, eg “Cancel this process? Yes/No”

Be a bit wordier and more specific, eg “Cancel this process? Yes, cancel process/No, continue with process”

So, to sum up

Check your users actually need a confirmation

Clearly explain what the consequences are

Write concise button text that makes clear what they’re choosing

(Thanks very much to Philip Guo and Zara Sheldrake for the ‘cancel cancelling’ screenshots!)

[uiwriting]

A bit of news

Sorry for not posting in a while! I’ve been away because it’s been a busy few months. In part because things have changed a bit - I’ve just started an exciting new job working at Ocado Technology (the tech company behind the online retailer). They’ve just created a technical writing team: I’m the latest to join a team of four.

It’s pretty different to my previous job! The tech comms team sits together, so I’ll be spending a lot more time with writers than with dev teams. My commute’s also expanded just a bit - from a 10-minute cycle through fields to 1hr on the train (and some cycling at either end). I’m quite enjoying the train though, as I’ve been getting some quality reading time. 

Anyway, things are starting to settle down now. So I should have some more blogs on the way for you soon :)

[uiwriting]

A flight for Mr Seat Cello

This week I came across the hilarious page that is EasyJet’s policy for carrying musical instruments on board:

(I increased the font size on that, because it’s way too small.)

The problem

This is so wordy, and difficult to follow. A lot of the content is being defensive about their strange policy - tons of words are wasted trying to justify it. I’m not sure this is necessary. “Rules is rules”: all big instruments have to go in the hold, except cellos. If that’s the policy, that’s the policy. 

But what a bizarre system - Mr Seat Cello? Really? What happens at when I check in online - do I have to make up passport details for my cello?

Clearly the way of doing this is stupid. But I’ve been in situations where I’ve had to write about something stupid, and there’s no way of fixing it. Take the example of a searching tool I worked on. The advanced search syntax was a ridiculous way of supporting Boolean operators. The implementation wasn’t my decision, but that didn’t matter - I still needed to explain how it worked in a way that our users could understand.

Sometimes the stupid is out of your reach, and you won’t be able to change it. Sometimes you have to write about things that you know are ridiculous.

The fix

I had a quick go at rewriting it. I added headings (to help users skip to the section that applies to them), simplified the language, and cut it down by about 40% (from 340 words to 195).

It could still be improved - I’m not sure about a couple of things:

I’m not sure about removing the list of instruments - that could be the thing that’s most useful to users, rather than a set of dimensions. That’s something that could be worked out in user testing, though.

Should I have left the insurance recommendation in? It didn’t seem to add anything.

The ‘one item of hand baggage’ bit could still be clearer, but that’s mostly because I didn’t understand what the policy actually is. Do they get to carry an extra bag or don’t they?

Conclusions

Writing explanations of stupid things can be really frustrating, because it’s often obvious how the thing could be made less stupid. But it’s a useful exercise in writing clearly in all circumstances.

EasyJet probably won’t make a better system for booking a seat for a cello. So in the meantime, they could at least explain clearly how you’re supposed to bring your instrument on a plane.

[uiwriting]

Log in? Sign in? Sign up? ... Log up?

There’s been some discussion at Redgate Towers this week about what we should call the action of getting access to your account. Our style guide, at the moment, says “Log in”, but one of our UX designers thinks “Sign in” is friendlier. 

The style guide’s always evolving, so I thought I’d investigate to see if we should change it.

The arguments

We had some chats internally, and I had look around online, and honestly: there aren’t many rational arguments to support one or the other.

The only strong argument I’ve seen is that you should use different verbs for logging in and signing up. Users need to be able to distinguish between them at a glance. Otherwise they’re much more likely to pick the wrong one - they’re not going to slow down and read the text. (See this article for more on that.)

As for choosing between the words: “Log in” has a more technical flavour than “Sign in”, but only a little. That’s pretty much all that’s between them.

Oh, and please do one thing for me: don’t use login as a verb. Here’s a site explaining many reasons it doesn’t work. If you must use login, it’s a noun or adjective, eg “I’ve forgotten my login details”.

What does everyone else do?

Often, making the right choice comes down to picking what people are used to. So I had a look around to see what some widely-used websites do.

Amazon: sign in and create account/register

Apple: sign in and create account (well, Apple ID)

Basecamp: log in and start a trial

Ebay: sign in and register

Facebook: log in and create account

GitHub: sign in and sign up

Google: sign in and create account

Mailchimp: log in and sign up

My Atlassian: log in and sign up

Office: sign in (although they use ‘login’ in the URL, consistency fail) and sign up

Slack: sign in and create an account/sign up 

Btw, I don’t think Slack are being inconsistent here - they’re using “Create an account” and “Sign” up to mean two different things.

Twitter: log in and sign up

Where does this leave us?

Sign in: 7, vs log in: 5. 

Sign up: 6, vs create account: 5. 

Clearly, both versions are widely used, which means whichever you choose, people are likely to understand them. There’s not one that stands out as better for users. So I think it just comes down to what you prefer.

I prefer the Log in/Sign up pairing - it seems neat to me (probably because it’s short). But Sign in/Create account is widely used too, and there isn’t much wrong with it. I like that a bit less, because it’s slightly longer. And our UX designer was worried that “Create account” wasn’t friendly enough. 

Above all, be consistent

It doesn’t matter much which one you pick - what matters is that you pick. If you choose “log in”, use that everywhere, and use “log out” correspondingly. And make sure that it’s visually different to what you use for “sign up”. 

Let’s finish with a bit of history

On a side note, why is it even called logging in? Turns out the word log, in this sense, comes from logging an entry in log books - which are named after the logs thrown over the side of a boat to measure its speed. 

Thanks to DesignCult’s The secret origin of log in for that!

[uiwriting]

Bad writing and anti-patterns on the Royal Mail site

It’s a familiar part of signing up for a website or service: opting out of any marketing emails.

And the forms are often deliberately designed to make it hard to work out whether or not you’ve opted out. I assume it’s because they’re trying to trick you into consenting?

Here’s a particularly confusing example, from Royal Mail.

The problem

There’s a lot of wordiness here, and it all seems design to obfuscate the meaning, making it hard for users to make a decision. 

I think that’s why there are so many unnecessary bits of text. It repeats itself a lot. It explains how to use the UI - eg “please tick the relevant options below”. 

“We will only send you information on these topics if you have opted in” - yes, that’s the point of the form, implied by “please send me information about”. It’s obvious. 

“Click on the Register button to submit this form and indicate your consent” is, superficially, explaining that these checkboxes are for opting out. But because it’s in a dense paragraph of text, it actually hides that information. You have to read it closely to find out what you need to do to not get sent anything.

The separation between the different “Keeping you informed” sections is pretty unclear. Are the “products, services and offers” in the second section the same as the "promotions” in the first section? As a user, it’s not obvious what you’re consenting to.

The worst part of the whole form is the use of both opt-in and opt-out checkboxes. If you select the middle set of checkboxes, you’re opting out.  If you select the last set, you’re opting in.

That’s a nasty anti-pattern. Users expect a control to act in consistent way - that’s what you signal, as a designer, by using a control more than once. Doing it this way is deliberately confusing. 

“Keeping you informed” is very weaselly, too. It feels dishonest.

The fix

This form boils down to something fairly simple: what can we send you information about, and how?

Title: Contacting you

Can we send you information and updates about:

Stamps and collectables

Sending mail abroad

Sending mail within the UK

Promotions

Other Royal Mail and Post Office products, services, and offers

Third-party products, services and offers

Can we contact you by:

Post

Phone

Email

SMS

Eg:

A caveat

I don’t work in marketing or sales. It’s possible that tricking your users into agreeing to get emails is an effective strategy for selling them things. I doubt it, but it could be true. 

But even if it is - forms like this treat your users badly. It’s disrespecting them and their wishes. And it leaves a bad taste in their mouths. 

[uiwriting]

4 practical things you can do to improve the writing in your UI

I gave a talk at Write the Docs this week, about how to write well for user interfaces. The video of it should be up soon - I’ll share it as soon as it gets posted. 

In the meantime, if you want some immediate steps you can take to make your user interface better, here are four ways to do it.

1. Don’t name things in your UI after things in your codebase

Or at least, be really careful before you do it. What your code does internally is rarely the same as what it does for users. 

Take the Cascade example. Internally, this button is adding a record. But for users, it’s letting them book a holiday.

Or the Google Drive example. Call something what it does for users, not how it works internally.

2. Explain what’s going on out loud

It’s hard to get phrasing right the first time, especially if you’ve not got much space. And if you’re not careful, it’s easy to write in a way that sounds robotic.

So start by explaining what your feature does out loud, in a sentence or two. How would you tell it to a person? Then write that down.

Because people speak like this:

Not like this:

Once you’ve got the meaning right, you can start cutting it down to the right size. Or if you need to, you can put your sentence into the UI, as embedded help.

3. Work out what’s blocking your users

Embedded help can get your users past obstacles. Work out what they need to know to complete their task, and put it in the user interface. 

If it’s essential information, and you’re leaving it out - how are they going to get past that point?

4. Write error messages that help users recover

The most important job of an error message is helping users move on from the error.

So tell them what they can do to fix the problem. If it’s just refresh or retry, say that. And don’t hide it away like this - make it clear like this. 

Be specific if possible - tell them exactly what they need to know to fix, avoid, or work around the problem. 

That’s not all

These are just a few tips, but there are so many more ways you can make the writing in your user interface better. I’m trying to put together as many examples as I can. 

So if you’re interested, take a look at the rest of my blog. If there’s something you’d like me to cover, get in touch on Twitter and let me know!

[uiwriting]

404 pages, good and bad

We’ve talked 404 pages before - let’s look at some more! These examples are on a political theme (although slightly out of date, as the election’s been and gone), thanks to Mashable.

Hilary Clinton’s 404 page

It’s short, it’s funny (but not trying too hard), and it’s reasonably clear it’s a 404 page. It could be more helpful by giving you a search box. 

I wonder how effective the volunteering call-to-action is? They’re taking the opportunity, while you’re not doing anything else, to give you something to do. 

But I think you probably are in the middle of a task - trying to find the page you were looking for - and I can’t imagine people stay here long.

A Conservative 404

They’re trying to do the same thing as Hilary - catch you while you’re not doing anything. But their attempt is to give you some tailored advertising instead.

Here’s a bit more detail if you can’t read it:

The problem is, because there’s so much content on this page, it’s not very obvious it’s a 404 page. I’d think that people would get confused by the form, as it wasn’t what they were looking for.

Labour’s version

This is a more obvious 404. And they’ve made a reasonable joke - predictable, but at least it’s not trying too hard.

Their call-to-action is a bit confused though. It’s like they wanted to get you to sign up for something, but they forgot to put in a link to do that.

A link to the homepage is reasonable. Not sure how much help the second link is though. “If you’re looking for a specific page, search here”, with a search bar, would be better. 

The Lib Dems

The poor old Lib Dems. They did get trounced. But at least they won the 404 page competition. This is another a not-too-terrible joke, that still makes it clear it’s a 404, and a sensible place to send people.

“Click here” isn’t recommended though - it’s bad for screen readers. “Go to our home page”, all as a link, could be better. (I considered “Go back”, but that’s not true if you’ve followed a broken link from somewhere else.)

A poor showing from the Greens

To finish it off, a page that’s making no effort at all. They’ve not even kept the navigation/header from the rest of their site - which, come on, isn’t hard.

“Please use the link below” - oh dear. Why would you explain to people how to use a link, rather than just putting the link there?

“You will also find a search in the top menu” - we wouldn’t need to, if you’d kept the top menu on this page...

They’re trying to be nice with the “Thanks for visiting”, but this isn’t a letter. And it gives the bizarre impression they thought someone wanted to go to this page on purpose. 

What makes a good 404 page?

So what have we learnt from all of these? How can we do better?

A 404 page is ultimately, just an error message. All you need to do is communicate to your user (clearly) that the page they wanted isn’t here, and offer them a way to move on.

That could be by giving them a search box (to find the content they were looking for), or by giving a log-in form (if you have content hidden from anonymous users). 

A link to the homepage is common, but I’m not sure how useful that is. If you keep your normal navigation in the header, users should be able to get there easily anyway. 

And what about jokes? Loads of websites use 404s as a place to be characterful and funny. 

I think it’s fine to be cute, but don’t forget that hitting a 404 can be frustrating, especially if you really needed the page you were trying to get to. Consider Voice&Tone’s guidance on error messages: it’s risky to joke around with people who are stressed. 

So it depends on your content - if it could be critical to people, be careful about making your 404 page a big joke. In those political examples, it seems likely that nobody’s relying on their content, so a joke is fine.

Finally - if you’re going to make a cute game or something, don’t forget that you also need to make it clear what the page means!

If anyone has any data on those volunteering calls-to-action, please let me know. I’d love to know how effective they are. 

[uiwriting]

Google Drive: becoming user-centered

I like Google Drive, and use it pretty much every day. I’ve found it fairly simple, pared-back, and convenient. 

I remember one small annoyance in the microcopy though: this category called “Incoming”. 

That category’s not very clear to me. My best guess as to what it did, without checking what was in it, was that it contained documents with new changes. 

In fact, it turned out that “Incoming” stores other people’s stuff that you’ve been given access to. They’re incoming in the sense that they’re coming from somewhere else - that’s where Drive is getting them from.

The problem

That name isn’t focused on what that category does for the user. It’s focused on the system internals, and doesn’t explain what it is to me. 

I suspect it was maybe even the name in the codebase, and it got leaked out into the UI without anyone thinking about it.

The fix

I don’t need to come up with a fix, because Google did that already:

(By the way, I also like the copy on the button. “Got it” is exactly the right response here - “yep, I’ve understood what you told me, don’t need to see this any more”.)

“Shared with me” is so much more obvious. Does exactly what it says on the tin. 

I’d complain about the unnecessary capitalisation on “Me”, but I just checked Drive again now, and they’ve removed it. So I thoroughly approve :)

One final point - notice that UK localisation it’s done for me, from Trash to Bin. It’s not essential, but it’s a nice touch. 

[uiwriting]

An unfortunate error message

This error has ended up being rather mysterious...

From Netherlanders on Twitter, via harrissimo

[uiwriting]

Write the Docs 2015

I’ve just got back from speaking at Write the Docs, and I had a fantastic time. Thanks so much to everyone for your kind words about my talk - I’m so chuffed you all liked it. 

If you’re interested, you can take a look at my slides, or read the transcript I just typed up of what I could remember of what I said. The talks were filmed, so at some point I’ll be able to show you the video. I’m sort of looking forward to watching it, but sort of nervous too - it was my first real conference talk, and it was a bit of a blur, so I’ve no idea how I came across.

The runaway favourite bit of the talk - according to Twitter anyway - was this example of clearly expressing consequences:

Ideal error message: here's how this affects you. @baitman at #writethedocs pic.twitter.com/TUq9lGt2nU

— Elite Truong (@elitetruong) September 1, 2015

(thanks to elitetruong for tweeting it, and nickparker who it came from)

It’s funny, but it also makes a really good point. Clear language is so important if you want people to understand you. It’s the same point being made in this blog post - “use the words normal people would use”.

Anyway, now the conference is done, normal blogging service should resume. I’m always keeping an eye out for UI writing examples, so hopefully I should have more soon to share with you all.