Programmers are from Saturnus, Customers are from Jupiter

When talking to customers I often notice that Programmers and Customers think they understand each other, but actually they are not on the same page. This is because the customer sees a problem and wants a solution. The programmer sees a technical challenge and wants to solve it the best he can. Good programmers are obsessed with doing things right. But when you start, it is even more important to do the right thing.

Socrates said, 'Know thyself.' I say, 'Know thy users.' — Joshua Brewer, Twitter

What the customer says:

"I just want it to work".

How the programmer translates it:

"Deliver something without a single bug. Oh and perfect user experience for any audience, that includes my grandma and my daughter".

Don't blame the programmer. I think a good programmer will never finish anything. Because it is impossible to write something with zero bugs. And you do want a programmer that is passionate about making it as good as possible.

Things a customer can do

Use wireframe tools such as Pop App. Make drawings on a paper and take pictures of it. It makes it so much clearer for a programmer. Within an hour you can draw the 'flow' of the app. Then you can make clickable buttons so you can really click through it and put it in the hands of your users.

Things a programmer can do

Keep replying to each answer with "why do you want to..." attached in front of it. Finally, make a summary of what the customer has said.

Example of an actual conversation:

• Customer: "I want a clean, simple user interface."
• Programmer: "Why do you want to have a simple user interface?"
• Customer: "Because of my target audience."
• Programmer: "Who is your target audience?"
• Customer: "Elderly people who have bad vision."
• Programmer: "Okay so high contrast, a big non-curly font is of importance?"
• Customer: "Yes."

Behaviour Driven Development

From this step I usually deliver a Requirements document, with rough hour estimation. After approval I start developing the product. What I've learned is that we need a solid requirement document, but often it's too technical for the customer to grasp. So to solve this challenge, I've started using BDD.

Behavior-driven development (BDD) is a software development methodology in which an application is specified and designed by describing how its behavior should appear to an outside observer.

The old requirement document way:

• The app must show a popup saying "Do you want GPS to be enabled?"
• The app must get a new GPS location on startup and send this to the back-end.

The new BDD way:

As a System
I want to know the location of the user
When he uses the app
So that I can serve him jobs which are in his own surroundings

Given the app with GPS enabled
When I start the App,
Then a new GPS location is acquired and sent back to the back-end.