Unfortunately, most of us know about projects that had low user adoption because users found them:
- Too slow.
- Too hard to learn how to use.
- Too inefficient to use.
How does this happen? Performance and usability requirements are missing or unfulfilled. Frequency of Use is part of the use case meta-data. A use case’s frequency of use combined with number of users helps us determine the importance and benefit of writing performance, ease of learning, and ease of use requirements for it. (I’m assuming you have limited time and must prioritize which requirements you write).
Consider the following graph:
When you have a use case that falls in the upper right quadrant of the graph (B), high number of users-high frequency of use, the reward for optimizing usability and performance is high; it is compelling to write usability and performance requirements. For example, consider a use case that 10,000 people use 50 times a day. A 1 second difference in the performance has a potential impact of 17 hours per day. Further, if it is not obvious how to use the system, this will lead to training and/or frustration for 10,000 people.
