How to Explain a Technical Problem Without Knowing Technical Vocabulary

Use the Witness Card: be a witness, not a mechanic

When you lack technical vocabulary, organise the report around six jobs:

TARGET

What device, app, object or context are you talking about?

TRY

What were you trying to do?

OBSERVE

What actually happened instead?

PATTERN

Did it happen once, on several observed attempts, or consistently as far as you know?

IMPACT

What useful task can you not complete?

ASK

What information does the listener need from you next?

This Witness Card is FunFluen’s practical communication framework, not an official technical-support protocol. Its purpose is to help you hand reliable evidence to someone with more technical knowledge without impersonating that expertise.

Weak report vs useful report

Weak: “The upload system is broken.”

Useful: “I’m using the document-sharing app. I select a file and tap Upload. A spinning indicator appears for a few seconds, then disappears, but the file is not listed. It happened on both attempts I made today, so I can’t submit the document. What information would help you narrow this down?”

The second version uses more words, but not more jargon. More importantly, it gives the listener a sequence of evidence.

Why evidence is more useful than a confident guess

Professional software-reporting guidance uses the same basic distinction. Mozilla Bugzilla’s current Bug Writing Guidelines ask reporters for precise steps that reproduce a problem, the expected and actual results, how reproducible the issue is, and a separation between observations and speculation.

Current Google Chrome feedback guidance likewise asks users to add details and steps that help recreate the issue, with optional context such as a web address or screenshot.

Those are software-reporting workflows, not universal rules for every technical problem. But they support a powerful communication principle: the person receiving your report can work with observed behavior even when you do not know the root cause.

A cause claim can be grammatically perfect and still be a bad report

Original: “The server is broken.”

Classification: grammatically valid, but context-dependent and unsupported in our fictional scenario.

What the listener hears: a claim that the server is the cause of the problem.

What the learner probably means: “The upload failed, and I do not know why.”

Natural evidence-first alternative: “I don’t know the cause. When I tap Upload, the spinner disappears and the file isn’t listed.”

When the original could be valid: if a reliable source has actually established that the server is down or malfunctioning. The language itself is fine; the problem is presenting an unverified diagnosis as fact.

Start with TRY → OBSERVE

If your first report contains only two sentences, make them these two jobs:

TRY: “I’m trying to upload a PDF.”

OBSERVE: “After I press Upload, the spinner disappears and the file does not appear in the list.”

This is often clearer than “Uploading doesn’t work” because the listener can see the gap between the action you intended and the behavior you observed.

What does “expected” mean if you are not an expert?

You do not need to invent a technical specification. State the result you were trying to get, or a result you genuinely know was normal in your own context:

• “I was trying to save the file so it would appear in the folder.”
• “Normally this button opens the settings page. Today it returns me to the same screen.”
• “I expected the document to appear in the upload list because that’s what happened before.”

Do not claim what the product should technically do unless you actually know that.

If you know the trigger, tell the movie—not the theory

In software support, you may hear the term steps to reproduce. In plain language, that means a short sequence of actions that makes the same behavior appear when you actually know that sequence.

For example:

1. I open the document page.
2. I choose a PDF.
3. I press Upload.
4. A spinner appears for a few seconds and disappears.
5. The file is not added to the list.

That sequence is useful because it tells the movie of the problem. It does not say, “The upload API has a timeout,” “the cache is corrupted,” or any other theory you cannot verify.

Do not manufacture a reproduction sequence if the issue happened only once and you do not know how to trigger it again. “It happened once while I was uploading a file, but I haven’t been able to reproduce it” is a perfectly respectable report.

PATTERN: do not turn two events into “always”

Frequency words sound small, but they can quietly overstate your evidence.

Original: “It always crashes when I tap Share.”

Classification: grammatically valid, but context-dependent and too strong if you have only observed two attempts.

What the listener hears: the behavior occurs every time under that condition.

What the learner may actually know: it happened on the two attempts they made today.

Natural alternative: “The app closed on both attempts I made today after I tapped Share.”

When “always” is valid: when you genuinely have enough experience to support an every-time claim in the stated context.

Useful honest pattern language

• “It happened once.”
• “I’ve seen it twice today.”
• “It happens sometimes, but I don’t know the pattern yet.”
• “It has happened every time I’ve tried this today.”
• “I’m not sure how often it happens.”

No invented percentages. No “90% of the time” because three attempts felt like a lot.

Report known recent changes without turning them into causes

A recent change can be relevant context. It is not automatically the explanation.

Useful: “I updated the app yesterday, and I first noticed this problem today.”

Too strong without evidence: “The update caused the problem.”

The first sentence reports two facts and their timing. The second makes a causal claim.

If you have a hypothesis, label it:

• “I’m not sure whether the update is related.”
• “This started after the change, but I don’t know if the change caused it.”

Do not promote your guess to CEO of the sentence. Let it stay a guess until someone has evidence.

Do not know the part name? Give two clues and keep moving

This article is not a full circumlocution lesson. For a technical report, you often need only enough description to identify the area or object provisionally.

Use two simple clues:

• Location: where is it?
• Function or behavior: what does it connect to, move with, display, open, hold or control?

For example:

“I don’t know the name of the part. It’s the small piece beside the charging socket, and it moves when I plug the cable in.”

Or:

“I mean the icon at the top right—the one I use to share the document.”

If the listener supplies the technical term, great. You can use it from that point. You did not need it to begin the report.

IMPACT: say what the problem stops you from doing

“It’s annoying” tells the listener how you feel. “I can’t submit the document” tells them what the problem blocks.

Useful impact statements include:

• “I can open the file, but I can’t upload it.”
• “The app closes before I can share my screen.”
• “The printer starts, then stops before producing a page.”
• “The control changes on the app, but the physical light does not change.”

These are illustrative communication examples, not diagnoses and not troubleshooting instructions.

Let the knowledgeable person ask the technical questions

A good first report does not need to contain every technical detail in the universe. It should make the next question easier.

If support asks for information you know, answer it. If you do not know, say so without improvising:

• “I’m not sure which version it is. Where can I find that information?”
• “I don’t know the name of that setting. Could you describe where it is?”
• “I haven’t checked that, so I don’t want to guess.”
• “What information would help you narrow the problem down?”

Current Chrome feedback guidance asks users for details and steps that help recreate an issue because useful support is collaborative: the first report starts the investigation; it does not have to finish it.

Fact-or-Theory Witness Lab

Use this fictional software problem:

You are in a document-sharing app. You select a file and tap Upload. A spinning indicator appears for a few seconds, then disappears. The file is not listed. You observed this on two attempts today. You do not know the cause.

Before opening each answer, classify the statement as FACT, HONEST CONTEXT or THEORY.

Now build the Witness Card

Say your report aloud before opening the model.

The 20-second no-cause practice pass

Take one fictional problem and explain it for about 20 seconds without using because, must be, definitely, or a named root cause.

You may add a sentence such as “I’m not sure whether the update is related” after the observable report.

This is a rehearsal constraint, not a rule that causes should never be discussed. Its job is to prove that you can build a useful first report before your vocabulary or technical knowledge is complete.

Make the symptom-first report easier to say aloud

The Witness Card comes first. Once you know the information jobs—TARGET, TRY, OBSERVE, PATTERN, IMPACT and ASK—the next challenge is retrieving the language quickly enough to give the report under pressure.

If English is your target language, FunFluen can support general speaking practice after you build the technical scenario yourself. The exact support scenario is not preloaded after the click, and FunFluen does not diagnose, troubleshoot or repair the system you are describing.

Practise short symptom-first problem reports in English

Know when this is only a communication tool

This guide helps you describe a problem. It does not tell you how to fix one.

For safety-critical systems—such as vehicles, dangerous machinery or medical equipment—do not use language practice as a substitute for appropriate qualified support. Report what you observe as clearly as you can and follow the relevant professional or emergency procedures for the real situation.

Missing terminology does not make you useless

You do not have to walk into a support conversation carrying a diagnosis and a pocket-sized engineering degree.

Be a witness. Name the target as precisely as you can. Say what you tried. Describe what happened instead. Report the pattern honestly. Mention relevant context without turning it into a cause. Explain what the problem blocks. Then let the knowledgeable person ask for the next detail.

The goal is not to sound technical. It is to make your evidence easy to work with.