Key-stroke Level Model
Predictive behaviour models are heuristic evaluations, that help product designers to predict and understand, how the interface will perform a task.
I recently decided to add few new heuristics methods into my toolset:
- Keystroke-level-model (KLM)
- Fitts’s law
- Hick's law
Heuristic evaluations cannot replace testing with real users. But especially in enterprise environment, they are helpful in many situations:
- Compare two variants. When building up the design framework, the designer is making many small decisions along the way. It might be not time and cost effective to set-up a number of user testing sessions for each of these. Heuristic evaluations can also guide opinionated stakeholders feedback and introduce measurable UI quality metric.
- Common benchmarking. When having multiple product bundles, a common method how to measure time on task enables teams to compose the result into overall user journeys.
- Project OKRs. The primary objective of our product is to reduce time-on-task by {N}%. Every next feature and improvement should bring us closer to the goal, and heuristics such as KLM helps us to measure this improvement.
- User testing. Even that theoretical heuristic evaluations can not replace user testing on real users, sometimes there is no other way to evaluate the design, especially when you cannot observe Jim in his cabin.
In this article, I am sharing my experiences with applying Key-stroke level model to a real use case analysis of a future product increment. The precondition was existing click-through prototype of the feature.
The Feature
This new feature should reduce repetitive task that users need to perform over and over. KLM comes handy in comparing Before|After interaction flows used to achieve the same goal.
KLM Operators
As a first step, I defined my KLM operators table. I used various sources listed at the end of the article and compiled the list containing operators that I needed.
Analysis
The interaction design is straight-forward, so the analysis was not complicated at all. I used click-through prototype to mock the feature and record the interaction.
Guesstimate
Since most of the key-stroke operators are defined by uncertainty ranges, I experimented with Ozzie Gooen's Guesstimate to model the same task analysis.
Conclusions
After I measured time-on-task difference in [%], I continued with basic ROI calculation. I estimated assumed frequency of the task and an hourly wage of the user and calculated expected cost-savings in [$].
The most important conceptual aspect of KLM that I needed to explain to stakeholders is its "precision". Your stakeholders might question, why you have scored certain task 4.51 sec and not 6,98 sec. For these conversations, you can find resources below that compares real user testing with KLM heuristics proving that KLM is a very accurate heuristic method.
My pain argument is the relative task difference. It is not really that important if Task A took 4.51 sec or 6.98 sec. The important aspect is, that the relative difference to Task B is pretty accurate since I used exact same method and operators to measure A and B. Again, there are data listed in resources proving this with real user research.
Even that initially I struggled to find simple how-to guide KLM "Cookbook for dummies", the overall concept ends to be dead simple and I am already working on much more complex KLM analysis.
I highly recommend this Heuristic method and include measurable metrics into your design process before investing your time and resources into the actual usability testing.
Resources
Olivier Georgeon & Frank Ritter | Key-Stroke Level Model
Lorin Hochstein | GOMS
Jeff Sauro | Estimating Productivity
Jeff Sauro | Measuring task times without users
David Kieras | Estimate Execution Times
Jakob Nielsen | Mental Models
Various contributors | KLM Form Analyzer
