Parmenides notwithstanding, I follow my own understanding of the world: Things that are “required” are required, that is, without them, everything fails.
Attn: @Flemn8r 1
Attn: @Flemn8r 1
@Flemn8r What some executive, SME, designer, or Other Opinionated Person demands is virtually never required. In the real world, ignoring alien orders is a vital tactic for success. 2
@Flemn8r You can see this clearly in the evolution of successful software products. A company delivers a solution to a “requirement” and leads the market. Along comes a feisty startup who scraps the “requirement” and overwhelms the former leader. 3
@Flemn8r 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 FUCKING REQUIREMENT. 4
@Flemn8r 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? 5
@Flemn8r 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. 6
@Flemn8r 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. 7
@Flemn8r But EVERYTHING else is just someone’s opinion. It might be good opinion. It might be a powerful opinion. It might have some buttressing dates or facts or resolutions or agreements, but it is still just something someone said. 8
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. 9
“Requirements” is a powerful methodology for NOT questioning or establishing the veracity of what 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. It’s bullshit. 10
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 are really freaking difficult things to learn. 11
But 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. 12
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 base illusions of our craft. 13
So, FE, 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. Fueling a vehicle is a task, not a goal. 14
They 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. Fuck requirements. 15
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. 16
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. 17
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. They don’t really care about winning. They care only about not being blamed for failure. 18
