Brought to us by Apple and Microsoft in the 1980s, the impact of the Graphical User Interface (or GUI) was undeniable. Prior to GUIs computer programs had been driven by inputting terms and bits of code to achieve a desired effect. With GUIs it became an issue of clicking on icons and links, etc. to achieve the same effect. So, rather than memorizing UNIX commands and the like - strictly the domain of the technically minded - GUIs brought using computers into the realm of regular folk. Even the slowest accounts clerk could now print an invoice, all at the click of a button.
Hey - that's not the right button!
That was, of course, if you could find the correct button... or indeed if you recognized the correct button as being the correct button. GUIs were great - except when they weren't. Very quickly the term "Intuitive Interface" emerged, meaning an GUI that a user could easily recognize all the bells and whistles and how to use them. But how did you determine whether an interface design was intuitive or not?
Get me a scientist!
The birth of the Graphical User Interface (or GUI) spurred the birth of a new 'science' - Graphical User Interface testing. Wikipedia calls GUI testing "the process of testing a product's graphical user interface to ensure it meets its specifications". When people created programs, they handed their designs over to GUI experts who tested them to see how people interacted with the designs, and where pitfalls lay.
Although GUI testing still takes place, the design discipline has matured. These days designers work within a set of guidelines and principals that are time tested and do not require further consideration. However, GUI testing can still pay dividends for smaller companies with websites they are designing in-house. It is a great way to establish whether your website is as user-friendly and accessible as it should be.
How do I test my website's 'GUI'?
Scientific endeavor is basically driven by conjecture. Scientists establish a theory, which they test to be correct or incorrect. GUI testing is slightly different. Rather than predicting where problems might occur and testing whether it is the case, it is driven by pure observation.
Essentially, the (extremely) bare bones of GUI testing are as follows:
1. Make a list of a website's functions
Make a note of everything that your website can do as far as the user is concerned. That might include accessing a file, or printing a page, or converting a webpage into a .PDF document - whatever it is make a detailed list of everything your website can do.
2. Make a list of 'tasks' for your test subjects to complete
Basically, you are going to test people doing things with your website. To do this you need to establish a set of instructions for your 'subjects' to use. This task list is everything a user can do with your website.
For example:
1. Convert a news item into a .PDF document.
2. Send a news item to your friend at test@websitename.com.
3. Etc.
This needs to be a fully comprehensive list.
3. 'Benchmark' how long you would expect someone to take to do each task
You can be generous here - if you state that sending a news item to a friend should only take 5 seconds, anything less than this would be ok for you.
4. Observe people using your website and record times
Get as many people as possible to perform all the website's functions and write down how long it takes them to do each one. Any problem areas should soon emerge. For example, if it takes an average of 15 seconds for people to be able to send a news item to a friend, that's substantially more than your benchmark. With all this data in place, you can now set about fixing the problems.
5. Observe people again, but this time focus on problem areas
This is going to be intensive work, but well worth the effort. You need to physically observe people trying to complete the tasks where there are problems. Some people record users using video cameras and look at the tapes later, but that might be an unnecessary step.
6. Make a note of what people do when they fail to complete a 'task'
Often this might mean printing screenshots of your website's various pages, and putting Xs where users click to perform a particular task. Basically though it is recording how they fail to complete a task. Obviously, each error a particular user makes could just be because his/her inability, so you need to compare results and establish errors where the majority of those taking a test fail to complete a task. The results might indicate that a particular icon is being mistaken as being for a task it is not used for, or a vital element of completing a task is somehow hidden from a user's view because of poor sequencing. Whatever it is, observation will reveal the problem.
7. Ask those taking a test how they would fix a problem
If people consistently hit the wrong icon to print a screen, ask your 'testers' what they would expect to see instead to avoid doing this. If there is a problem with a sequence of events that lead to someone not being able to complete a task, ask those taking the test how they think the flow should go. Whatever the issue, ask the folks in the test to give their suggestions.
8. Redesign
Compile the feedback from those taking the test and give it to your developer. This should be pretty useful stuff - areas that users find the site difficult to use and suggestions on how to improve them. Rather than seeing this as criticism, in my experience people step up to the challenge of ensuring a redesign doesn't have the same problems again.
9. Test again
Go through the process as many times as you can. Develop more iterations of your website design, and test them, until eventually the majority of those taking a test can complete the majority of the tasks within your benchmark times. At that stage your website is pleasing most of the people, most of the time, and so should be considered a success!
