…f the team can notice you’re doing something different, you’re probably changing too much too fast. Design leadership is a game of patience. To avoid triggering resistance to change, any change has to happen undetected under the radar.
Giving people what they ask for doesn’t result in success. Your customers aren’t the same as your users. Neither your customers nor your users know what they want or even what they do. What people tell you has little bearing on the truth. Good user experience isn’t dependent on features. Radically different products can have identical features. A list of features is not the same as the design of behavior. Expertise in a subject doesn’t correlate to expertise in designing software behavior. Requirements cannot be “gathered” like colored eggs on Easter morning.
…use people are stupid or obstinate. It is just that they — we — are victims of cognitive illusions. There is a large and growing body of scientific evidence corroborating what programmers know empirically: humans don’t know what they want, what they need, or even what they do. And they are utterly blind to the real reasons why they do what they do.
…mers. Wedged in among all of that wisdom, however, is one big, commonly-held, erroneous assumption. Programmers, and most other people too, assume that asking people what they want results in useful answers. But human beings are not capable of giving answers that can be used without significant transformative effort. Let me show you why this is true.
Agile is a powerful tool for coping with incompetent designers. The new discipline of interface design has attracted a lot of wanna-bes and posers, who imagine that their color sense or esthetic vision qualifies them to design complex software behavior. They believe that putting a pretty “skin” on software makes it easy to use, or that being nice to users makes them more productive. They guess at solutions, without caring that each of their guesses causes lots of wasted work for the programmer. Agile forces them to bring a little discipline and responsibility to their work, just like programmers have to. Actually there aren’t that many incompetent, foolish managers out there who believe that it is th…
…cess. There are significant, meaningful differences in the various stages of software construction. What’s more, the non-programming stages of software creation can be as large, complex, and as time consuming as the programming stages; and certainly, they are just as important.