Modules and Wholes

Outside of projects involving consumer gadgets or consumer websites, usability professionals often feel they work on the margins of software projects. True, there is growing recognition that usability is important in principle, but in practice, many project plans simply don't reflect a realistic role for UCD, in terms of budget (do many of us get 10% of the project?), timelines, or process. Unfortunately, other than to groan, most fixes focus on highly variable soft solutions such as improving communication between team members, and sharing one's perspective. Such approaches are laudable, but inadequate. Except for the the smallest projects, improved communication will not accomplish much when the structure of the project has been cast by the project plan and room for addressing changes in scope has been eliminated.

I believe a major reason UCD is on the outside looking in is because of simple phrase most of us hardly even notice. The phase is "functional requirement." Nearly all our colleagues --business analysts, programmers, project managers, and business stakeholders -- are under the impression that usability is a nonfunctional requirement. They are both right and wrong. And while usability professionals did not create this confusion -- we don't even use the terms functional and nonfunctional -- we are least partly responsible for confusing others about what is essential in what we do.

Functional requirements are important for people involved with developing systems in many ways. In larger projects, functional requirements are articulated in a written specification. Once a specification is written, the scope to make changes has been reduced considerably. But what constitutes a functional requirement -- something so essential is must be done or else -- is open to considerable debate.

I am not a professional programmer, so I can only offer a flavor of how programmers view functional requirements. Here are some distinctions others make between functional and non-functional requirements:

• Functional: quantatative tasks a system performs. Non-functional: how system fits into its context.
• Functional: actions system must perform, input-out behavior. Non-functional: system properties and constraints.
• Functional: system behavior expressed in Noun-Verb form. Non-functional: Adverbial qualifier what what system does.
• Functional: what system must perform, what a system does. Non-functional: how a system does it.

Although the above distinctions differ, one element is clear: functional stuff looks important, while non-functional stuff looks a bit less so.

So what do our colleagues think about where usability fits? Generally, people concerned with functional requirements don't even address usability: it is not part of the functional requirements process. The closest explicit statement to that effect I can find comes from Leffingwell and Widrig in Managing Software Requirements (edited by the famous Booch/Jacobson/Rumbaugh) who give 2 pages to usability as non-functional requirement. They complain about usability being a "fuzzy" notion that hard to judge a system by. Given existing usability specifications, how do we know the system is performing the functions it needs to do? In some respects, I think that is a fair criticism. Too many usability requirements are fuzzy, and hard for others to respond to predictably.

Software requirements don't often specify UI behavior, which creates a host of problems. Agile methods, about which I wrote recently, offer a work-around by trying to remove documentation of requirements so that decisions about the UI aren't choked off by pre-existing functional requirements. Lucy Lockwood, codeveloper of usage centered design, argues that UI design is intrinistically associated with system behavior. "The best user interface design will offer little to users if crucial details are lost in implementation." She comes close to viewing usability as a functional requirement. While I agree that UI is deeply affected by what the system can offer the user, I balk at her belief that programmers need to drive the UI. She says: "most detail decisions affecting product usability are made by the people writing the code." Moreover, "good interface design is closely tied to the programming that supports it. Usability is a function of both appearance and behavior, and behavior implies programming." She believes a week's training in UI for programmers is sufficient for most the develop usable, if not excellent, designs. I can't speak for her experiences offering such training, but my experience has been that most programmers are not that interested in UI design and would prefer for someone else to make these decisions. Lockwood cites a shortage of usability professionals as limiting their involvement in UI design, but I think a bigger problem is the lack of explicit requirements processes for UIs, especially how these requirements are formalized, reviewed and communicated to coders.

Part of the confusion about the role of usability in the requirements process stems from its elastic meaning. Sometimes people refer to usability as user needs, sometimes as UI design. User needs in turn can be needs that relate to specific functions of a system (such as specific scenarios of use that are discovered from contextual inquiry), and needs that apply to the system as a whole (will users rely on mice or keyboards, will users need to conduct wildcard searches or sort results)? These user requirements can feed into both the functional requirements (via the business requirements) and the UI design. When usability is viewed solely as a non-functional requirement (screen layout issues that are independent of the system behavior), then major problems can arise in assuring that the system does what it must do to satisfy user goals.

Getting usability considered as a functional requirement is an essential step to getting it built into the project plan, getting time and resources for front-end activities essential to the success of project from the user's perspective. Sometimes even seeming trivial requests, such as wanting a summary screen drawing together different pieces of information, will precipitate a functional change request, and be viewed with reluctance. In these cases, usability is viewed as a project spoiler, and is further marginalized.

Unfortunately, the more UCD professionals talk about "user experience", the more others view usability as mostly a matter of presentation, and as a non-functional requirement. This aspect of usability does exist, and is both important and non-trivial, even if non-functional. There is much that usability can do to improve things for users without tinkering with the underlying behavior of the system. But such surface usability has limits. We need to get wiser about communicating the specific impacts of UCD, how they impact other non-UCD activities, and how project plans need to be constructed to assure that UCD addresses important functional aspects of the system.