How can you simplify technical information?

One thing I've found helpful is use cases, sometimes the customer doesn't know what to ask for or provides vague answers. I find use cases help by getting to the root of the issue and help determine the scope of the problem as isolated or widespread. Another option is to ask follow-up questions like are your aware if anyone else on your team is having this.

Often I've found that the end user simply doesn't know the right terminology to explain a problem or understand a concept. If you can: - Identify what terminology they ARE familiar with - Translate the concept into a metaphor they're comfortable with - Do these without talking down to them You'll have greater success in getting your point across or helping them comprehend what's going on. Talk with them, not at them. It all starts with a little bit of understanding. In my work I've explained things using scenes from movies, food, or even farming equipment to get a working dialog going. Be creative!

It's important to grasp the type of company you're working for, and the users it contains. Taking a moment to know someone's title and a bit of information about their role is helpful in knowing how you can communicate with them. A person in a legal department typically doesn't care for detailed explanations about why/how something gets done, they commonly just need an issue resolved so they can continue working. In this instance, you simply need to give them a single, simple sentence about what you're doing or ask if you require more information. Alternatively, if you're in IT, and you're working with another type of IT personnel, the jargon or abbreviated terms relevant to your field can be used instead.

Situational awareness of terminology definitions and differences is a critical success factor. An example of this is “turning it on” is means the same thing as “cutting it on”.

When you support and write documentation for different users, you need to use a different approach for them. If you're writing documentation for internal IT personnel, keep it factual, straightforward, and neat, but feel free to abbreviate some expectations. If you're writing documentation for front-end basic users, take the time to go through each step and write exactly what you're doing, even if it seems mundane. Depending on the process, it's easy for a user to get confused, so the goal is to make sure your documentation is lining up exactly with what the user sees. One of the most important things is to review your documentation draft multiple times, each time cleaning it up, and simplifying it.

Analogies can be a staple when explaining technical concepts, I recall a time when supporting a Citrix estate with limited licenses and a user not understanding why they couldn't access at that time (due to all licenses being used by other users). Ultimately I ended up explaining it to them in this way, to imagine a car park with only 15 spaces and at the time they'd arrived, all the spaces were taken. They would have to wait till someone left so that they could 'park their car' ... you could hear the penny drop ??

We think people communicate like we do. Big mistake. The three basics - audio, kinesthetic and visual - are further compounded by Gardner's discovery and sharing of 'multiple intelligences' engaged in learning. So much can be done to explore the depths of not just 'good' communication. Items used cover ways to further engage and inform appropriately across the spectrum.

Any time I send instructions in an email or text I try to give at least one image for context, or to clarify the most confusing step. I will also finish my directions and read them fully and carefully twice before sending. This helps to catch mistakes that can be even more confusing for those we are trying to help.

An important practice I acquired during my military experience and have since incorporated into my professional life is the skill of summarizing and restating requests. This technique serves two essential purposes: firstly, it allows me to confirm my complete comprehension of the task at hand, ensuring that no aspect has been misunderstood. Secondly, it demonstrates to the individual assigning the task that I have actively listened and fully understood their request. By employing this approach, I foster effective communication and minimize the risk of misinterpretation or errors.

This is called 'active listening' and offers immense benefits when applied. Year's ago, decades actually, the phrase, 'Nobody cares how much you know until they know how much you care,' was a key feature of communication training in sales. It applies to life, too.

Here are a few keys to think about: Empathy Never talk down Customer defines emergency It is impossible to over communicate Even difficult customer’s money is green ?? #PhoneBill

I think one of the most imperative things about supporting users is the understanding that you're working with them together as a team. The issue a user is facing relies on two major things: What information the user provides to you, and the actions you take using that information. With this, make sure you use inclusive language and keep you and the user as a unit. The last thing you want to do is make the user feel “separated” from the solution. As you are working as a team, be mindful of your tone when communicating. Remember, you're representing your department when you interact with people, so it's important to try to build that relationship with users. Happy users will be more helpful to you in the future as a result.