Traditional usability firms (or usability groups within large companies) tend to focus on evaluation, and their design process typically ends at the Discover phase with workflows and application screens created by researchers. For companies that tout themselves as “Human Factors” or “Usability,” the goal is to have research and data dictate design. After all, isn’t a research-based interface what we’re after? In this environment, the role of design is often an afterthought and always under-used. While traditional usability firms (and the software development industry in general) have recognized the need for designers, it has typically been either to create nice looking marketing materials or to make the designs created by researchers “look pretty.”
The reader can be forgiven if he or she has imagined me to be a (disgruntled) designer looking for a little respect. Not so. As a researcher with a classical background in experimental psychology (Ph.D. in Cognitive Psychology, 1991, The State University of New York at Buffalo) I have seen the field of ergonomics/human factors engineering/usability/design research/user experience architect develop and mature. However, in the 21 years I’ve being doing usability research, I’ve seen (and been party to) a great many applications that, while usable, were not innovative, inspiring, beautiful, or lasting regardless of the interaction models made possible by the technology du jour. Why? Because we were following a research process (or, dare I say, a technology-driven process) rather than a design process.
Who is Designing?
Traditionally, the field of software development has looked to the contributions of two types of individuals to ensure that applications meet the needs of users. These individuals are the Business Analyst and the Subject Matter Expert. Many industries continue to rely on these job roles to gather, develop and coordinate application requirements. Indeed, the claims made by industry that their applications are guaranteed to be usable because they have business analysts (collecting business/functional requirements) and experts (representing users) on their staff are both commonplace and misleading.
Unfortunately, the fact is that no matter how well intentioned, these individuals are neither trained nor qualified to design a system that is usable, innovative and supportive. In order to understand what is missing from this process, you need only look at what these two job roles are expected to bring to the development process.
Business Analysts
The role of the Business Analyst (BA) is to gather functional requirements from the point of the view of the business. In order to provide structure and guidance for the development team, these requirements are incorporated into “use cases.” A use case is a detailed description of what the application needs to present to the user and what data the user needs to provide in order to accomplish a task. For example, one might define the process of collecting patient information in terms of the fields on a screen that must be completed. These use cases typically represent a view from the system’s point of view—what does the system need to do for a task to be accomplished. This view of design ignores the needs of the user and the demands of the situation. It isn’t difficult to see how a task might require differing designs to support the different contexts of a clinician’s office, a trading floor, or a boardroom.
This is not to minimize the role of Business Analysts—it is extremely important to understand the needs of the business. However, accurate documentation of business requirements counts for little if users thumb their noses at the resulting application. Millions of dollars, years of development and crowds of dissatisfied users at companies all over the world are an unfortunate testament to this method of traditional software “design.”
Subject Matter Experts
As a way of addressing the problem of users and their stubborn refusal to use systems that do not support them, industry has inserted the role of Subject Matter Expert (SME) into the mix.
In the medical industry, for example, this means making sure that software development firms employ clinicians (MD, RN, etc.) whose role is to describe what the application needs to do, what data is required and how it should be presented. While this might certainly be a step in the right direction, these individuals are fundamentally like any other user group—they are not skilled design professionals and their appointment to this role in the design process is flawed.
It is flawed because the job of the SME is specifically to act in place of users. Experts are, at best, providing what they believe to be user requirements or, at worst, their own requirements. The point is that they are not providing user requirements. In addition, Subject Matter Experts are also asked to make decisions regarding design. We should be clear on this point; experts are not qualified to design any more than designers are qualified to be subject matter experts. My apologies to the experts put in this role. With this in mind, users (and purchasers of new applications) should be wary of the marketing phrase, “Designed by Expert X for Experts Y.” Perhaps, as an industry, we should start insisting on “Designed by Designers for Experts!”
What All This Means
Good design doesn’t just happen. It is not a checklist of requirements, though it must certainly support the tasks that users need to accomplish. It is not a passing grade on a usability test; all the functionality in the world is meaningless if users can’t or won’t use the application. It is not a slick, natural-feeling interaction model. Most of all, good design is not “making it look pretty,” though a well-designed application should certainly be expected to look the part. And neither business analysts nor Subject Matter Experts can guarantee good design.
So what is good design? Design is a research-based, highly iterative process with a focus on exploring different models of the user-system interaction. It consists of gathering requirements from end users and business and technology stakeholders coupled with fast, early and iterative usability testing to determine the ultimate form of the design. Perhaps this design incorporates highly interactive models of the sort made possible by today’s rich application frameworks. Perhaps not. Whatever the form, it must support a user’s requirement to get something done. This ensures that the system is shaped not only by the opinions of design professionals, but also on the needs, expectations and requirements of users.
