In my last article, I talked about how important it is to ask “why” so many times that you get to the bottom of what it is that people actually require without specifying an implementation alternative. Starting from “the possibility to import an XML configuration in the system,” we ended up with “making changes in the configuration and changing the status of the modules has to be easy.” Two issues need to be clarified in the requirement: do we have one requirement or two, and, most important, what is meant by easy?
One can easily argue that there are actually two requirements: making changes in the configuration has to be easy and changing the status of the modules has to be easy. The current requirement clearly reflects the current practice of using the configuration to build the TOC of the document set as well as to monitor the approval status of the modules. Naturally, since these actions may not exist in the new system, it would be wise to separate the requirements. It may also be that “easy” may be defined differently for the configuration change than for the module state change. These changes may be made at different stages in the process, which also speaks to separating the requirements.
The second question, what is meant by “easy,” is more difficult to handle. There are no absolute answers. The requirement needs to be clarified by the people who will actually implement the tool. Their opinion of what is easy will vary a lot from the actual end users’ perspective. For example, entering a bunch of commands with variables and switches in a command prompt may well be the easiest way for an experienced Unix user to change the status of the modules but would not be easy for a technical writer without DOS experience, let alone coding experience.
The problem with defining a requirement in more detail is that it easily turns into an implementation solution. If you ask, for example, “What in your opinion would be “easy” in changing the configuration,” you will probably get an answer like “drag-and-drop.” That is what people are used to. However, that limits the implementer’s ability to innovate. They might come up with an easier way to make changes than “drag-and-drop.” For example, they might use “click-and-click,” a technique in which you simply click the module to be moved and then click the place where you want to place the module without having to keep the mouse button down. Naturally, everyone has already made some assumptions about the implementation at this phase. You can probably assume that if the product is Web-based or PC-based, you would use a mouse and thus can handle clicking.
The answers to “what” and “how” questions should relate to measurable properties that you can actually test during and after the implementation. For example, “Changing the status of a module to approved should not take longer than three seconds” or “Changing a module’s place in a configuration should not take more than three clicks,” are reasonable definitions of “easy” which can be objectively measured. Remember, however, that all time-bound requirements are dependent on factors like network load and may apply only under normal conditions. I have heard responses like “We cannot promise these response times if the network is congested or down” to performance requirements from the development people. Naturally, they can’t and they should not promise; everybody understands that if there are problems in the network, the tools may have problems as well.
Setting requirements for response times and the number of clicks is relatively easy but more is needed to define “easy.” If the buttons are in strange places or the program forces the user to do steps in a strange order, the tool may fulfill all the requirements but still not be easy to use. Some requirements need a bit more definition and must be tested with the actual users to see if they have been fulfilled. Requirements should have measurements that can be verified. For example, you might write a measurement as “90% of the test users can do task x in y minutes with maximum of one reference to help or documentation.”
The only way to ensure usability is to use user-centered design methods in the design and implementation phases. That means creating user profiles, doing task analysis, prototyping, doing heuristic evaluations and usability tests, and so on. You can set requirements such as “The use of the program should follow a logical sequence of user tasks.”
The design group is responsible for designing use cases that show how they believe the users should interact with the product. They review those use cases with the actual users. I have sometimes encountered situations where the user representatives have written the use cases themselves, but I believe that also limits the innovation of the design and development team. The users begin with a reference point to their current tools and may not be able to innovate or may create scenarios that are impossible to implement. Naturally cooperation can help in these cases as well.
All in all, the requirements should not contain subjective words like “easy,” “fast,” or “with minimum effort” but should be further defined in measurable terms without implying an implementation alternative. The user interaction with the product should be defined by the design group and verified with the user community. During the entire development cycle, users should be involved in the decisions about the user interaction.
This article is the personal opinion of the author and does not necessarily reflect the opinion or practice of Nokia.