Communication Gap: User vs Analyst-Designer

Question

Normal practice is to use case studies, construct work- and data-flows, etc. But this does not necessarily create a shared vocabulary between the user/sponsor and the analyst-designer: one or the other, both normally, will have to acquire terms and views of the "internals" of the others area of expertise, and this usually leads to misunderstandings and meetings-to-clarify (enter RAD-techniques like Evolutionary Prototyping), etc.

The user/sponsor is focused on his/her needs/environment, and does not want to, nor should be forced to acquire, from their perspective, unrelated 'programming terminology'. The responsibility to learn a new environment lies with the analyst/designer(/programmer).

How do you overcome the learning curve? What works for you when you are faced with a user who wants a software solution?

Answer 1

A good interaction designer should be able to describe the software workings in layman terms. If not, he should not do frontends, IMHO.

Answer 2

Try to eliminate as many intermediate steps between the user and final implementer as possible. Every such step obscures and loses information. The most valuable members of your team may be people who can wear both suits - "interface" with users, and actually implement the thing.

If not, make sure you have rapid iterations and implement things iteratively. It's easy to confuse it with incrementally. The difference is, that with iterative approach you have broad range of functionality implemented to a small, but uniform degree. In incremental approach you implement big chunks of functionality one after another.

In the iterative approach you have the advantage of agility. User changed mind, or there was some misunderstanding? No problem, there is still room to change. Not much effort has been spent, even, hopefully.

Answer 3

It takes a range of techniques, and a both sides need to learn to understand the other's business to some extent: i.e. the analysts has to gain understanding of the user's domain and the user has to become familiar with some of the techniques of analysts.

I find Process Flows a good way to start, to agree at a high level how the business operates. Some users are good with data models (ERDs for example), but generally I would say they are not: they often respond better when the rules are spelled out in text e.g.

• An Order can consist of one or more Order Lines
• Each Order has a unique, 10-digit reference number

They can read through and tick or cross those much more easily than they can quality-check an ERD.

Next, nothing really beats sketches of input screens and reports for getting users to focus on the details of what they want.

Answer 4

I use the comments

"If you cannot explain your physics to a barmaid, it is not very good physics" and "You do not really understand something unless you can explain it to your grandmother" (Attributed to Rutherford and Einstein)

as mantras when I am talking requirements with customers.

Take the two pronged approach, a high level, Powerpoint or whiteboard presentation, and if you can let the users loose on a POC or a mockup.

Then do detailed line by line requirements. The devil is in the details. Get them to sign off these details. Label and number them so they can do a line by line analysis.

If you do the detailed requirements prior to the high level set, the users will never grasp any concepts in the design and get bogged down in the tiniest detail specifications. Without any frame work, or concepts, the users will spin around the number of angels on the head of a pin.

Agility and iterations are good, as long as customer and development team can talk a similar language. Ensure expectations are set and met.