Colouring-in Team

In my last post I talked about what it means to say that text is legible. If you haven't read it, you might want to take a look before you dive into this one, as some of the maths follows on.

It's pretty obvious that contrast can and does have a significant impact on legibility, and therefore also readability, and not enough of it can make for an unpleasant user experience. To counter this problem there are strict guidelines set out by W3C. If you work in web-based media you'll be familiar with the Web Content Accessibility Guidelines (WCAG), which define minimum contrast values for text in both AA and AAA accessibility standards. WCAG 2.0 level AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text. And the guidelines also state that once contrast reaches 7:1, legibility is unaffected beyond this point. And if that all seems a bit impenetrable, there are many online contrast checking tools available that allow you to test your proposed text foreground and background colours to see if they meet the guidelines.

What is contrast?

In simple terms, contrast in vision is the ability of the eye to distinguish between differing colour and brightness. The values listed above are the ratio of the 'luminance' between the foreground and background colours (though not necessarily in that order). You can think of luminance in this context as a measure of the intensity of light as perceived by the human eye. Some wavelengths (i.e. colours) of light have more luminance than others, peaking in the green-yellow part of the spectrum.

The process by which contrast ratios are calculated probably isn't for the mathematically faint-hearted, but I'll set it out anyway. Feel free to skip to the next heading if it all looks like Greek to you. It probably is.

The first step is to work out the relative luminance of the foreground and background colours in question. To do that we use these formulas:

if R_sRGB <= 0.03928 then R = R_sRGB / 12.92 else R = ((R_sRGB + 0.055) / 1.055)^2.4

if G_sRGB <= 0.03928 then G = G_sRGB / 12.92 else G = ((G_sRGB + 0.055) / 1.055)^2.4

if B_sRGB <= 0.03928 then B = B_sRGB / 12.92 else B = ((B_sRGB + 0.055) / 1.055)^2.4

...where...

R_sRGB = R_8bit / 255

G_sRGB = G_8bit / 255

B_sRGB = B_8bit / 255

You can think of the SRGB values as proportions of red, green and blue. Thus, if your text colour was specified as #800000, that's a red value of 80 in hex, or 128 as a decimal, so the SRGB value for red would be 128/255 = 0.5.

We can now calculate luminance by combining the R, G and B values above in the following way:

L = (0.2126 x R) + (0.7152 x G) + (0.0722 x B)

Note that to acquire a luminance value we are essentially adding up the red, green and blue values, adjusted by constants in accordance with how much of an impact those wavelengths of light have on luminance. Thus the green value has a far bigger impact on the final luminance value than the blue value.

Finally, having calculated L for both the foreground (text) colour and the background colour, we can work out the contrast ratio between the two quite simply, as follows:

Contrast ratio = (L₁ + 0.05) / (L₂ + 0.05)

Where L₁ is the most luminous and L₂ the least luminous of the two colours.

OK, so that's the scary maths-bit over...

So why am I interested in this? Well, at present if we designers want our websites to be AA or AAA compliant, they must meet with the contrast guidelines described above. But in real life, of course things are rarely as simple as a binary rule: "THIS text is legible, THAT text isn't..."

Text on the web that is illegible or at least hard-to-read due to the choice of colours is nothing new. Katie Sherwin, writing on the Nielsen-Norman Group blog, has some interesting things to say about the use of low-contrast text on the web.

What I'm suggesting here is that it is possible to have hard-to-read text that meets the WCAG rules, and easy-to-read text that doesn't. For example...

As far as I can tell, this text passes the AA level guidelines, with a contrast ratio of about 4.5:1.... The question is, is it easy to read? I suspect that most people would find this paragraph harder to read than the next one. I'm deliberately droning on and on here, just to make sure there is a nice long block of text to really ram home the point I'm trying to make. Fortunately for you, the next box just says...

bicycle.

So, in case it wasn't already clear, the top box should pass AA guidelines, but the text in the bottom box fails both AA and AAA.

Now, to be clear, this isn't due to lack of care on the part of the clever people who make up the WCAG. In fact the guidelines go to some lengths to explain the choice of contrast-ratios used as cut-off points, and they are clearly the result of considerable thought and research. My point is really that, as soon as you introduce any sort of binary rule into design, it immediately creates space for applications of that rule that seem outside of what was intended, such as the text above.

Now, designers clearly can't user-test each piece of text we want to use to see if it the contrast works well enough, and a hard-and-fast rule is a pretty safe alternative. But what if, instead, we try to look at the effect contrast has on legibility, and apply it on a case-by-case basis to mathematically assess how legible and how readable a piece of text will be, across devices. Can we construct a formula that would warn you that the red box above might be hard to read, but reassure you that the text below it is likely to be just fine?

Modelling contrast

We know that contrast effects legibility. Therefore it is logical to suggest that, in most cases, a reduction in contrast can be countered with an increase in text size. Consider the text you are reading right now:

If I suddenly make it slightly lighter, it becomes harder to read, right?

But if also make it bigger, it's not so much of a problem.

Now imagine a graph where we plot the size a character needs to be to maintain it's level of legibility against its contrast with its background. Thinking about how this model might look, we can see we already have two known points on the graph.

Firstly, according to WCAG, once contrast reaches 1:7 there is no further improvement in legibility. We express 1:7 as 1 divided by 7, or 0.143, so this gives us the start of our graph. To the left of this point (i.e. where contrast is better) it should level out.

Secondly, we might reasonably say that if the size of text has to increase each time contrast decreases, then the other end of the graph must tend towards infinity. To put it another way, once contrast has a ratio of 1:1 (for instance white on white or black on black), the text would have to be infinitely large i.e. it can never be legible at that contrast ratio.

In between I will assume (for want of information to the contrary) that the relationship is a smooth curve. Thinking about these few characteristics, we end up with a graph that looks a bit like this:

The next logical step is to try and find a mathematical function that will produce a curve that looks like this, so that we can predict the necessary change in text height for any given contrast ratio. To me, that looks a little like a 1 / 1-x function, though if anyone reading is a proper mathematician (or knows one), I would welcome any alternative suggestions. The best-guess function I have at present is...

Putting it into practice

Having come up with a function that might model the effects of contrast on legibility, it seems sensible to try it out. I have created a sort of legibility testing tool to do this. Feel free to try it out and have a play, although be aware that it is all rather Beta, and probably as likely to break as to work. The font detection relies on Flash, and also won't work if you're using any sort of 'private browsing' mode. It also takes a few seconds to work, so have patience.

Stupidly, I borrowed the font-detection AND the nifty size-calculation scripts from somewhere, and can't remember where. If they're yours please let me know so I can give credit where it's due!

What is it all for?

This tool is designed to combine all of the legibility-related calculations from this blog post and the previous one, and allow a designer to choose any locally-installed font, specify the size, colours, and intended device on which it will be displayed, and see just how legible it might be.

The point of all this is twofold:

1. To enable designers to make better decisions about typography, for a more readable web experience.
2. To free designers from the constraints of hard-and-fast contrast rules, so that where branding or aesthetics require type to appear outside of the suggested cut-off points, a judgement call can be made with confidence.

Next steps

The plan is to test the theory. I've written some testing software that should enable me to test real eyeballs under controlled conditions, and see if the relationship between text size and contrast really does look like this. It may be a little while before a large-scale test can happen (though with help from my awesome colleagues at Zone it shouldn't be too long, I hope), but early signs are good. Here is a chart of results from testing myself and a couple of others in not-very-controlled conditions...

If you found this useful or interesting, or if you know anything about this topic and you don't mind sharing, please add a comment below. Thanks for reading.

References and Links

WebAIM: Color Contrast Checker

Contrast Rebellion

Contrast Sensitivity Testing

Wikipedia entry: Luminosity function

Conference Paper: Human Computer Interaction, Legibility and Contrast

What minimum text size should be used on the web?

If you work in digital design you probably have some sort of answer in mind. Maybe you have a preferred size for readability, and a lower limit you won't drop below. Perhaps you remember the WCAG guidelines. Whatever your answer, the next question is probably more tricky: why?

With the range of screen sizes and resolutions currently available, not to mention the variation in the way we use devices, it is becoming increasingly hard to know exactly what is a sensible minimum, or a comfortable size for reading. In this post I will attempt to explain what 'legibility' means, technically, and how this can help you make better decisions about text size.

“Typography has one plain duty before it and that is to convey information in writing. No argument or consideration can absolve typography from this duty. A printed work which cannot be read becomes a product without a purpose.” - Emil Ruder

How good is your eyesight?

One way of describing the sharpness of eyesight is with the 'Snelllen scale'. As I understand it, this is actually somewhat old-fashioned these days, but for the purposes of this explanation it is ideal. You're probably already familiar with this measurement: normal eyesight is described as "twenty-twenty" (20/20).

So what does that mean? On the right is a Snellen Chart, a method of measuring visual acuity developed in 1862 by Dutch ophthalmologist Herman Snellen. A descendant of this chart is still used today. The smallest line of characters that a person with so-called 'normal' vision can read at a distance of 20 feet is the 20/20 line. If a person is said to have 20/40 vision, they can just about read at 20 feet what can normally be read at 40 feet. And likewise if you were lucky enough to have 20/10 vision it would mean you could read at 20 feet what others could only read at 10 feet.

Technically, whether or not something is legible is all down to the angle the character being viewed makes with the eye. That is, it is the perceived size that is crucial, not the physical size. Small-print on the back of a form held a few inches from your face may be easier to read than giant words on a billboard a few hundred metres away. You can visualise it like this:

It is a simple matter of either trigonometry or common-sense to demonstrate that the relationship between the distance and the character-height is linear, meaning that you can maintain the same angle at twice the distance by doubling the character-height.

It's all about angles

Going back to that definition of normal eyesight, the angle those characters on the 20/20 line make with the eye at a distance of 20 feet is 5 minutes of arc, a minute of arc being one sixtieth of a degree.

The characters that form the chart are actually very interesting. They are known as 'optotypes', and they have some important characteristics. Firstly, the width of the lines is the same as the the width of the spaces. Secondly, the width and height of each character is five times that line-width.

What this means in practice is that when a person is able to discern an optotype that makes an angle of 5 minutes of arc with their eye, that in turn means they can "resolve a spatial pattern separated by a visual angle of one minute of arc". If that sounds confusing, look at the capital E. To read it you must be able to differentiate three horizontal bars and two spaces: five elements in total.

Note that although these definitions reference distance vision, the actual measurement of visual performance is not related to a particular prescription for lenses. Factors beyond myopia or hyperopia can affect a person's ability to resolve a sharp image, including astigmatism, problems with the shape of the eyeball or cornea, and even neural problems. It is, however, a measurement only concerned with central vision, and not peripheral vision.

Some vision trivia...

• About 35% of adults have natural 20/20 vision, rising to about 75% with the use of corrective lenses or surgery. [source: UIHealthcare.org]
  
• Many people have better than 20/20 vision. In 1999 Tiger Woods had laser eye surgery, which is said to have given him 20/15 vision. After the surgery he won seven of his next ten events. [source: Independent.co.uk]
• Here in the UK, the DVLA require you to read a 79mm number-plate character at a distance of 20 metres in order to obtain a driving licence. This equates to just 20/54 vision.
• There is a separate DVLA requirement for visual acuity of 'decimal 0.5' (after correctives). This is just 20/40 vision, and may go some way to explaining the quality of driving here in Bristol.

Easy to read?

There is a crucial difference between text being legible and actually being easy to read. To say that something is legible is simply to say that the reader can discern what the characters are. But for something to be easy-to-read it must be larger. And of course there are other typographic factors that I shan't cover here, such as line-length, leading, typeface and so forth. There are many excellent blog posts on this subject.

Many studies have looked at at what constitutes easily-readable text. The ANSI calls for a minimum of 16 minutes of arc, and British Standard BS EN ISO 29241-3, ("Requirements for Office Work with Visual Display Terminals”) also uses 16 minutes of arc as the boundary for easily readable text. Interestingly, the apparent radius of the sun at the horizon is also 16 minutes of arc. I expect this is just coincidence, but it is interesting that there is a commonality between human visual acuity and probably the only object that has been a constant size throughout our evolution.

Text on Digital

So what affects the legibility (and by extension, readability) of text on the web? We know that this is a question of the physical size of the text and the distance of the eye from the screen. So what we really want to ask is: what affects the physical size of text on a screen? And here a number of factors come into play. Clearly the specified text size is the major factor, but perhaps less obviously there is also the pixel density of the screen, and the typeface itself.

Pixel density

Pixel density has become a significant variable in digital design only relatively recently. If you're not sure exactly what I'm talking about, pixel density is simply the number of 'dots per inch' on a screen. To illustrate, a laptop with a 1280 x 800 pixel 13 inch screen has a much lower pixel density than a 5-inch-screened smartphone of the same resolution. For reference, a pretty standard HD resolution 24 inch PC monitor has a pixel density of about 94 pixels per inch (PPI), whereas a 'Retina' screened Macbook on the other hand has around 225ppi.

Unfortunately the complexity doesn't stop there, as it is also necessary to think about device-pixel-ratios. This is to contend with the fact that many newer mobile devices are so pixel-dense that they have to 'pretend' to have lower resolution screens in order to ensure that web pages display at a size that is readable.

Interestingly, 20/20 vision should allow a person to recognise a 1 pixel pattern on a 290ppi screen held 30cm from the face. What this means is that many of us are are already using smartphone screens that exceed the capabilities of the human eye in normal use, with density values exceeding 300ppi becoming more and more common. If you've ever worked in print design, this number might seem incredible: there are now phone screens that exceed the standard quality measure for print.

Typefaces

When we talk about the physical size of text rendered on a screen, one of the things that is commonly overlooked is the differences between typefaces. Below is the letter E, set in a variety of typefaces. But each 'E' is exactly the same font size. As you can see, some fonts produce a letter E twice the height of others.

Doing the sums

So, how can you work out if the text you've put on a website will be legible? If you know the height of your capital E in pixels, then the pixel-density of the screen multiplied by the pixel-ratio should enable you to work out the physical height of the character. We can estimate the distance of the eye from the screen if we know the most likely usage for any given type of screen (i.e. handheld, sat at a desk etc). Combining these means we now know two sides of a right-angled triangle, and so we can calculate the angle made with the eye.

If all of that seems too complicated, have a look at this diagram:

If you can remember a little of your school trigonometry, you might recall that the tangent of an angle is equal to the opposite divided by the adjacent. So....

tan δ = opposite divided by adjacent = b / 2a

To save you the trouble of doing this yourself, I've made a handy little tool to do the job for you.

About contrast

Clearly contrast of text against a background has an enormous impact on how readable it is. Understanding (and attempting to model) the impact of this will be the subject of the next post on this blog. I have written a tool which attempts to check typography for legibility both in terms of size and contrast, and I hope to share that next time, too.

Final word

Legibility is of course only one factor in making text useful and valuable. I can't really say it any better than David Carson: “Don't mistake legibility for communication”

This is something I've been trying out recently, and I thought it might be nice to share it and see if anyone else finds it useful. It's still something of a work-in-progress, but I think the approach outlined below has the potential to speed up workflow and communication within this particular bit of the website design / development process.

It can be useful to have a simple way to communicate how a web page will be laid out at different screen widths: which bits will grow or shrink, what will sit off the screen, what will be hidden, and so on. This is essentially a diagrammatic approach to the problem of how to communicate that information, as well as a sort of design-aid. It is not a wireframe, as details are deliberately excluded. It is also not a mock-up as the dimensions of objects on the page bear only a loose relation to real life in terms of their relative sizes. It is also fairly useless on its own - it must be read in conjunction with a realistic mock-up of the web page designs in question, depicted at at least one size.

The basic idea is that each website element is represented in a simple block diagram, and colour coded according to broad element types to make it easier for the recipient of the diagram to match these up against a realistic design mock-up. Sizes are only approximate because everything is based on a very large grid to make editing easy.

I think something that makes this approach particularly helpful is its abstraction from reality i.e. the in-built room for manoeuvre that results from not specifying screen widths, and not having exact sizing. There is no particular reason why layout changes have to happen all at once at certain screen widths - after all, break-points are so last week - but it is still important to plan for a good user experience at key screen sizes. How transitions are made, and at what precise screen widths, should probably be dictated by the content in question and doubtless require input from a skilled front-end developer. These diagrams simply show the 'keyframes', if you like.

You can download the template here, suitable for Illustrator CS3+

I have also made a PDF of the same No use as a template, but if you don't have Illustrator at least you can still see what I'm going on about.

I've used these diagrams to plan website behaviour in preparation for front-end build by the quite frankly improbably clever @lnrb0b Perhaps in an ideal world I would mock-up individual page-element behaviour, or sit with my friendly front-end developer and work out how each aspect of the page should reshape itself, but there generally isn't the budget for that. It's still early days, but so far this seems to be quite a good way of roughing out what I'd like to see without adding too many constraints.

Feel free to leave comments below - it would be interesting to know if this is useful to anyone else. And if you think my template is actually about as useful as a brushed-nylon fire-blanket, that I'm completely missing the point, and that I should immediately retrain at my local McDonalds, do please feel free to improve it and re-share!

Earlier this year I wrote a blog entry for the Auros site about how the UX analysis for a particular project had provided inspiration for the visual design that was to follow. A current project has given me cause to think about this further, and to try to more eloquently explain why I feel that the project stages we generally refer to as 'UX' and 'Design' are in fact just design, and all of the designers involved need to be there for all parts of the process.

At work we recently outsourced the UX component of a particular project, and a few days ago I had a handover from the UX company so that I could start work on the visual design. Usually I handle both bits of the puzzle, and so no kind of handover is required. It made for rather an interesting experience to have been completely separate from the UX analysis and design process, and then receive a set of completed wireframes, approved by the client. I might liken it to starting to watch a movie half an hour in.

What surprised me was how bereft of knowledge I felt. I still understood the client's business, and had a fair idea of what might look good, but all of the subtle nuances of preference that a client normally gives away without even realising were totally absent. I hadn't fully realised until this project just how much of this discretely, subconsciously-delivered information aids my understanding of both what will sit well with the intended users, and what the client will want to see. Without those weeks of to-and-fro with project owners, discussing users and goals and journeys through the site, it felt like I knew both the client and their users less well than I would like to.

It seems rather obvious to say that visual design and user-experience design are simply different stages of the same process, and that really the whole lot is simply DESIGN, and probably would be thought of that way in most industries. But so often I read about them being treated as discrete project elements, handled by different people/teams/companies (delete as appropriate), and that makes me question the way in which many websites are created. The way wireframes describe information and functions on a page has a huge effect on the visual design of a site. The way a graphic designer formats text, images and layouts has a huge effect on a user's experience of a site. So if there is a clear delineation between the two, I don't think I can see it.

And even if we put the influence of visual design on user-experience to one side for a moment; in a commercial setting, the visual designer's judgement call as to what a client will find acceptable can be as important as well-founded user-experience design. The harsh reality is that if you want to get paid, the client has to like your work in the first instance, and not just when or if users report back. And achieving both of those things means knowing your client and knowing what they will like.

I feel like many of the nuances of preference and discrete information that drive delivery of the 'right' design (either from a user-experience or client acceptance point of view), are often implicitly communicated by the client over the course of the UX process. The visual designer / Graphic Designer who is not involved in the design process from the start is missing half the story, and must either do without, or spend time discovering the same things that the UX designer already knows. Likewise without continuity of process from UX analysis through to creation of a visual mock-up or prototype, there can never be a truly thorough realisation of a user-experience designer's vision. Whichever way you look at it, you're wasting time or skills at one end of the process.

I recently changed energy providers. Not an especially interesting revelation I admit: why would anyone else care whose logo is at the top of my electricity and gas bills? But I'd say that the reason for changing provider is interesting, because this is the first time I can recall consciously having made a purchase decision based on the quality of user-experience on a website.

It isn't that long ago that the user-experience of a company's website was no more than incidental to the overall customer experience, and an optional part of the customer's relationship with the business. These days it clearly makes sound financial sense for almost any business to encourage its customers to self-manage online, and now regular contact with the website has become an absolute requirementof that relationship.

The upshot of this is that the experience you have performing essential activities on a company's website has, to varying degrees, replaced the experience you might have had in their shop, talking to their staff, or reading their literature. Which is where the title of this post comes in: the user-experience of your site is your customer service. A website that is difficult or confusing to use is no different to running a badly laid-out shop with rude staff. And whoever you pay for your electricity and gas, using their website to manage bills, meter readings, direct debits and so forth is almost unavoidable. And because of this necessity of usage, the experience of performing these tasks on the site must be a good one.

If you work in the web development industry, or run a successful website yourself, then you might find everything so far to be blindingly obvious. But rather surprisingly this state of affairs does not seem to be universally appreciated, my now ex-energy-provider being a case in point.

Like it or not, a customer's expectation is often already in place before they visit a website, a result of the fact that "do it online" is used as a byword by marketing departments worldwide for "it'll be easier and more convenient". And this applies doubly to the kind of task thatfeels like it should be simple. Finding some information, changing an address, or submitting a meter reading are all conceptually simple, and so the end user is bound to feel that those tasks should be straightforward, quick and obvious.

This is something thatall businesses need to appreciate - not just those of us designing and developing new sites, but the people paying the bills too. In the same way that successful service and retail businesses spend money to ensure that well-trained staff project the right image and give the best customer service, expenditure on equally good online customer service needs to be seen as a worthwhile investment.

So getting back to the original subject of this post, I switched my gas and electricity away from E.onas a direct result of the difficulty I had using their site. The somewhat haphazard and unfocussed nature of http://www.eon-uk.com/ should give a bit of a clue to the problems that lurk within, but it's not until you engage in trying to complete a task that the user experience really suffers. I won't turn this post into a full-scale dismantling of poor old E.on: for all I know they might have a fabulous new site launching tomorrow. However, it is worth detailing one small aspect of the user journey that aptly demonstrates how a few small failings can have a big impact in combination.

One of the most frequent ways in which I came unstuck while using the site was during the log-in process. The password rules for E.on meant that I couldn't use a password of the type or pattern I might normally choose, and as such I almost always failed to remember it.

This on its own might have been bearable, but the problem was compounded by the fact that the user is only allowed 2 errors before the account is locked for 15 minutes. Now it could be that I am a cretin of truly epic proportions, but personally I found it rather easy to get the password wrong twice. In fact, I imagine many users could easily make the same typo twice in a row. The fact that the forgotten-password link is also locked for 15 minutes is the icing on the cake.

So by combining password rules that differ, however subtly, from the norm, with an oversensitive account lockout, they inadvertently created the perfect conditions for absolute infuriation. My bank doesn't have a system as sensitive as that, and it's hard to see why the place where I look at my gas bill needs to be more secure than my bank. It all comes down to that all-important expectation on the part of the user that things will be easy and convenient - if I want to look at my gas bill, I want to look at it now, not in 15 minutes and after performing a password reset!

All of which means that when it came to the end of my contract with E.on, the experience I might have as a customer via a website seemed at least as important as the potential cost savings of switching supplier. Making my choice of new supplier based on how much effort seemed to have gone into their website was a new experience for me. Many times I've made purchases based on the perceived quality of the item or customer service of the supplier, but never before with a better website experience in mind.

It could be that I'm preaching to the converted here, but for me this was quite a watershed moment. If businesses are to continue making essential administrative functions 'self-service' via the web, then it is vital that they remember what this is replacing: real people, offering real customer service. And just like its human equivalent, if the online customer service experience is notably poor, customers will start to look elsewhere: I certainly did.

I've recently been reading a fairly lightweight, factual book on our Kindle. It's probably been about six months since I've done this, as my wife has had sole custody of the thing for an age, apparently reading Agatha Christie's entire back-catalogue. Anyway, as when I first bought the thing, I have been marvelling at what a nice user-experience it provides. So light, so easy to read, so comfortable to have my thumb by the next-page button and so romp through any given book, never seems to need charging, and so on. It would be fair to say that, as far as I was concerned, the user-experience lacked nothing.

Having recently finished making a vast set of built-in bookshelves for our living room, I have finally got around to unpacking all of our books from their hiding place in the loft. To be fair, we have only been living here for two-and-a-half years...! One of the books unpacked was a rather nice hardcover version of the same book I'm reading on the Kindle. I now seem to recall buying it, nearly new, from a bootsale shortly after it came out. This seemed to be a good excuse to try out a back-to-back comparison, so that night I read the next 3 chapters from the book instead.

The first thing that became apparent is that the Kindle, displaying in my chosen font, size, and spacing, is vastly easier to read. It is also easier to hold whilst lying in bed, and crucially for me, quieter. It's not until you have a tiny baby with the hearing of an owl, and a sleep-deprived wife that you realise how much noise just handling a hardcover book can make.

The second thing I noticed was that the Kindle lacked a whole area of the intended user-experience of the book. The book was full of large colour photographs, content-snippets blown up to full-page quotes, and lots of fun graphic design. The content of the book worked fine without all of this, but its existence added to the overall user-experience enormously. Reading it on the Kindle gave me no complaints at all, but the entire time I could be said to have been missing a whole dimension of the user experience the publisher had intended me to have.

At work we've spent the past 18 months formalising our UX process. Exciting, I know, but stay with me... This has largely been a process of separating out the Information Architecture and User Experience stuff from the visual design. Previously the journey we took from starting a new project to having the client sign-off a finished design was not that well structured. Although we were already working through most of the necessary steps to be able to call it 'UX', it all tended to be lumped under the common heading of 'design', without significant milestones or deliverable documentation.

Now we have a formalised, structured, and to some extent measurable process. This is good for our internal project planning, good for transparency with the client, and makes it easier to justify why we need a particular number of man-hours on a project. Perhaps most importantly though, it gives us a clearer view of what we are actually delivering in the sense ofwhat kindof UX service.

I've been fortunate enough to be driving this work, and this means that it reflects my firm belief that the visual designer needs to be heavily involved in said process. Some time ago I wrote a post for the company blog giving an example that you would not have one designer design a beautiful teapot, only for a usability expert to come along and move the handle and spout to opposite sides so you could actually use it. A designer should really consider all the ways in which a user might actively engage with a product, not just passively, with their eyes. Aesthetic designispart of the user experience, and has the power to make things more or less usable, so it boils down to the fact that the designer needs to be part of the UX process.

Despite this, our UX service leans heavily toward the scientific end of the spectrum. We are largely asking questions about usability: Can a user find what they're looking for quickly and easy?; Is key information obvious to the eye?; Will these links be easy to click on a smartphone?

And this brings me back to the start of this post. The Kindle answers this type of question brilliantly, as far as I'm concerned, and I find it tremendously difficult to criticise. But, and it's a big 'but', there is scope for a vast area of 'good' user-experience to exist outside of these kinds of usability-led UX tests. I might make the same comparison between an mp3 and an LP. The former issousable: click the file, it plays, quality is good. The latter is comparatively irksome: find album, remove disc, place on turntable, clean with carbon brush to remove dust and static, lift arm across, press descender button, quality is OK. BUT, the theatre of going through this process - the 12-inch square artwork on the cover, even the pops and crackles - add an extra dimension to the overall user experience. Essentially the more usable product is actually providing a less-rich user experience.

Now this post has clearly become rather longer than anticipated when I began writing, so in order to ensure thatyouruser experience does not degrade any further, I shall attempt to wrap this up.

What I am getting at is that our next steps in delivering a solid UX process have to be greater consideration for the creation of a rich and engaging user-experience; we need a way to make sure that we consider UX beyond usability, perhaps even to the extent that a great overall experience for the user can come at the expense of perfect usability. From a design point of view it's certainly a more interesting challenge: don't just make this easy to use, make itgreatto use. How we do this I'm not sure, but I look forward to reporting back.

I have recently acquired a new gadget, an apparently simple device for the conversion of breast milk into kinetic energy, sound and poo. What has become apparent over the past three weeks is how poorly designed this device is from a usability perspective.

Commonly cited requirements for a thing to be considered usable often include that it is simple, learnable, memorable, self-explanatory (intuitive), makes use of existing conventions, not prone to error, satisfying to use, and even that it is beautiful. So where does it all go wrong for my new milk-processing machine?

Well, for starters, it isn't simple. At first glance the controls seem perfectly straightforward: there's a hole for milk to go in, and one for waste to come out. But on closer inspection there are a number of holes, all but two of which (mounted either side of the main milk-entry globe) seem capable of delivering waste in various states of decomposition. Not only that, the milk-entry hole is also the main exit point for the release of sound energy: this seems to be an unnecessary and confusing dual purpose. A small amount of sound energy is also emitted from the main waste exit point, though thankfully less frequently.

As for self-explanatory, I have searched all over the device and there are NO instructions whatsoever. If not for the profusion of existing users and community documentation, discovering all of the features of this product would be a near-impossibility. Very disappointing. Moreover I have noticed that frequently the responses of the device are inconsistent in reference to the user input. Ingress of milk should be followed by a recharging period, and yet this is frequently NOT the case.

This leads me to my main gripe - the appalling error handling. Now I understand that a high-end gadget such as this will require a certain amount of experience to operate to its full potential, but there is simply no excuse for the existence of only a single warning signal. Whether the problem is waste related, a request for input of milk, or something more serious, the warning siren is the same. This seems to needlessly lay the onus of responsibility onto the end-user where the fault-finding process is concerned.

In terms of learnability and memorability, it is true that the fundamental operating procedures are not complex, and even taking the aforementioned error-handling into account, finding the correct procedural response to the notification coming from the device is usually a simple process of elimination. However, the key point of failure here is the fact that this device seems intended - in fact required - to be operated on a less than optimal amount of sleep. This deprivation is taken to such extremes at times that even these simple procedures can seem tiresome and complex - truly a flawed design.

Satisfaction in the operation of the device is currently inconsistent, and rather dependent on how it responds to input from the user. This is something that can be frustratingly inconsistent. Anecdotal evidence suggests that satisfaction levels increase significantly over time.

Overall one is forced to conclude that this device is not merely poorly designed, but seemingly not designed at all. It has certainly not undergone effective usability testing (the shared milk-input and siren hole would never have made it through the first round of testing), or even the most basic forms of heuristic development. I truly cannot imagine what the manufacturers were thinking of, and I suspect that they weren't thinking at all.

All this said, this is still a hugely desirable device, and one that has already won itself many plaudits for the simple fact of being extremely aesthetically pleasing. It is rare that a contraption of such clearly flawed interaction design can still win over users, but in this case it has. I feel confident in saying that the beauty inherent in this creation, together with the promise of increasing user satisfaction, outweighs all of the above flaws.

I just wish it came with an instruction manual and some sensible warning lights.

It has recently come to my attention that my previous post could have given the impression that I was referring to the type of false simplicity found in such devices as software 'wizards'. As an addendum to the previous post, I feel I should clarify this point. In such cases, information and choices are hidden from the user with the intention of making a task easier. Often the net result is that (a) the user does not get exactly what they wanted, and (b) there is the ever-present feeling that the very things that have been hidden in order to 'simplify' the process might be what you were looking for all along!

What I was proposing in my last post was simply a situation where there is a need for a task to be completed (registering a new user, making a purchase etc), and two routes through which this could be done. Both would require the same level of input from the user. One would be geared towards the more experienced 'tab to the next form box' type of user, and one would be set up to cater to a less confident audience.

Essentially, I am postulating that, though ultimate ease-of-use should be a feature of any interface or process on the web, this can sometimed come at the expense of expediency. As such, it might not be a bad thing to allow those users that function in the fast lane, so to speak, to make the most of their experience on the web, whilst those less attuned to human-computer interaction are guided in a more controlled, and ultimately helpful way.

I've just got off the phone with my Dad. I'd been talking talking him through the installation and set-up process for DropBox, and came across a rather interesting usability failing.

I should say at this point that DropBox is one of the most useful, and easy-to-use applications I've come across in some time. It enables me to work in the office, and without even thinking about it, know that my files will be waiting for me when I get home. Like all the best technology, it melts into the background and just makes things better.

But the usability failing? That was during the installation process. Having clicked the link to download the file, Dad was presented with a screen of instructions. I confess I was not replicating his actions whilst this was going in, and so was helping 'blind'. Anyway, having downloaded the install file, he told me that he had three windows on the screen, one saying 'Dropbox.exe', one saying 'Do you want to allow changes', and one saying 'Welcome to Dropbox set-up'. Odd, I thought, but assumed he must've already been clicking things to bring up these alert boxes. I told him to click the 'Install' button he could see, but to no avail. When he clicked it, nothing happened. To cut a long story short, the examples on the Dropbox site were realistic enough to completely fool my non-techy Dad into thinking that they'd come from his own computer.

This isn't parental stupidity, as one pixel looks very much like another, no matter where it is on the screen. It is, really, a failure of the author of the page to realise that too realistic an example could actually dupe some users completely. It isn't something I've really thought about before, and until now I'd probably have made the same mistake, but I guarantee that the next time I need to include the same kind of thing on a web page, it'll have 'EXAMPLE' writ large across any mock software boxes!

One of the aspects of website design that is a constant balancing act is choice between new-and-different and old-and-understood. There are many 'design patterns' that users already understand, and using these in a design has a pretty high chance of making your site easier for a new visitor to use. To give a specific example, if I put a bunch of bold text links at the top of the page, in a line, at a similar level to the logo, most people will assume this is the main menu. This is because this particular approach has been used over and over again, and so has become familiar to most regular internet users.

Sometimes this is a good thing. I wouldn't necessarily want to have to reinvent the wheel with each new site I design. Likewise users don’t want to have to learn each new site they come across as a fresh concern. But what if the existing design pattern is wrong? Well, then we have a problem.

I was recently pointed towards a post on uxmovement.com concerning search buttons. It’s a great post, and I recommend having a read, but I have some difficulty imagining that positioning the search button on the left of the box will ever gain much popularity. It is doubtless provable that positioning the button on the left is more usable, but because the existing layout is so very well established I cannot imagine users feeling comfortable with it.

It reminds me of the change in theUK, from right-hand to left-hand side indicator stalks. Sometime around the 1970’s, all the major European manufacturers started producing just one set of column stalks for both left- and right-hand-drive cars, as a cost-saving measure. Previously, the position of the indicator on British cars was on the right. This is for the simple ergonomic reason that you will almost certainly want to change gear and indicate at the same time at some point. It is for this same reason that left-hand-drive cars have the indicator on the left. Perhaps because there were far fewer motorists on the road at the time, or perhaps because the change happened over some years, we (the British motorist) just put up with it and got used to the clunky, less ergonomic set-up of having to operate the indicators and gearlever with the same hand.

Well, now we’re used to it, and it is not uncommon to hear people complain when they drive a Korean or older Japanese car, fitted with an indicator stalk on the right, that it is ‘on the wrong side’. Of course it isn’t: it’s on the best side, from a usability point of view.

Likewise with the article mentioned above. Positioning the search button on the left of the search box might well be better for all sorts of reasons, but I wouldn’t fancy your chances of convincing a billion web users that it was change for the better. Designers and site owners are responsible for these design patterns at the point of inception, and if we get them wrong we may well end up stuck with something we wish had been better thought out in the first place.

Personally, with every Mini I’ve ever owned I’ve always fitted a set of pre 1974 indicator stalks, and enjoyed the superior ergonomics in that part of the car, if not in the rest of it so much.