In the game Chants of Sennaar, players traverse a tower of civilisations where each tribe speaks a different language. The players need to chat with locals, decode and understand the fictional languages, and pick up clues along the journey like a detective-slash-translator.
I never expected a game like this to echo so closely with my daily work.
As a support consultant, I respond to dozens of customer enquiries every day. On the surface, I’m solving technical problems. But in reality, I’m decoding language: vague, emotional, and often indirect expressions that hide deeper needs.
Reducing Ambiguity with Targeted Questions
“It’s not working.” “Can’t see it.”
Vague user messages like these are common — and tricky. But they’re not random. Often, users aren’t being vague on purpose. They simply don’t have the system vocabulary that we as builders do.
Instead of asking “What do you mean?”, I ask targeted, semi-open questions like:
“Are you looking to …, or…?” “When you say…, do you mean…, or…?”
Right questions reduces back-and-forth and makes the user feel understood.
Asking the right question, I believe, is part of the product experience. It a subtle form of service design.
Translating Vocabulary Across User and Internal Teams
Using the same words doesn’t always mean we’re speaking the same language.
Internally, we say “create” or “build” when we’re talking about setting up an entire workflow from scratch. But users? They usually say “create” when they refer to adding a single task. They also tend to call some functions “jobs”, or come up with other terms that simply make more sense in their own context.
It’s a small language gap but it can cause confusion on both sides, whether it’s users trying to explain what they need or the support team trying to interpret their requests.
Relying on internal definitions to understand users’ questions often gets support consultants nowhere. So instead, I simulate their user account and environment to understand exactly what they see and what they mean. It’s a daily act of translation between two worlds: internal logic and user cognition.
A glossary of terminology can be useful — but let’s face it, most users don’t have the time (or patience) to go through it.
(I loved keeping a notebook during Chants of Sennaar to note down what the symbols meant. Turns out it’s more fun when it’s a game.)
From Support to Strategy
Most user questions I deal with are about system configurations. As internal staff, we’re trained to think like builders: structured and systems-first. But users think like operators： goal-driven, task-focused, and often stuck in edge cases we never saw coming.
Mapping user questions and identifying recurring issues can help the team spot what’s missing and drive more user-centred updates.
However, not every gap is a product gap. Some are knowledge gaps. Adding a new function takes time — time for planning, building, testing. But writing a user guide? That’s a quicker fix. It’s like patching the experience with content: fast, low-cost, and surprisingly powerful when users just need to get unstuck.
Knowledge-Building as the True Value of Support
Solving a ticket is step one. But to me, support is about more than quick fixes. It’s about helping users build confidence and independence.
Maybe it comes from my background in teaching, but I genuinely believe that everyone deserves the chance to experience the joy of learning.
I try to encourage the users to explore the user guides as much as possible, and and I always make sure to acknowledge when they take initiative or figure things out on their own.
Moreover, after spotting recurring issues, I extract patterns, create user guides, and grow the knowledge base.
That’s how support shifts from firefighting to enabling — from answering questions to scaling knowledge.
Support isn’t just about solving problems — it’s about bridging gaps, like establishing connections between worlds in Chants of Sennaar: between systems and users, between language and intent, between what’s designed and what’s actually experienced.