Category Archives: usability

Giving a shit

Sturgeon’s law states that “90% of everything is crap”. He was probably an optimist. Here are some recent examples of the sort of crap I come across day to day:

The school selection website

My wife and I had to select which secondary school we want out son to go to, an important decision for our family. We had to do this via a website created on behalf of Swindon council. I won’t bore you with all the painful details, but only an impressive combination of incompetence and apathy could have produced something so egregiously awful. At the end of the process we got an error message and the promised confirmation email never arrived. We were left feeling confused and angry. Every other parent we spoke to had a similar experience.

The ATM

Feast your eyes on my local ATM:

ctnybk8wiaaqkza-jpg-large

Yes, that’s right, the buttons aren’t correctly aligned with the screen, so they have added some shonky visual cues in a feeble attempt to compensate for it. They failed – I have pressed the wrong button more than once. If they couldn’t move the buttons, why didn’t they just change the text positions in the software? I would like to know what sort of horrific set of bad decisions and sloppy planning led to this laughably bad design.

The in-flight meal

Check out this British Airways in-flight meal I was served:

IMG_1083.jpg

Behold, the cutlery is in a sealed plastic bag in the pasta. To get at your cutlery you have to open a slippery plastic bag covered in sauce with your fingers, which are now also covered in sauce. Who could have possibly have thought this was a good experience? You might as well just eat the pasta with your fingers. Or stick your face in the plate. Maybe the subliminal message is: if you won’t pay for business class we are going to make you eat like an animal.


You don’t have to look very hard to find crappy design. Badly designed parking buildings, confusing ticket machines, painful to use Sat Navs, packaging that is almost impossible to open, web forms that won’t let you use a space or a dash in a telephone number. I could go on, but I’m sure you could come up with plenty of examples from your own life. The most frustrating thing is that these issues could have been avoided with a little bit of thought and care. I doubt it would have added more than an extra 1% more effort or cost to get them right.

Crappy products and services make everyone’s life worse. Hold yourself to a higher standard. Take pride in your work. Do usability tests. Get feedback from your users. Fix things that are broken. Keep improving. Above all, give a shit.

First impressions count

Imagine you are on a blind date. You’ve heard great things about how funny and intelligent your date is and they are certainly very attractive. But it isn’t going well. They just sit there, staring at you with glassy eyes. Nothing you say gets more than a nod or a shake of the head. Maybe they are just shy, but you are never going to find out about their hidden depths if you climb out of the toilet window and run off into the night after twenty minutes.

Now imagine you have downloaded some new software. You have high expectations and your credit card to hand. But you just can’t figure out how to get started. It just sits there, a blank canvas. Totally inscrutable. Offering no clue as to what you should do next. How long would you click buttons and examine the menus before you gave up and downloaded a competing product. Two minutes perhaps? Competing products are only a few clicks away, after all.

As developers we spend months or years lovingly crafting our products. This makes it very hard for us to see them with the same eyes as potential customers. But those first few minutes are crucial for converting a download into a sale. Give the user some pointers on what to do first: show a set-up wizard, quick start guide or tutorial when the application first runs; populate the application with sample data; show hint text or images in the GUI (e.g. grey “start by typing your email here” text in the background of an edit field). If they feel they are making some progress within those first few minutes they are much more likely to buy. It really isn’t difficult to do, and yet it will probably have a bigger effect on your conversion rate than adding a complex feature that may take weeks or months to write.

I remember reading about usability problems with one of the early wordprocessor packages. Users weren’t used to wordprocessors and many just sat there, not knowing what to do. The solution was simple – to show a flashing cursor at the top of the page as a cue that this is where text would appear when they started typing. Usability improvements are usually simple in retrospect. But this apparently trivial change made a big difference to the initial experience.

How good a job are you doing at engaging users in those crucial first few minutes? Are they hitting the ground running, or just hitting a brick wall? Are you sure? Try comparing your download to conversion ratio to industry averages. Better still, do some testing. Find a few people in your target market that haven’t used your software before and watch them try to use it. Don’t help them, no matter how much you want to. It is often a painful experience, but I have yet to speak to anyone who has tried it and didn’t find it incredibly useful. Remember, you only get one chance to make a good first impression.

This article was also published as a guest post in the upload.com newsletter.

10 things non-technical users don’t understand about your software

If you are writing consumer software you have to understand that you and your average user have a very different level of understanding of computers. When you first start doing support it can be a shock to realize just how vast this gulf is. It doesn’t mean that your users are stupid, just that they haven’t spent the thousands of hours in front of a computer that you have. Below I have summarized a few of the things I have come to understand about non-techies through answering thousands of support requests relating to my own table planning software.

1. Copy and paste

It is very clear from many support emails I have received that users will often re-type a licence key emailed to them because they don’t know how to (or even that they can) copy and paste text. Yes, really. You can mitigate this to some extent by including instructions on how to copy and paste where relevant and making licence keys easy to type (short and without ambiguous characters, e.g. ‘0’ and ‘o’).

2. The difference between web and native applications

Many users are used to web applications and don’t understand that they need to download and install new versions of desktop software to get access to the features in a new version. You can avoid this by automating the update process, but this can be pretty catastrophic if you get it wrong.

3. Data storage

Many users don’t understand how or where data is stored or even that it is separate from the application. They don’t understand that some data is stored on their local harddisk and some is stored ‘in the cloud’. And they don’t understand the difference between storage in a file, a database or the Windows registry. Consequently, when they install a desktop app on a new machine they are often surprised that it can’t automatically access the documents they created on a previous machine. So it is worth having something in your FAQ about moving from one machine to another.

Given that users don’t understand the basics of data storage it should come as no surprise that they also don’t understand the concept of file formats either. For example when told to ‘save a .xlsx file as a .csv file’ some users will simply change the file extension from .xlsx to .csv and be surprised when the resultant .csv file is gibberish when they open it in Excel. You can try to avoid this by providing clear step-by-step instructions on how to save a .xlsx file as a .csv file.

4. The jargon you use

Using terms that your users don’t understand can be very off-putting. For example, non-techies have no idea what a “dialog” is, let alone a “modal dialog”. Just call it a “window”.

5. Right click

Some users have not discovered (or will not think to try) clicking the right mouse button. You should therefore never put something only in a right click menu or anywhere else that it can’t easily be discovered.

6. Concurrency

Some applications can handle concurrent access (e.g. client-server and web-based apps) others can’t (e.g. most desktop apps). But many users assume that all software can be safely used by multiple concurrent users. If your software can’t it might be worth spelling this out in your marketing so as not to raise false expectations.

7. What changes can be reversed

Techies are happy to play with software to see what it does. They aren’t usually too worried about trying things because they can rely on some combination to undo, version control and backups to reverse most changes and they can usually judge when a change won’t be reversible. Non-technical users aren’t so confident and won’t try things in the same way. In fact some of them seem to think that a wrong move could cause the computer to burst into flames. So try to stick to conventions they will understand (e.g. on Windows those used by MS Office and Outlook) and offer step-by-step guidance for complex tasks.

8. The need for backups

Every few days I get an email from someone who has lost all their data because they had a major hardware problem and no backups on a separate device. Sometimes this is because they don’t even realize the data is stored on their computer. You can mention the need for back-ups in your documentation and/or in the software, but it is unlikely to make much difference. History shows that this is a lesson most people have to learn the hard way (techies included). Mentioning it doesn’t hurt though and it might help to defuse an angry users if you point it out to them after the event.

9. That they should read the documentation

People are using your software because they have things to do. Like it or not, your beloved software is just a means to that end. Although some users will read documentation, most consider it a waste of their precious time. In fact, support emails I receive provide incontrovertible evidence that some users won’t even read a single sentence of text in an error message explaining what the problem is. This means you need to write clear and concise documentation, but you also should develop your software under the assumption that most users won’t read it. That is where usability testing comes in.

10. Problem exists between keyboard and chair

Unskilled users often don’t realize how unskilled they are. Consequently they may blame your software for problems that are of their own making. One just has to be as polite as possible in such cases. Making your customer feel stupid is never great for business. If it is clear that the customer doesn’t have a sufficient level of skill to use your software, you should politely suggest that it “obviously isn’t ideal for their requirements” and offer to refund them. However, if several people have the same problem then you need to change your product to be a better fit for your users (changing your users to be a better fit to your software unfortunately not being an option for most of us).

Have you been caught out by assuming technical knowlege that your users don’t have? If so, please leave a comment below.

Easy screen sharing with Skype

The latest version of Skype allows you to share all or part of your screen with another Skype user in a couple of clicks.

This can be incredibly useful. So far I have used it for:

  • support – Sometimes email just doesn’t cut it. If your customer has Skype, you can use screen sharing to see exactly what your customer is doing while talking to them.
  • remote usability testingUsability testing is very important. But luring a stream of  fresh victims  to your office to take part is a logistical headache. If you use Skype screen sharing neither of you has to leave the comfort of your own computer. I have used it successully to do usability testing with people on the other side of the world.

Skype screen sharing has its limitation. The images are bit blurry, there is some latency and you can’t interact with the remote computer (as you can with services such as Copilot). But it is good enough for most purposes, and it’s free!

If you are going to be using Skype much, then I strongly recommend buying a USB headset. It is much more comfortable than holding a phone to your ear for extended periods and it keeps your hands free for typing. I use a Logitech headset and I have been quite happy with it. I sometimes get sweaty ears during a long call, but it seems a small price to pay.

Logitech ClearChat Pro USB on amazon.com (affiliate link)

Logitech ClearChat Pro USB on amazon.co.uk (affiliate link)

Ten mistakes microISVs make

Here is a video of the “Ten mistakes microISVs make” talk I gave at the Software Industry Conference 2009 in Boston. Total duration: 27 minutes.

The slides aren’t terribly easy to read, due to the resizing and compression of the video. But you can also download the paper and slides:

A big thank you to Alwin and Sytske of collectorz.com for doing the video. You can read Alwin’s excellent software marketing blog at alwinhoogerdijk.com.

Feel free to embed this video, as long as you include a credit and a link back to this blog.

How many of these mistakes have you made? How many are you still making?

GraphicDesignerToolbox

I launched my product a year ago, but so far haven’t had much luck selling it. I desperately needed advice from a person that could take a look at my situation and help figure out what’s wrong and how to move on. Andy Brice has been through all this and knew exactly what I was struggling with.

Simon Strandgaard, www.GraphicDesignerToolbox.com

gdt-screenshot

GraphicDesignerToolbox is a Mac OS X application for creating computer generated graphics. It allows users to snap together generative and filter blocks to create a vast range of different types of images, without any drawing or programming. It is an impressively slick and well engineered piece of software. But sales were unsatisfactory. I did some consulting for the author, Simon Strandgaard, focussed on improving the marketing and the user’s initial experience of the product. As a result he has made a lot of changes, including:

  • Re-thought the product positioning, marketing message and target customer.
  • Renamed the application to GraphicDesignerToolbox (from the less descriptive ToolboxApp).
  • Moved the website from ToolboxApp.com to GraphicDesignerToolbox.com.
  • Commissioned a new application icon.
  • Completely rewritten the website.
  • Improved the initial user experience with a quick tour and easy to load samples.
  • Improved the product documentation.
  • Changed the trial model.
  • Increased the price.
  • Released version 1.0.

You can see captures of old and new versions of the website below:

toolboxapp_cropped1

Old home page - click to enlarge

graphicdesignertoolbox

New home page - click to enlarge

It is has been very rewarding to see the product and marketing improve so much in just three months. Especially as someone else was doing all the hard work! I think the changes are a huge improvement all round and I wish Simon and GraphicDesignerToolbox every success. v1.0 was released today and Simon tells me he has sold as many licences today as in the previous 5 months.

If you have a Mac you can head over to GraphicDesignerToolbox.com and download the trial.