more users than you think

In the fresh light of day, I have a slightly different way of expressing the ideas in yesterday’s rant

When we’re designing and developing a system (and hopefully we do those two things at the same time), most of us have checklists of some kind in place to ensure that we consider the system’s various users (end users, managers, administrators, support persons, etc). What we often forget, though, is to consider another important group – programmers. We take great pains over user experience, always thinking that means only those folks who’ll use the system for it’s intended purpose. But unless we consider the user experience of the developers, the other users may never see the features they really want, because the code is too impenetrable to work with.

how not to design a website

Yesterday I had a utility bill to pay, so I went to the utility company’s website to pay it. By the end of the exercise I was so frustrated I contemplated switching my custom to a different supplier. Let me explain…

First of all, I only discovered I needed to pay the bill when I received a red overdue reminder, threatening to cut off our supply unless I paid immediately. This is the third time this company has failed to send me the original bill, so already my user experience of their service is starting at a low point. Anyway, I go to their website, credit card in hand, and I log on to my account. The login form is buried within the registration form, so it took me a couple of minutes to find it.

Once logged in, up comes a page listing my account details, including two incorrect facts:

  1. my current balance is £0.00; and
  2. I last logged in today

There’s also a very cryptic message telling me that, as the site is undergoing maintenance at the moment, I’ll have to use my “old account” if I wish to view my payment history. I have no “new account”, and therefore no idea what an “old account” might be. I decide to ignore the message, and click through to the “pay your bill” page (not “pay my bill”, note).

I discover that the page has tried to complete some of the fields for me, but unfortunately the formatting is completely mangled. I daren’t risk filling in the form, because I have little idea which text relates to what. After a couple of attempts to re-display the page – each attempt forcing me to navigate there again – I decide to try accessing the site from IE (I’m a firefox user). It works, of course, and I’m now able to complete the payment form.

The field for my credit card number says “no spaces!” above it. The drop-down to select the card type says: “if you have card XXX, select YYY.” And there are a couple of other fields with caveats too. Finally I complete my payment, and I’m taken to a page which says just “click here to go to your accounts.” No thank-you, no payment reference, no automatic re-direction; and your accounts again.

This is the website of a company that was once a nationalized (state-owned) monopoly. Historically, my experience of those organizations was that their rules come first, and the customer seems to be just an inconvenience. Their current website gives this particular user that same kind of feeling. Rules is rules. We can’t write the two lines of code needed to take out the spaces you might type in your card number. We can’t list the correct card types. We can’t make the site work in all browsers. You’ll do things our way. And by the way, this is our site; we aren’t here to provide a service; they are your accounts, so you do all the work. Keep off the grass!

For me, when designing a software system (web front end or otherwise), it’s the details of the user experience that can make or break a project. If it’s ugly or hard, it’s wrong. If the user is helped, guided and delighted, the rest will often be really easy – and in my experience the system will tend to have very few defects. Whenever possible I push for software that can be installed and used without any documentation, and with a user experience that is easy, natural and error-free. I believe that aiming this high helps keep defects out of the code. And that’s why net promoter score is a critical measure of product (and hence project, team and process) success.

trees? who needs trees!

bird Yesterday I took delivery of a new headset to make Skype and conference calls with remote clients easier. As a product I’m pleased with it so far, and it worked correctly right out of the box. Full marks for usability. The manual comprises 32 dense pages of small type giving (what I assume to be) the same instructions in sixteen different languages. Here’s the English section:

  1. Plug headset into available USB port.
  2. Put headset on.

That’s it. Repeated fifteen more times. And I had to unfold the sheet twice to find that.

Wouldn’t a diagram have sufficed, I hear you ask? My thoughts exactly. Until I noticed that there was a diagram. Actually two. One for each step in the process.

I’ve kept this manual, alongside those for every other product I’ve ever purchased, just in case I need to refer to it in future…

language matters in UI design

I’m easily confused, and all too often I construe the wrong meaning from something completely innocuous. The UI for Google’s new online aggregator (thanks Clarke for the link) is a case in point. I was trying out this new (to me) service today and I kept getting lost. Because there’s a menu-link labelled read items. It took the “read” part to mean “peruse”, and to be an imperative participle of the verb “to read”. Later I realised it could mean “consumed” – it could be the past participle of the same verb, being used as an adjective to identify those items I’ve already …er… read. The link might take me to a reader, or to an archive. I’m still not sure which it does. Ho hum.