3 minute read
Making life easy for your users can often make life a lot more complicated for you.
In trying to meet all their (ever-evolving) requirements, ensure you maintain good quality data and trying to imagine every which way they could act, your tools and applications can get complex. Fast.
If you happen to have a customer/product owner/user who doesn’t appreciate the technical side, then explaining this can become extremely tricky, especially when issues and problems are discovered.
This can be a big deal.
Get your explanation wrong and they are potentially going to think you are trying to con them.
Quickly they are then going to start questioning everything you’re saying. And that, is a one-way path you’ll want to avoid like the plague …
The issue is that they may not understand your technical reasoning.
If you’re put on the spot, you are going to have to think on your feet and try to explain what is going on.
But, how do you approach that so it doesn’t sound like BS?
If you knew what to say and how to say it, you could maintain their trust. If you did it really well, you could even increase the level of trust and respect that they have for you.
From potentially being the villain, instead you become the hero-of-the-hour!
But is this even possible?
Well, yes, I believe so.
There are three things to address:
– The impact of the issue.
– Communicating its impact in a way the customer will understand.
– Determining how best to resolve it whilst reasoning this to the customer.
The impact of the issue you should be able to quickly determine from your technical understanding of the system.
If it is highly complex, for example pulling in several different data sources, or an especially complicated data model, then it is always useful to use an analogy with your customer.
A good analogy I’ve successfully used a few times is an iceberg.
There is stuff you see (the dashboard, charts, buttons etc) and stuff you don’t see.
Think of this as a lot of “plumbing” going on under the surface.
What is under the surface enables what they see – your smooth and simple user experience.
Depending on the system, swan’s and buildings (foundations, hidden pipework etc) are other good ones too.
“Try to think of every day systems that resemble, in principal, how your app is working.
The key here is transparency and honesty of intent.
You are genuinely trying to explain what is going on.
You’re not trying to confuse them with jargon or techno speak.
You do want them to actually understand the situation, as best they can.
Trust comes through transparency of action and intent.
Your primary objective during your explanation is to maintain (and build) their trust in you.
It is worth reminding them that no professional sets out to design something overly complex, slow and hard to maintain.
Applications and projects naturally evolve with peoples requirements that develop, change and flex.
Design choices made in the past, might not be appropriate now.
There is normally a good reason why choices were made and it is often not anyones “fault” per ce.
They are prototypes. Prototypes break, but you can (and will) fix them.
People do make mistakes though.
If this is you, hold your hand up – best you can.
Offer to take on some of the responsibility for fixing the situation.
Offer what you have to offer, either a discount on the fix, some free overtime, working through lunch, coming in a bit early or staying a bit late for a few days.
Too often people get defensive, try to pass the buck too early.
This is the fast-track to that one-way path to zero trust we are looking to avoid.
With a reasonable, honest approach you can calm any tension and help everyone move forward.
Offer to show willing. Be honest. This is a technical situation. There will be lots of possible technical solutions.
Keep it simple, keep it objective and keep developing your analogies.
If you have ever been in this situation and have a good analogy that worked for a particular situation, it would be great to hear about it. Drop me a line at our email (email@example.com)