The cognitive walkthrough isn’t going to take very long to explain, so I’ll be spending a good deal of time explaining its strengths and weaknesses to make this worth your while. This seems to be a really popular form of assessment and testing, and I can understand why, but I’m not as big of a fan of this as some, because it’s so unrefined at this point.
What it Is:
The cognitive walkthrough is a test of usability in which a specific task’s ease of learning, ease of adoption and ease of reflex learning is gauged by performing the task with a number of users across the platforms to which the design is being deployed.
So, it’s basically, more or less, every usability test ever known. And that brings us to the biggest problem with this.
The Problem:
It’s just a generality. There’s no clear set of models widely documented and adopted for this, there’s no de facto science to learn, and no clear definition to set it apart from a lot of other testing mentalities for usability.
Now, that’s not to say that the idea behind it isn’t defined and unique, but for now, there’s no refined model of execution to actually apply this mindset. It’s hard to adopt something with poorly refined guidelines.
The Benefits:
If this were able to be implemented properly, with clearly defined tenets and best practices and the like, then there would be benefits to this approach, as it’s more or less measuring the actual every day use of a design, versus clinical metrics of design.
This would allow you to really see how well something worked in realistic practice, which isn’t the same as how math or clinical tests actually portray. This has been a concept long sought by programmers, product developers, engineers and a host of other disciplines, because that daily use versus clinical functionality dilemma is indeed a really big one.
The Downsides:
The downsides, in this same fairytale land where this is even really defined enough to apply literally, are also somewhat numerous, though.
The biggest downside would be that it’d be hard to measure this, even with defined metrics in place, and controlled testing and experimentation would be very short in availability during the design period, meaning hoping for a lot of value of smaller testing times.
That’s a risky proposition, and one that, again, is largely the result of no real common practices for this being available.
How to Fix this:
Honestly, without some kind of … well … something being invented to alleviate lack of clarity with this and lack of practical controlled time to test, there’s not much you can do to fix it.
However, a good alternate approach would be to implement a less removed form of this into other testing models. This is being done to some level by many people, and I think that’s probably where this idea is best kept, because it’s not anything real on its own, sadly.
Conclusion:
Like I said, the cognitive walkthrough concept is very easy to explain, but it took some doing to explain why there’s not much to explain.
