Wow, alright internet. You actually had me with this one for a while. Even in working with usability as a designer, as a programmer, as a project leader and several other positions, before asked about the context of use analysis concept. That’s saying something. Soon as I heard it, given how the term sounds, I expected it to be another buzzword.
Having donned my armor to gripe about buzzwords, I looked around, and I really had to dig to get a clear definition of the context of use analysis. This length of time before finding clear definitions only reinforced my belief that it was a keyword, and so my ire grew like a flame.
But Wait:
When I finally found out what this was, I was never happier to be wrong simply because of the bulk of internet topics of late have been nothing but buzzwords for us to refute or needlessly define.
No, context of use isn’t a buzzword, but this idea does have some problems, and a lot of them are similar to cognitive walkthrough problems. I’m getting ahead of myself though. Let’s talk about what it is, and why it’s sought after, before getting into its faults and benefits, shall we?
What is It:
Context of use is basically a theoretical set of sciences based around the principle of implied design and learning. It’s mostly for software and web interface design, though other industries have to dabble.
As we know in UX, it’s ideal for an interface to be kind of obvious in what things do. This is a core to the way GUI has evolved. Things like scrollbars, buttons, tabs and other such things are used because representing them in those obvious concepts makes them easy to get used to.
The idea behind context of use science and analysis is to put forth a model of usability design and testing that focuses on implementing this effect beyond just the natural tendency of GUI. It also works to set up metrics, standards and other things to really make this a stable science.
Why this is Good:
If this can be refined so that we can be sure on what practices to act on in order to work around it, there are quite a few benefits. The biggest of these is that a fully formed science around design and testing for cognitive design would benefit future software in tremendous ways.
If you can get at least the simplest truly useful things done in a system, merely by a few mites of poking and prodding deductively, then you have a success, and a hook. Immediate accomplishment makes the software feel easy to adopt.
Impenetrable software is … impenetrable.
How to Do It Now:
This is something with no agreed best practices, models of implementation and the like at the moment. That will change in a year’s time. For now, though, this can be implemented in a simpler, more sparse form. It still works great though.
Simply have the same principle behind storyboards in mind when designing layout, labels, aesthetics, navigation and groupings. Test for how quickly a user can intuitively do something without training.
Conclusion:
The one caveat with context of use analysis is that it’s not good to tackle computer novices or computer illiteracy.
