A user calls a programmer and says, “We need a button on screen ______ to do _____.” What is the right answer?
a) Sure we can do that for you.
b) Wow that screen already has way too much stuff on it. Adding another button will make it way too busy.
c) That screen wasn’t designed for that. But you can do it by. . .
d) Hmmm. Help me understand the context a bit better and where this fits in. Sorry, I just do a better job coding if I understand the big picture. . .
Answer A sounds helpful, but it will result in patch after patch being applied haphazardly. Eventually this will break down the technical unity/cohesiveness of the system. In the end the system will be what the users requested, but probably not what they wanted. Answers B and C put the user on the defensive. Even if the argument is “successful” it may leave lingering resentment.
The right answer is D. It opens that critical two-way communication channel between programmer and user. Over the years I’ve noticed that the most effective programmers understand the frustrations of the user’s world and write their programs to solve those problems (not add to them). The flip-side is true for users. The most effective users understand the applications/technology they use.
Neither programmers nor users automatically know such things—they must teach each other. One of the best times to exchange that knowledge is when a request is being made. Always start by asking the user about their world—people like to talk about what they do. And what they do is the basis for your application—and for their change request.
Once they’ve described their processes, start drawing connections between those processes and the application. You’ll probably realize with a shock that the application doesn’t even come close to matching the user’s world. That mismatch is the “root cause” of the request.
Next, discuss various options to resolve the “root cause”. Usually the best option is not adding a button, but something else that is both technically sound and often far better at fixing the user’s problems. You can’t fault the user—a button was probably the only technical term they knew.*
In the last few years after learning this technique I’ve had these conversations many times. It takes a few minutes, but in the end it saves a ton of time/trouble.
Jeff’s Book Recommendations:
Innovation and Entrepreneurship is a great book for those of you considering a startup. Drucker lays out a very logical and useful framework for innovation that is well worth checking your business plan against. It is equally applicable for those in established companies looking to branch into new products.
Jeff\'s Post 
June 8, 2008 at 4:08 pm |
I don’t know, Joel, I prefer an appointed business person to handle requests such as these rather than users going directly to my programmers. And if my programmers are working on things I’m not managing, then there’s a problem with my abilities to manage deliveries.
June 8, 2008 at 7:10 pm |
HeresyBob, you raise a valid point. Thanks. (BTW, my name is Jeff, but I don’t mind being confused for Joel (Spolsky). I’m a big fan of his.)
In a corporate environment it is MUCH better if a group of users can select a “proxy” to represent them to the programmers. Someone who thinks like the users (very important), but has the authority to approve changes (even more important). Ideally this would be a low level manager (direct reports actually use the software) or a paid application administrator (typically for the enterprise level application where low-level management isn’t high-enough to make overall decisions, but high-level management isn’t close enough to the work to make effective decisions). The presence/lack of someone in this role easily makes/breaks a software project.
June 9, 2008 at 10:30 am |
Heh – whups, sorry ’bout that 🙂
November 13, 2008 at 1:01 pm |
Очень полезная вещь, спасибо!! (Very useful thing, thanks!!)