Learning curves have been studied for decades when evaluating manufacturing systems and proposing cost reductions. The Boston Consulting Group did an oft-cited analysis in the 1960’s that describes how people get faster at tasks through repetition. Peter Abilla looked at the application of learning curves to writing software. We look at how they apply to using software.
Learning Curves
Wikipedia tells us that the learning curve phenomenon was discovered in the 1800’s by a psychologist, but industrial applications of the concept reference the Boston Consulting Group study on experience curves.
Learning curves describe how people become more efficient through repetition of a task. The experience curve concept extends this idea to organizations, suggesting that overall costs for an operation will drop over time in the same way. People argue about the validity of this – suggesting that economies of scale take over with high volume activities. Regardless, the element of learning still applies.
Learning Curve Explanation
The easiest way to explain the concept is with an example. Consider a task that takes five minutes (300 seconds). Over time, a person will get faster at performing that task. The graph shows the amount of time required to complete the task decreasing with repetition of the task.
To make it more concrete, consider the task to be “Enter an issue into the bug-tracking system.”
There are three curves in the graph above, labeled 90%, 85%, and 80%. Each curve shows a progressively faster rate of learning. Note that the scale of repetitions is logarithmic. The first time the user enters an issue in the bug tracking system, it takes five minutes. By the thousandth time, the user will spend under two minutes on the “90% curve.”
The percentage-labels of the curve represent the quickness of learning. Each time the number of repetitions doubles, the amount of time a person spends on the task is reduced by the listed percentage.
On the 80% curve, the user will spend 300 seconds on the first issue, 240 seconds on the second issue, 192 seconds on the fourth issue, etc.
Usability Is Important
Usability is an important factor in software development. It may be a challenge to define the usability requirements, but usability affects user satisfaction, and usability sells software.
When investing in usability, you have to take into account how valuable each investment is. Any product will have a number of business use cases, and each use case will have a frequency with which it happens. Usability investments affect two factors of that use case:
- The initial amount of time it takes.
- The speed with which someone improves at the task.
ROI of Usability
Once your company reaches stage 5 in corporate usability awareness, you will be prioritizing usability initiatives, and prioritization should be driven by return on investment. That analysis is typically done based on the initial amount of time that a task takes.
Incorporating the element of learning into that analysis will yield a better (and higher) indication of the value of usability investments.
If you’re math-oriented, you’ll notice that the learning curve never really ends (theoretically). You have to “stop” the learning at some point when performing a financial analysis, based on the net present value of future savings. Three years is a realistic time horizon for software (and might even be a little long).
However, you won’t continue to see benefits for three years.
Competent Users
There’s a phenomenon with software – people stop learning when they become competent. Most people get “good enough” to satisfy their own needs, and don’t move on. They don’t become experts, so don’t design for experts, and don’t propose an ROI that assumes that everyone will be an expert.
Grasping Time Horizons
The theoretical learning curve is handy, but you have to do a little more work to make it useful. Consider first the frequency of repetition of the task. Is it a weekly, daily, or more frequent activity? This frequency will determine how quickly (on the calendar) someone will achieve the high levels of repetition that result in improved efficiency.
The following graph shows how an 80% learning curve overlays a calendar for tasks that happen daily, weekly, and hourly.
The graph shows that for a weekly frequency, after 16 weeks, the task time has reduced from 300 seconds to 100 seconds. With a daily frequency, the task time is even lower – about 60 seconds. This graph shows nothing other than converting the academic learning curve graph into one that incorporates calendar time and frequency of occurance.
Note the odd, vertical drops in task time during week 1. This is just a manifestation of looking at a weekly time scale. For a task that happens once per hour, the user will rack up 40 repetitions during the first week. From a decision-making standpoint, you don’t have time to react to that rapid rate of learning, so it is ok that it is collapsed on this graph.
Further Limiting The Time Horizon For ROI
There are three vertical, dashed red lines on the graph. The original learning curve theory stays pretty, well, theoretical – using log graphs for a time horizon. This is fine for academics that want to understand the underlying trends and drivers. An ROI analysis brings in a set of relevance constraints driven primarily by the time-value of money.
However, software’s time cycle should limit the time horizon even further in order to be practical.
- First Impression. Software is often evaluated for usability or suitability based on first impressions. The reduced barrier to entry for many software products makes it extremely easy for a user to say “I’ll download something else – this isn’t good enough” after a couple minutes with the software.
- End of Training. Other software sales cycles involve training as part of the evaluation period. This is more common with enterprise software, and may be the way your target users (or decision makers) approach the evaluation. Everyone is different. When this is the case, the user’s ability to be effective with the software will be evaluated after some nominal period – perhaps two weeks.
- End of Attention Span. The competent user phenomenon limits the attention span of most users – they simply stop learning. A realistic way to represent this may be to draw an (admittedly arbitrary) line in the sand at the three-month mark. At this point, users either like the software or they don’t. They’re as good as they’re going to get.
Conclusion
You will have to determine which time horizon is most relevant for your product, customer, and users. That decision will determine the relevance and impact that learning should play in prioritizing usability investments for your product. If your product will thrive or die on first impressions, then the learning curve should be all-but-irrelevant to your decisions. Only the word-of-mouth-marketing factor will come into play. You need to stress investments that lower the initial task times over those that accelerate learning.
One thought on “Software Usability and Learning Curves”