To paraphrase, an error message should tell a user clearly what the f**k is going on and what to do about it.

For example, take the following display, snapped on my phone in Manchester Airport’s departure lounge before Christmas, an hour or so before our flight was cancelled (poor us).

Airport error message UX

The message, in the centre of a blank display which should have shown flight departure times:

is useless to its intended audience (ordinary human beings), as it is filled with techno-babble

is literally unreadable in places

provides no guidance on how to fix the error and restore the system

may have been marginally clearer if its button read ‘Terminate program’

includes a close icon, whose purpose is unclear (does it close the message or terminate the program?)

No error message in the context of a departure lounge display board is a good error message – all passengers want to do is see departure times, and can do nothing to fix the error. It’s a prime example of where error prevention is far more important.

Nevertheless, error messages like this persist in other contexts – we’ve probably all seen them many times. There’s no excuse – error messages should simply be simply and clear.

“it’s always more important to be clear than entertaining. When you’re writing, consider the reader’s state of mind. Are they relieved to be finished with a campaign? Are they confused and seeking our help on Twitter? Are they curious about a post on our blog? Once you have an idea of their emotional state, you can adjust your tone accordingly.

So does Mailchimp’s current 404 error message breach its own rules? You decide…

Mailchimp 404 error message

Green swamp-monster not withstanding, Mailchimp’s error message is readable, concise and offers a clear next step (the navigation or search box) – unlike the message in the airport.

In my last post I wrote about “choice blindness”, the principle, supported by research, that people can be blind to their own choices.

In designing solutions through user research, presenting users with multiple variations of a feature, and asking them to choose their favourite, tends to be unreliable.

In UX, an iterative approach is thought to be better. Start with a proposition based on evidence from users (or a proposal for testing from the business), build something testable (a paper prototype, wireframe, etc), and trial it through usability testing with real users, in context. Identify the aspects that work, remove or change those that don’t. Iterate, and test again.

Watching users use a system and making iterations based on observation and evidence tends to yield best results.

Many businesses suffer from the ‘it seemed like a good idea at the time’ syndrome, where software or features are built on the suggestion of an individual or two. Time and money is spent on implementation, but often the results go by the wayside: never finished for lack of clarity of vision; never used for lack of user interest.

UX methodology avoids ‘ISLAGIATT’ projects.

It starts with the tenet that a business doesn’t necessarily know what its users want. But more than that: users don’t necessarily want what they ask for. That’s not as counter-intuitive as it might seem: though UX is firmly rooted in user evidence, that’s not synonymous with what they say they want.

My favourite example of this is an experiment run by Petter Johansson, a cognitive science researcher at Lund University. As explained by Petter and his colleague Lars Hall, two cards of same-gender faces were placed in front of participants. They were asked which face they found more attractive. Unbeknownst to participants, the moderator was a magician who, with slight of hand, presented the participants with the face they rejected. They were then asked to explain their choice.

The choice blindness experiment is a useful lesson for UX practitioners

75% of the time, participants were blind to the mismatch. Furthermore, the majority proceeded to give detailed reasons why they choose that face over the other, one remarking “I prefer blondes” (he’d chosen a brunette). Johansson calls this ‘choice blindness’.

To give another example, perhaps I’m designing the information architecture for a clothing e-commerce site. I present someone with a random list of all clothing categories and I ask them to find ‘shoes’. Understandably, they say – ‘I wish these were in alphabetical order’. However, that doesn’t mean that laying out categories alphabetically is the best approach for the website. What if a visitor wants to find a suitable gift for Christmas, or something cool for summer?

Understanding that users don’t necessarily ask for precisely what they want is a small piece in the long and broad road to great UX.

It’s a process and methodology that gives companies the tools they need to build better software – stuff that users actually want, that will drive businesses forward. It makes sure projects develop in line with user needs, that solve real problems, that tie in with business requirements, and that test assumptions.

I digress from the usual topic of UX to share some lessons from my recent foray into design for print, which was challenging, rewarding and fun.

I was given the challenge of taking an agency’s creative vision and using it as the basis for designing Kings Court Trust’s printed materials.

Designing for print is not something I had done to this scale before. I knew enough to know that there was much I didn’t know; particularly, about getting the best colours on paper – one of the most important, and bewildering, parts of the process.

For anyone dipping a toe into the the world of print, here are the lessons I wish I knew before I started.

1. RGB vs CMYK

RGB and CMYK are two colour models; effectively, two different ways of displaying colours. A bit like paint ranges.

Most professional printing presses are based on CMYK. So, if you haven’t got your head around colour models well before the first print run arrives on your desk, you could be in for a nasty surprise – regardless of how stunning it looked on screen.

This video is an excellent introduction to CMYK and RGB:

Herefollows some nitty gritty, much of it specific to the latest Adobe CC suite (apologies if you don’t use it):

I find it helps to create a swatch library with both RGB and CMYK colours, using the Adobe CC colour picker. To the right is a screenshot of my swatches: the differences between RGB and CMYK variations are particularly marked in the oranges and greens.

Determining the right colours in the first place is more difficult. If you use a designer, ask for CMYK, RGB and hex equivalents for every colour. In our case, we had tremendous difficulty translating our green from RGB to CMYK… turns out green in particular is a pain in the arse when it comes to CMYK. But after experimenting and having a few test runs, we got the right one.

In InDesign (or equivalent), make sure the ‘transparency blend space’ is RGB or CMYK as appropriate – the wrong one can produce some odd results.

Don’t bother converting RGB imagery to CMYK (or vice versa) before importing – this is a myth. If your export settings are set up properly, this will do the conversion for you. (Though it’s not so simple for text…)

Create an RGB version of the document for downloading, emailing and printing at home/office – on screen, these colours tend to look more vibrant than CMYK. Create a CMYK version with all the trimmings (bleed, printer marks etc) for professional printing, though check with your printer first for the best settings.

How to check if a file is CMYK or RGB

It can be helpful to do a final check of a file before it’s sent to print.

If you’re lucky enough to have the very handy Adobe Acrobat Pro DC and you want to check a file’s colour model, open ‘Tools’, ‘Print production’, then ‘Output preview‘. Under ‘Show’, select ‘CMYK’ – if all the elements on the page (apart from printer marks) remain visible, it’s CMYK. Then select ‘RGB’ – if it’s CMYK, all elements will disappear.

Above – the output preview in Acrobat showing anything CMYK. The page elements remain visible so they must be CMYK.

Also in ‘Output preview’, if you select ‘Preview’ > ‘Separations’, you can hover the cursor over an element on the page to see a breakdown of the CMYK values. Particularly helpful to check for four-colour blacks (see below).

Above – hovering the cursor (not shown) over a colour in output preview will show the four CMYK values

2. Black’s not necessarily black

Something that looks black on screen might not appear black in print.

To achieve blacker blacks and greyer greys, conventional wisdom is to avoid “four colour blacks”. That’s a black or grey made up of four CMYK values, e.g. C75 M67 Y67 K89. Instead, it’s often best to ensure blacks have a “K” value alone – e.g. C0 M0 Y0 K100.

Setting up the right swatches in your software is a great start. I use C0 M0 Y0 K12 for a light grey, C0 M0 Y0 K30 for a mid grey and C0 M0 Y0 K50 for a slightly darker grey.

It’s often helpful to check the blacks in a file after export. Using Adobe Acrobat Pro DC, under tools, choose ‘Print production’ and then ‘Output preview’. Select a CMYK profile from ‘Simulation profile’, e.g. Coated FOGRA39. In the preview section, select ‘Separations’. If you untick ‘Process Black’, all one-colour blacks will be removed, and all four-colour blacks will remain.

1. Above – Acrobat Pro output preview showing all four parts of CMYK, so every element on the page is visible.

2. Above – ‘Process Black’ has been unticked, so all genuine one colour blacks disappear (only elements made up of cyan, magenta and yellow remain, like the orange headings).

3. Above – Oops… on this page, some cheeky grey lines remain, which means they can’t be one-colour. This needs fixing, so it’s back to the original document to sort it out.

3. The right software, the right export settings

For brochures and other documents, I use Adobe Indesign CC. In terms of colours, ‘Output’ is an important part of the ‘Export’ settings. To ensure a document exports as CMYK: for ‘Color conversion’ select ‘Convert to destination’; for destination I use ‘Document CMYK’ (which takes the current working space from the document settings, which for me is ‘Coated FOGRA39 (ISO 12646-2:2004)’); for ‘Profile inclusion policy’ I use ‘Don’t include profiles’.

4. Find a friendly printer

A good relationship with your print professional helps enormously – they can identify problems and suggest solutions before the print run.

This is just the tip of the iceberg. There’s paper stock, finish, bleed, trim, slug, litho vs digital (for more information on litho vs digital, check out this video and others from the same channel), etc etc. But achieving the right colours and blacks is a great place to start.

Error prevention:
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

I recently fell foul of what I consider to be an inexcusable lack of error prevention.

Using Apple’s native Mail application on my Macbook, I searched for the out-of-office feature. It doesn’t exist (pity). Apparently I needed to set up a rule, to send a friendly message in reply to any incoming email, letting the sender know I’ll be sunning myself in Norway.

All good so far, and one final action for me to take:

The offending window in MacMail – poor error prevention

Sure, I was in a bit of a hurry to log off and go on holiday, but of course the choice was obvious – I clicked the welcoming blue button.

Two minutes later I got a call from my line manager, who was heading home on the train. His phone was going BING, BING, BING, BING, BING, BING, BING, BING, BING, BING – attracting the attention of other commuters, until he switched it to silent, but the emails had kept flooding in. 300 of them or so. (My only saving grace is that I’d only joined the company a couple of months previously, so the number of emails were limited.)

I retraced my steps and realised that that enticing blue button had applied my rule to ALL emails in my inbox, which meant a reply had been sent to EVERY email I’d EVER received letting my colleagues (including the CEO and various others) know I’d be on holiday.

Apple die-hards may dismiss this as user error, and sure – I make mistakes like anyone now and again – but I maintain that this hugely embarrassing, unexpected consequence of such a common, ostensibly simple task was far too easily done.

The issues:

1. Mail should have an out-of-office feature.

Debacle prevented.

2. Why, why, why would I ever want the actions I took to lead to the results that occurred?

I cannot envisage a single reasonable scenario where any user would want to send the same reply to every single old email in their inbox. It simply shouldn’t have been possible for this to happen.

3. It shouldn’t have been so easy.

Even if it had to be possible (which it didn’t), it was far too easy for me to click that button, considering the seriousness of the results.

Putting aside the issue that this result shouldn’t have been possible in the first place, there are options which might reduce the likelihood of errors.

For example:

swapping the buttons, to make ‘Don’t Apply’ the default

showing ‘Apply’ as text (rather than a button) to further distinguish it from the preferred option

adding a warning symbol and/or warning explanation to ‘Apply’

rewording the window to make the action and consequences clear (the copy at the moment is very unclear, in my view) and changing the wording on the ‘Apply’ button to something more specific like ‘Reply to every single email in your inbox, even though you’d never ever want to do so’ (er… or maybe something a little more concise)

A confirmation ‘Are you sure?’ pop-up, or the option to undo before the changes kick in.

And so on.

4. Users hate errors

When poor system design leads to serious consequences for the user that could and should have been avoided, that’s about as frustrating as it gets in terms of user experience. Error prevention isn’t the most glamorous part of UX but there’s nothing more important.