As we have seen, when writing documentation, there is a need to adapt the language used to the audience. To do this, we must have a good picture in our mind of who the audience is, what their current level of knowledge is, and what they're trying to accomplish. A notorious challenge for programmers is communicating with less technical or non-technical people. This is a very common and crucial part of their role as a creator of software. Whether communicating with end users at specific points in a UX, or collaborating with non-technical stakeholders, there is a need to tailor our communication to the audience. To do this, we should do the following:

• Pick the right level of abstraction: It's crucial to find a level of abstraction that is fully understood by the audience. Use their roles and proficiencies to inform the analogies you use to explain things. For example, if you were talking to a patient about a piece of medical software, you might prefer to say please add your medical information instead of please populate the medical profile fields.
• Avoid overly-technical terminology: Avoid words that mean nothing to the audience. Use regular language to explain detailed concepts. For example, you might talk about visual enhancements instead of CSS modifications.
• Get constant feedback: Ensure you are being understood by checking with your audience. Don't assume that people understand you just because they don't explicitly say otherwise. Consider user-oriented prompts in your documentation or software (for example, was this message helpful? [YES] [NO])

Communicating with non-technical individuals may appear to be a distinct challenge, but it is no different from communicating with anyone else. As we should be doing all the time, we just need to meet the person where they're at and communicate according to their current understanding of the problem domain.