Fequency of Use vs Ease of Use

It's easy to be easy when your software only does one thing. It's easy to be easy when your software only serves one user, or a homogeneous collection of users with the same backgrounds who attrbitute the same meanings to things. These situations are not typical.

Instead, we face a long list of things our software must do, a long list of ways the software must do it, and a heterogeneous collections of users who different things, play different roles, and don't share background or meanings. This makes achieving ease of use across all features or tasks impossible. We face the tradeoff between the number of features and ease of use.

One way to make an informed tradeoff is to look at the fequency of use of the features or tasks. To do this we record use over a long period of time. It will turn out that certain features are used all the time like opening a file and saving a file, and that other features are rarely used. If we recorded the use of a single user, we end up with that user's statistical distribution of use. If we do that for many of our users, we ed up with a statistical distribution of their aggregated use.

If we order the frequency of use by frequency, we end up with something approximating a power curve or "The Long Tail," as shown by the black line in the figure below. Then, we can design an ease of use curve, as shown by the red line.

If the most frequently performed tasks are the easiest, the average ease of use will be low. If the least frequently performed tasks are hardest, again, the average ease of use will be low. In some sense the intimidation of the harder tasks will provide the administrators with a benefit. The causal user won't go in and mess around with things.

An alternative would be to partition the functionality around roles, uses, and meanings. Consider MS Word back when it competed, in the legal industry, with WordPerfect, the market leader. MS Word provided a function key mapping feature that enabled word to match WordPerfect keystroke for keystroke. Legal secretaries were touch typists that worked at 200 words per minute or better. They would never touch a mouse. That was too slow. If you were not a legal secretary, you wouldn't use this feature of MS Word, because you couldn't remember the function keys. The feature required you to dig around to turn it on. After that, you just did what you always did the same way you always did it. MS Word eventually took over the WordPerfect space in the legal industry.

MS Word provides many other examples. How may of us use mail merge? Or, fields? Or, bookmarks? Most of us just type in the words, do some formatting, do a spell check, and save the file. There is so much to MS Word that we never use.

MS Word also demonstrates how an application can be partitioned into two applications. It used to be that MS Word could do anything that you could do with a desktop publishing application. You could set up a grid. You could simulate embossing. Microsoft did not have a desktop publishing application. The eventually decided to enter that market with MS Publisher. At that point MS Word became a blunt instrument. MS Word's font metrics couldn't enforce a grid any longer. So MS Word is less capable today. If you want to do desktop published quality work, you move over to a desktop publisher, and only type up the words in MS Word. Sad.

MS Word also demonstrates the task sublimation that Moore talked about as a necessary step when entering the late market. MS Word, today, is a non-geek, tool. With task sublimation, you don't give up power. You only give up feature bloat, or control. That's the idea. MS Word doesn't live up to this ideal when you compare the current versions with MS Word for DOS 5.0, yeah, a dinasour.

The point of all of this is that you can design an allocation of ease of use that simultaneously fits different populations of users, fits different ease of use segmentation schemes, or gives the broadest collection of features or tasks, the perception of ease of use.