First off, the critical incident technique is not as new as you probably think it is. This model is actually pretty ancient in so far as within the industrial age. But, it hasn’t always had this name, and in fact kind of didn’t have a name to the practice at all until relatively “recently” by that scale.
What:
Ok, that doesn’t tell you much, does it? Well, the critical incident technique is all about specific events within an experience or design that make deciding contributions to the process at and, and in shaping the overall experience, psychologically, for the user.
Any given one of these instances that have such effects are called incidents. Usually, they are recorded by having a test subject perform a task with known incidents. Upon completing the task, they are then asked to tell the listener a story.
As one of the incidents expected is mentioned, everything associated with it, which the user says, is noted. It’s a pretty simple process, though analyzing the data you get from this can be kind of a headache.
Why the Headache:
Well, it’s fluffy “soft” analytics from users. The problem this brings up is that there’s no digital solution to mass process this kind of data and generate hard curves and graphs to illustrate the incidents that are of good result and the ones that are bad.
We’re on the brink of software that can do this, actually. But it’s not here yet.
Why Use It:
Well, you don’t want to use this technique until the beta phase of a project, when you have a clear set of events to test that aren’t messy half-real theories, if you will. But, when you’re at this stage, this can tell you which features have to be altered, and other similar things, before it’s really ready to launch. But, you’re far enough along that it’s a final polishing step easy to make happen and devote the last bit of work exclusively to.
A Few Examples:
I’d like to give you a couple real world examples of this, but most companies don’t show this testing process in a transparent and public way, so those are hard to come by. But we don’t need that, given how simple this really is.
A good hypothetical example of this would be in graphical software. When a user wants to delete a layer or other higher level construct inside the project, containing data that would be lost forever, you’ll need to warn them that it’s going to happen.
The incident would be a recording of a user being either warned off from it and glad of it, told ahead of time it would be permanent and so is unsurprised, or be annoyed that it warned them. It would also reveal how effective the warning is, by how many people are shocked they cannot undo such a thing.
Another example would be testing the login and sign up for a web-based service. It would show how frustrated, confused, appeased with simplicity or the like that a user is after enduring it. Similar testing of them having to log back in when sync expires, having to recover a lost password, and other things are also often tested in this manner.
I know these aren’t a lot of examples of critical incident technique, but really, it’s so simple to do that the two I gave sum up the whole of it, in down to earth terms!
