Moving on from Requirements

The phrase business requirements is used to describe a set of features or capabilities that have been determined to be important to substantiate a particular strategy. These elements are "required" to remain competitive, or to spur innovation, or to increase market share or any other key business driver. They are identified by a business analyst or those with the unfortunate acronym SME (subject matter expert); the requirements are usually presented in a product brief or requirements document.

A requirement typically takes the form of a user or system directive, for example:

• The user must have the ability to display the cost of their purchase before checking out.
• The user must have the ability to complete a transaction with a credit card.
• The system must support the ability to use single-sign-on.
• The system must save transactions for at least three years.

The requirement model is taught in most UX programs, and it positions this practitioner at the hub of three ideas that must be balanced: user needs, technical constraints, and business goals. Students learn that their role is to scurry around the organization talking to all of the constituents and these experts in subject matter, and to flesh out more detail around the requirements. They learn that it's important to socialize the refined set of requirements, and to identify the technological constraints, and then to create a design that's appropriate and feasible.

There are a number of problems with this model.

• This way of working defers strategic thinking and responsibility to the "business owners," rejecting the idea that anyone "downstream" (both engineers and designers) is able to drive innovation. Innovative thinking comes from within all aspects of an organization. Often, it is those closest to the product—those actually moving the pixels or writing the code—who have the best ideas about what the product should actually do and what role it should fill in the market. The requirement process treats the what as the focus of only a select few, and the how as the territory of those building the product—it says, "It is required that you build this product and that it allows someone to do these things. Don't question the features or capabilities; just get those features in there in the best way possible."
• This way of working assumes it's necessary to compromise before anything has even happened. By positioning design as the great mediator, it assumes that mediation is necessary—that the business, technology, and user wants and needs won't be aligned. But each time compromise is necessary, the integrity of the product and the overall strategy is diminished, and often, it's the "user" part of the model that gets compromised the most. Great products don't require compromise. They require vision, perseverance, and the ability to do amazing things in the face of perceived impossibility. This isn't hyperbole—it's the way great product visionaries have described their success. Walt Disney's mantra was "It's kind of fun to do the impossible."
• Most important, the model removes any sense of mystery or surprise from the design process and concept. The design process is about dreaming and visualizing an optimistic future of the world. This dreaming doesn't happen in the context of requirements; in many respects, it doesn't happen in any of the artificial containers we put around the workplace. The process itself identifies constraints, which are implicit to the explorations. The beauty and wonder that's infused in great products come from passion and from looking at the world differently. The requirement model eliminates this stage of thinking from the process entirely; it renders the process sterile precisely where we need the process to be invigorated.

Most UX programs are teaching this triad of technology, business, and people, and more so, they are teaching that the model is the norm. And they are right: It is how most companies produce products. The students that graduate from these programs are easily employed. They fit right into the existing enterprise, and then they serve to reify the model itself.

I talk to many designers who graduate from design programs focused on iteration, empathy, and dreaming, and to many who graduate from UX programs focused on requirements, business, and technology. More often than not, the designers are confused by the requirement process. The UX students love it. The designers expect to draw and imagine, and are surprised that those skills aren't valued. Those from UX expect to manage requirements, and are happy to see they are well prepared.

We can teach our students other models. We can teach them that design can lead, producing innovation that is uncompromising and directly supports a business strategy. We can teach them that good products aren't developed through over-analysis, and that there's room for ambiguity and emotion in the entire process of product design. And we can teach them to question everything, particularly when someone tells them that something is required without explaining why.

If we teach our students these other models, they will be confused or disappointed when they enter the "real world." Confusion or disappointment doesn't feel good. But it does often lead to change. These students might vocalize their concern and describe another way of working. They might work to change the organization. They might leave and look for another place to work where design can be strategic. They might even start their own company to drive a process that brings delight and magic to the process of bringing new products to life.

We need our students to realize that product development is more textured than a list of requirements and a simple three-prong diagram. It's a disservice to our future colleagues to prepare them for safe careers in an established system. We need to prepare them to dream big and question everything.