Tech Usability

I love good design that’s easy to use, so here’s a collection of rants and hints about it all

Tech Usability #1: Introduction to usabilityDecember 5th, 2008

If you ever visit an Asda or Tesco (other supermarkets are available), you might see a small number of self-service tills at the end. I guess the point of these tills is to make it quicker for the customer to pay for their goods, particularly if they only have a handful of items to pay for. But there’s one big problem with these tills which slows things down: they aren’t very useable.

A self-service till at Tesco. Image by Cowfish

A self-service till at Tesco. Image
by Cowfish

OK, before I go all out on the attack, the system does have some good points: the buttons are nice and big, which makes it quicker and easier to hit them (I’ll explain why in a future article); and I’ve certainly used worse touch screens in my life. But still; they’re annoying, and there are design elements that slows things down. Small things, like having the customer to press “Finish & Pay” before paying (why not just have the customer place the money into the slot?) and requiring every single item be ‘bagged’ (that is, be placed in the bagging area) before you continue to scan the next item and not letting you put your own bag on there.

Basically, usability matters — whether it’s on the web, or just some random piece of technology. It might be something small (like not requiring the customer press a button before paying), but it could make all the difference. Things should be simple and intuitive to use: in fact, I claim (perhaps wrongly) that if something is well designed then it shouldn’t need any kind of sign or copy with instructions for the user (there should be no need for ‘press here’ or ‘pull’). It should be a joy to use the product.

Of course, no designer has all the answers when it comes to intuitive design and knowing how the product will be used, which is why testing is so important. If you sit a prospective user down at a computer (and note that a prospective user is usually not the client!) and invite them to use the system, you will gain a lot of information about what you got right and what you got wrong, just by watching them. Do they keep going to the bottom of the page to look for your company’s contact information? That’s where you should put your company’s contact information. Many companies get usability wrong, by assuming that if a user doesn’t know how to use their system then they are clueless idiots, rather than the problem being with the software itself.

Note that customer support is a great method of getting user feedback! If you find out what the users are thinking by looking at error and access logs, watching out for general trends and habits, and actually inviting feedback (Get Satisfaction is a great tool for this), you’ll learn how to make your site more useable. Instead of going against the grain and telling the users how they should use the product, a good designer will help make it easier to use it in that way. A good example is Twitter‘s @replies. This started off as an unofficial way of replying to each other’s messages, and once the guys at Twitter noticed this trend they built in all sorts of features which uses the @reply.

So, in conclusion, usability is (in my opinion) one of the most important parts of any kind of product — be it a physical item, software, or a website. Users should be listened to, software and websites should be tested, and results should be implemented.

“[Design is] not just what it looks like and feels like. Design is how it works.” – Steve Jobs

The Accessible Web #1: Intro to WCAG2November 21st, 2008

The first in an ongoing series of articles about web accessibility issues, tips, tricks, and standards.

The new standard for accessibility on the web — WCAG2 — is almost with us, with the final publication of the standards expected to happen by the time the year is out. These new guidelines are a step forward from WCAG1, which was published back in 1999 and is severely outdated. WCAG isn’t as well known as some of the other WC3 standards, but in my opinion is just as important. Hopefully this article will serve as an introduction to the guidelines for when they are mentioned in future Accessible Web posts.

With WCAG1, latest technologies aren’t taken into account, so it’s very difficult to create a site that follows the guidelines that make use of these modern technologies. WCAG2 is technology independant, which should hopefully mean that in another ten years time when things have moved on again, WCAG2 will still be relevant.

WCAG2 introduces four principles to web accessibility: any content should be perceivable, operable, understandable, and robust. This means that the content should be visible to the user in some way (whether that is through text, sound, or touch), the user should be able to easily interact with the content, the content and user interface of the site should be easy enough to be understand by anybody, and it should be possible to access the site from any kind of browser — not just regular browsers such as Internet Explorer and Firefox. These four principles are the pillars behind the whole guideline documentation, and are the pillars behind the future articles within this series.

As with WCAG1, there are three levels of conformance. Each criteria in WCAG is leveled either A, AA, or AAA. In order to conform to Level A, all Level A criteria must be met. To conform to Level AA you should meet all Level AA and A criteria, and to conform to Level AAA all three levels should be met. This might sound confusing at first, but if you think of the success criteria as “meets all points for this level and all those below it”, hopefully it should all make sense.

Checking sites through WCAG may seem a bit of a waste of time, but accessibility is important to a website because not only does it improve the experience with those with disabilities, it also improves the experience for those without disabilities (this will be mentioned in further detail in another series of articles, about web usability). There are three levels of compliance, with the lowest level (Level A) being common sense and good design practice anyway.

Finally, it is worth noting that in this series of articles, I will be referring and linking to the relevant guideline in WCAG2 whenever they appear. From there you can find the conformance level, find more details on implementation of the guideline, and find out the different pros and cons of following the guideline which simply can’t be outlined in a weekly 500 word article.

Further reading