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.

Share this: Twitter

Facebook

Like this: Like Loading... Related