Frequency of Use, It’s Not Just a Use Case Template Item

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.

When you’re in the lower left quadrant (C), low number of users-low frequency of use, the risk you incur by allowing developers to deliver suboptimal solutions is low. A feature used once a month by 5 people which performs 5 minutes slower than perhaps you had hoped has a potential cost of only 25 minutes per month.

As far as the other two quadrants, they are also strong contenders for usability and performance requirements. However, what you need from the development staff may differ by quadrant.

In the low number of users-high frequency of use quadrant (D), optimizing performance and ease of use may be compelling, but ease of learning how to use the feature may not have much benefit (e.g., training costs for a low number of users are low).

On the other hand, if you have a high number of users who perform a task infrequently (A), making it very easy to (re)learn may have a high reward, whereas sub-optimal performance and/or ease of use have a low user impact; users just don’t use it often enough to care if it is a little bit slow or takes a few extra clicks.

As you can see, the data helps you make the right decisions; frequency of use is not just a use case template item.