Skip to main content

Found in Translation: Developers to BAs to End Users

As a business analyst working on the operations side of the house, I often have to translate between the developers who make the fancy stuff

(i.e. integrations, exceptional Javascript, etc.) and the end users who actually utilize the byproducts of the fancy stuff. But the question often remains: how do you explain enough to your end users without overwhelming them with the finer details? Let’s face it – the finer details might excite us, but they will do nothing but confuse our end users.

1. Understand enough about your topic from a technical standpoint to talk about it.

  1. That doesn’t mean that you have to understand the ins and outs of any given programming language. But you have to understand that when your developer says “point A goes to point A.1 goes to point A.2 goes to point A.3 goes to point B”, what he or she is really saying is that point A goes to point B. That is what your end users need to hear. All the steps in between are exciting and necessary but superfluous to almost all of your end users.
  2. Leave the jargon out of conversation with your end users: give it to them in the plainest language you can muster. As I have told a colleague – you will feel like you’re over-explaining, but you need to over-explain in order to explain.

2. Don’t forget about the business.

  1. Your end users’ demands might seem wildly unreasonable. Listen with the end goal of understanding, not necessarily solving. Listening comes first – solving will come later. Your ears need to be in tune to what is really going on with the business. Are they facing a difficult customer, or a project that is in trouble? When they say something is a red-hot emergency, they might not be exaggerating even though it’s the fifth red-hot emergency this week. At the end of the day, the business needs to continue, and you will prove invaluable to your end users if you can meet their ever-changing needs.
  2. Your end users are your customers. Bottom line. Treat them as well as your company treats their external customers.


3. Know your audience.

  1. This cannot be stressed enough. An executive doesn’t need the same information as the end user who is performing the action.
  2. An executive wants to know that it works and that it saves time, money, effort, or all three. Think of it like a stoplight. They want to know that green means go, yellow means hold on, and red means stop, problems ahead!
  3. An end user needs to know what buttons to push, which links to click, which files to attach – all the specifics. If you can give them a document with simple step-by-step instructions, so much the better. But they still don’t necessarily need to know all of the technical aspects hiding behind the scenes unless it directly affects how they will perform the task at hand.
  4. That being said, don’t talk down to your end users. They are your best advocates. Help them to understand and they will help you.
  5. Be patient even if it hurts. What seems like a simple concept to you might not be simple for someone else.

4. Make sure your users know they can come to you for help.

  1. Our job as BAs is to be helpers. We are the facilitators of solutions, the guides of actions. Sometimes we build those solutions and perform those actions, and sometimes we don’t. But when things (I won’t say specifically what) hit the fan, we are the ones who are consistently called in to help organize, define, moderate, instruct, and a multitude of other verbs that cannot be articulated in just one sentence.
  2. In those stressful moments, your end users don’t need to know the ins and outs of every solution. They need to know that you’ve got the problem in hand and that you will bring in the right people to solve it, whether that’s someone else, or you – the solver of problems, the finder of solutions, the sense-maker of all that fancy stuff.

Comments (3)