Fire-breathing requirements
The mythical design tool.
The concept of “requirements” in interaction design is a mythical dragon that refuses to die. Designers seem to constantly bow to requirements and to imagine that they are cold, hard facts whose demands are non-negotiable. I’d rather follow my own understanding of the word: Things that are “required” are required, that is, without them, nothing works, everything fails, the streams get crossed, and the universe as we know it ceases to exist.
What some executive, Subject Matter Expert, designer, or Other Opinionated Person demands of the product is virtually never “required” required. In the real world, ignoring such alien orders is a vital skill every designer needs for success.
You can see this clearly in the evolution of successful software products. A company delivers a solution to a “requirement” and does well in the market. Along comes a feisty startup who scraps the “requirement” and overwhelms the former leader.
I’m very sympathetic to the opinions of those executives, SMEs, designers, and OOPs, after all, they are not all idiots. But there’s a world of difference between an educated, intelligent opinion and a genuine, required requirement.
The idea of “requirements” in the world of software has some validity because there is a small engineering component in most products. They have to run on computers. An example of something that is actually required would be that a program runs on a target platform, or that a server can handle the expected client load. And even those are asterisked: who chose that platform? And who estimated the client load?
The idea of requirements is borrowed from physical-world engineering practice, which is governed by the laws of physics. It is, in fact, required that one obey the laws of physics. They are actual requirements. Gravity, I guarantee, will always win.
But everything else is just someone’s opinion. It might be a good opinion. It might be a powerful opinion. It might have some corroborating dates or facts or resolutions or agreements, but it is still just something someone said.
In many disciplines, but certainly in the world of interaction design, the biggest problems are not caused by what we don’t know, but are caused by what we think we know but that is wrong. Persuading practitioners to not recognize their mistaken beliefs is a powerful technique for management and control.
Thus, “requirements” is a powerful methodology for getting people to not question the veracity of what we think we know. It’s a way to demarcate someone’s opinion as DO NOT TOUCH and STAY AWAY and DANGER NO USER SERVICEABLE PARTS HERE. But really, it’s bullshit.
Design needs to be driven by an understanding of who the users are, what end-state they are trying to achieve, and why that is so. Those apparently simple things are actually really freaking difficult things to learn. That’s what research is for, and why many organizations won’t let their designers do any of it.
One thing about the user’s motivations and goals that is a nearly universal truth is that they change only very slowly, and most times not at all. But, if you don’t put in the hard work to determine what your user’s goals and motivations are, then they will always appear to shift and change. It’s one of the most powerful and common illusions of our craft.
So, for example, you see a user put gas in their car and you pronounce “gassing car” is a requirement. Then they buy a Tesla, and they don’t put gas in their car and you say, “Requirements have changed.” And you are very wrong, because fueling a vehicle is a task, not a goal.
Users are not motivated by having a full charge or a full tank. They are motivated by driving somewhere. Actually, they are motivated by being somewhere. Now your thinking is freed up to be creative. Every single piece of enterprise software I’ve ever seen has nailed its “requirements,” while its actual users sit weeping in the stairwell because it has so crushed their soul. Fuck requirements.
The most frequent invocation of the idea of “requirements” is from designers who are terrified to cross them. These designers have been beaten into submission by people who are blind to the path forward. And those blind and frightened people know that they will be judged by other blind and frightened people, so they know that they can easily hide their fear by pointing to the dragon. They don’t really care about winning. They care only about not being blamed for failure.
