June 17, 2011
More On User Experience Design - UX Testing, Heuristics & OptimisationTo follow up on previous posts and screencasts on acceptance test-driven UI/UX design, and to satisfy those of you who were complaining that "ah, but there's more to it than that" (yes, we know), just a few more thoughts about that process of UI design.
First of all, user experience design is like any other kind of design, in so much as we're very unlikely to get it right first time. So there's a need to iterate our designs and to evolve them based on feedback. As you'd probably expect, the best source of feedback for user experience design is - er, well - user experience.
We should present our designs to users and learn lessons from watching them trying to use them to do the things they need to do using our application.
Experience teaches us that the most effective way to test a user interface design for basic design flaws is to find examples of the kind of people who will be using it, set them some key tasks to complete using the application (e.g., based on your use cases or user stories) and then stand back and watch. Do not interfere until they get stuck and really need help. Don't give them a user manual, or any instructions at all. As much as possible, let the user interface speak for itself.
When the user gets stuck and can't make progress with the task, make a note of exactly where they got stuck, and at that point you can have an discussion with them to try and ascertain why they're stuck. For example, is there an action they wish to perform but they can't see how they can invoke it? Or are they unsure as to what effect their actions are having and can't see where they are in the process? Or have they made a mistake and can't find a way to undo it? Perhaps they can't make sense of the conceptual model of the interface? What is that thing with a hat on supposed to represent? What does the button with the lightning bolt icon do?
You may be surprised to hear that users get stuck for one of only a small set of reasons:
* Lack of comprehension of the UI ("what does that icon mean? What does that button do")
* Lack of visibility of functions ("how do I do this?")
* Lack of contextual information or reuse of input data ("it wants me to enter that file path again, but I've forgotten it")
* Lack of consistency ("why does the 'OK' button on this dialogue do something different to the 'OK' button on that dialogue?")
* Lack of meaningful feedback ("what happened whan I clicked that button?")
* Inability to go back from mistakes ("how can I undo this?")
* The application not protecting them from avoidable mistakes ("I hit delete but it didn't warn me that I'd lose my data forever")
* Show-stopping bugs in the software ("what the f**k just happened there?")
* Poor system responsiveness and performance ("It seems to have stopped responding")
Usability testing is the process of uncovering UX "smells", things that make your UI harder to learn and to use. After observing a reasonable selection of potential users trying to complete key tasks with your application, you should have built up a statistical profile that gives a good indication of where the smells are in your UX design.
You can then feed this back into design, and refactor the user experience to eliminate the most basic smells.
Then rinse and repeat with a new sample set of users until you have a UX that nobody gets stuck on.
Once you have a UX that is fundamentally sound - i.e., users can do their jobs with it and don't have to climb a steep learning curve to be productive - you can think about taking UX testing to the next level.
Your user experience may be usable for beginners, but I'm sure we've all worked with applications that were a doddle to learn but a real drag to use. In particular, duplication of sequences of user actions can be a pain in the behind.
When I study my own workflows - for example, how I get a blog post out of mind and published on my site - I see myself performing the same repetitive actions over and over again. If I wanted to optimise that experience, I'd record my actions and then set about creating "shortcuts" for those often-repeated tasks to put less burden on me as the user and more burden on the application.
This is very much like refactoring duplication out of code. Look for what the common logic is. It always goes to the same blog at the same URL. Then look at what's different each time. Well, obviously the actual content of the blog post is different - so there's one parameter. And I tend to post under different tags, so there's another parameter. I could write a macro for my text editor that logs into my blog admin page, gets the list of tags and prompts me to select the ones I want to post under, and then logs into my blog server and submits the post as a JSON request. This would cut out about 2-3 steps that make posting blogs a bit of a fag.
Duplication of inputs is another thing that can be refactored. For example, the last set of tags I selected when I posted on my blog could be selected by default, so I just have to hit the "OK" button if I'm posting about the same subjects as last time.
By carefully observing what users do, and by iteratively eliminating obvious duplication and creating shortcuts for experienced users, we can streamline the user experience without impacting on how easy it is for new users to learn.
And now here's a funny thing: most of the UX smells I've mentioned so far can actually be identified heuristically. That is, we can inspect a UX design and spot many of these design problems without going to the expense of having users test the UI. Just like we can spot potential code maintainability problems without having to watch programmers trying to make changes to the code.
This kind of analysis can also help us weed out critical system paths that might benefit from performance optimisation to speed up a task. And it's also sometimes necessary to deliberately "choke" system performance for the sake of usability (I worked on a CAD tool once where screen pans were so fast it make users feel dizzy).
Indeed, we can apply heuristics like "users should be protected from making costly mistakes" and "users should have to remember as little as possible" in the design process itself as a set of organising principles for UI/UX design.
By applying a test-drive or scenario-driven approach, iteratively and with both heuristic and user testing throughout, we are far more likely to end up with a user experience that's both fundamentally learnable and usable for beginners, but also streamlined and flexible for more experienced users.
Couple that with the talents of a good graphic designer and/or animator and you can add "aesthetically pleasing" and even "satisfying" to the final user experience.
AND ANOTHER THING: Just after I posted this, I thought I'd better add one more titbit of UX wisdom. What seems liken a great UI design when you test an application in isolation can turn out to be quite poor when you test it in a wider context. e.G., you street map app may have scored 10/10 in the usability lab, but on a busy street when the user's got the dog lead in the other hand and etc etc it may be a very different kettle of fish. I've written before about the potentially huge value of "model offices" - simulated usage environments that test software in a wider context. They can be very powerful tools for UX design.
Posted 7 years, 1 month ago on June 17, 2011