Usually a client does not know as much as a developer about software, that is why we are hired. The issue I run into is terminology. How do you communicate with a client that has limited computer experience, ex. a client that has never used a right click you can teach them the difference between a left click and a right click. But in the case of a client that has this little experience is going to have other limitations on terms/experience.

I am going to limit this to web pages since that is where the majority of my work is.

I have tried asking clients how they use web forms describing in their own terms. I attempt to use their terms, but I tend to forget their terms (except one client calling a text box a "message grabber", I couldn't stop laughing when I figured out what they were talking about).

I have no issues with teaching a client all of the terms they want to learn, and I have tried this many times, as well as how to use everything that is created. Sometimes this information just cannot be learned in the time of a short contract. I often see clients get frustrated with the amount of new information and occasionally shutdown giving up on creating a website altogether.

I have tried making sure I know their preferred method of contact so they are not going over another barrier they are not used to. This seems to help the most, but I still see issues.

What I would like see is any or all of the following ...

  1. Personal experience on how you have resolved/prevented similar issues in the past.
  2. Advice (however obvious it might be) on how to improve communication in my situation.
  3. Link(s) to articles that have personally helped you improve communication. (NOTE: I have found many articles online on how to improve communication, but I seem to be missing something critical. I want to know how the article helped you and why you are linking it. Please do not include the results of a web search.
  4. Anything else you find relevant.

3 Answers 3


You will probably hear a lot of suggestions, but they will eventually lead to the client itself. They are either willing to learn new things or not. And there is nothing you can do about it.

Now, what you can do it make an initial conversation with them asking them about their technical knowledge of the area in question. I personally do not do that as I simply forget to ask them these things. Later in the process I may discover that they do not understand some terms and then I explain it additionally.

I also have a habit of explaining specific terms in the brackets, a few first times I talk to the client. The second thing is that I tell them on the beginning to stop me any time I start sounding too technical. For example, last night I had to explain the client why I will be late 2 days on a certain task by introducing him to a term which made me work slower. Then I used good 5 sentences explaining to him what this term means, how is it used in the UI environment and why it's harder to detect bugs. Next time I mention this term, I do not have to make an essay.

So far this either works with me or clients are too embarrassed to ask for clarification :). No one likes to sound stupid, although we'd never call them that way.

This covers points 1 and 2.

I never tried point 3. Just learned from my experience.

The bottom line is your behaviour as well. Never try to boast in front of the client by trying to look like a guru or something. We are all gurus to them just because we are "programmers". So he already sees a guru in you and if you talk simple with him, he will sooner interpret it as yourself stooping to his level, then yourself being ignorant or a bad programmer. So maybe you can have an introductory talk with the client to discover his technical background (again, I do not do that, but it does not mean I am right to do so).

  • These are all very useful points and it sounds like you have a great way of interacting with clients. You are correct that sometimes terms will just need to be taught, clients will either learn it or not. You are also correct that behavior, something I learned the hard way very early in my career, makes a huge difference. Can you give an example of an experience that went poor and what you learned from it? Nov 21, 2013 at 20:07
  • 1
    I can't remember of poor experiences, but I can say that I learned that I should combine explanation (it takes time) if I do not receive feedback from the client. Like "thanks you now it's more clear" or something what tells me that he actually read my explanation. In such cases, if I am talking technical of less-important stuff, I do not write explanations. If I talk about something crucial or justifying my overtime, then I explain each technical word which I find that the client may not understand. Sorry for not being able to be more concrete.
    – Peter MV
    Nov 21, 2013 at 22:26
  • You were very descriptive. It helps to see how your thought process is when facing this type of scenario. I certainly know the feeling of not remembering my poor experiences, or at least I try not to ;). Nov 21, 2013 at 23:09

Most clients you will run into will not understand the terminology that we are used to. Jargon is a barrier meant to keep outsiders away. It is a code, and all professions have their jargon. Try to keep conversations free of words that the average person will not understand. Above all, be patient with clients. The biggest part of our job is relating to people, not writing code. Train yourself to explain things as simply as possible; don't go on for too long or you will lose their attention and understanding.

  • Great point about going on too long. I have seen the deer in the headlights look often. Dec 1, 2013 at 16:38

Speak to uneducated clients in terms you would use for a 12 year old. That is not to say be condescending or speak down to them, but use the words a 12 year old would understand. Or another way... think of explaining things to someone who English is a second language. That helps. I have some clients which aren't native English speakers so I often have to stop and restate a sentence using more basic words.

I too often fall into the "there's too much jargon in that" pitfall. I have to remember that in education, any education, you need to speak using universal words that even a child (pr pre-teen) will understand. Rather than "text box" or "input field" use "the area where they type in their name". (Although, I'm using Message Grabber from now on.) Or "spacing between sentences" rather than "line space" or "leading".

Once you do this a while you get the hang of it very quickly. And as I work with clients and they slowly learn what the terms mean it becomes less of an issue.

The tricky part is the initial conversations. You often don't know what the client doesn't know. So I try and pepper initial conversations with some terminology specifically (prepared to rephrase if needed) to see how astute the client maybe. The more astute the client the easier the conversations are.

  • I like the idea of thinking of English as a second language. So many times I am told by my family I speak a different language when I talk code. Dec 1, 2013 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.