Remote-work systems writer focused on clear asynchronous communication, practical workplace technology habits, and simple ways to explain confusing problems without unnecessary technical language.
Contact: seungeunisfree@gmail.com
Learning how to describe a technical problem to IT became easier when I stopped trying to sound technical. When something fails during remote work, I may know exactly what I was trying to do and exactly how the failure interrupted me. What I often do not know is whether the cause is the application, my account, the network, a device setting, a permission, or something happening somewhere I cannot see.
For a long time, that gap made me hesitate. I felt as though I needed the correct technical term before I could explain the problem properly. If a company page kept sending me back to sign-in, I wondered whether I should call it an authentication problem. If a meeting froze while the audio continued, I wondered whether I should mention bandwidth, latency, graphics, or a network connection.
The problem with that approach was simple: the technical word did not necessarily make my description more accurate. Sometimes it only made my uncertainty harder to see.
I now start with the part I actually know. I describe the action I took, the result I expected, and the result I saw. If the behavior repeats, I explain how. If another approved way of doing the same thing works, I mention the contrast. If the software gives me an error message, I preserve the wording instead of translating it into my own diagnosis.
I do not need to know what a technical problem is called before I can describe what it does.
This matters even more when I work remotely. A support person cannot lean over my desk and see the screen at the moment something goes wrong. They may read my description hours later. In an international team, they may also be reading it in a working language that neither of us grew up speaking.
That makes plain language valuable. Short sentences survive time-zone gaps. Exact interface labels survive translation better than slang. A simple description such as “the button changes to Loading and stays there” often communicates more than an impressive-sounding guess about which system component has failed.
Official software-support systems use similar ideas. GitHub's issue-form documentation includes structures for current behavior, expected behavior, steps to reproduce, and environment. Microsoft's Visual Studio problem-reporting guidance likewise asks for a clear problem description and reproducible steps where possible. Neither approach requires the person reporting the problem to know the root cause first.
When I cannot name the technology behind a problem, I ask: What did I do? What did I expect? What happened instead? Can I repeat it? What still works?
This article stays focused on description rather than the entire support process. I am not trying to collect every possible device detail or build the final help desk ticket here. The narrower goal is to turn a confusing experience into language another person can picture and investigate.
Start With What I Can Observe
I separate what happened from why I think it happened
When technology interrupts my work, I naturally want an explanation. A page stops loading, so I suspect the internet. A sign-in fails, so I suspect my account. A microphone disappears from an application, so I start wondering about drivers or permissions.
Those ideas can be useful later. They are not the same as facts I directly observed.
For example, “The file upload reaches 100%, then the page returns to the form and the file is not listed” describes behavior. “The server rejected my upload” describes a cause that I may not actually know.
The first sentence is safer because it stays true even if the eventual explanation turns out to be completely different.
I use the words that are already visible on the screen
I do not need to know whether something is technically a panel, modal, authentication prompt, workflow component, or browser element. If it has a visible label, that label is usually enough.
I might write, “I select Download report, the button changes to Preparing, and then it returns to Download report without creating a file.”
That description gives the other person an action and a result. There is no need for me to invent a name for the mechanism behind it.
The same idea works with navigation. “I open Settings and select Notifications” is clearer than trying to identify what kind of interface component Settings happens to be.
I describe state changes instead of using broad labels
Words such as crash, freeze, disconnect, and lock can mean different things in everyday conversation.
If an application closes without me closing it, I say that. If the window stays open but stops responding to clicks, I say that instead. If my laptop still shows Wi-Fi as connected while one company page stops loading, I report both observations.
Those small distinctions can matter to the person investigating the problem.
“The corporate network keeps failing because the VPN server is unstable.”
“The VPN continues to show Connected, but the internal project page stops loading after several minutes. Public websites still open normally.”
I leave genuine uncertainty visible
Sometimes I notice a possible relationship without knowing whether it matters. I do not have to hide that uncertainty.
I can write, “I first noticed the problem after switching from my home Wi-Fi to a mobile hotspot, but I do not know whether the change is related.”
That sentence preserves a potentially useful clue without turning the clue into a conclusion.
I use the same approach with scope. If I do not know whether anyone else is affected, I say so. I do not turn one coworker's silence into evidence of a company-wide outage.
I name the action immediately before the unexpected behavior appeared.
I describe the message, delay, missing option, frozen screen, repeated page, or other result I actually observed.
I keep confirmed facts separate from ideas about the underlying cause.
I leave unanswered technical questions unanswered instead of filling them with confident guesses.
I begin with observable behavior. Actions, visible labels, exact messages, and state changes give IT useful information without requiring me to diagnose the technology behind them.
Explain What I Expected and What Happened Instead
I define what “not working” means in this situation
“It does not work” may be completely true from my perspective, but it hides the part another person needs to understand.
A button can do nothing. A page can load indefinitely. A file can open but refuse to save. A meeting can continue while the camera freezes. A sign-in can appear to succeed and then send me straight back to the login page.
Those are different problems even though I could describe all of them as “not working.”
I make the difference clear by explaining what I expected first.
For example: “When I select Save, I expect the edited document to remain open with my changes. Instead, the Save button becomes unavailable for a few seconds, returns to normal, and my changes disappear when I refresh the page.”
I do not need to know whether the problem sits in the browser, application, connection, database, or account. The gap between expected and actual behavior already gives the support person something concrete to investigate.
I use the normal workflow when I already know it
A familiar workflow gives me a natural point of comparison.
If a meeting normally opens within a few seconds, I can say, “Normally, selecting Join opens the meeting. Today, the meeting window appears but remains on Connecting until I close it.”
I am not claiming to know why the behavior changed. I am identifying where the familiar sequence stopped behaving normally.
If I have never used the feature before, I avoid pretending I know the normal behavior. I can describe what the interface or instructions say should happen.
I mention what still works
A problem is often partial rather than total.
Perhaps I can open a workspace but cannot create a new task. Perhaps audio continues while video freezes. Perhaps the desktop application fails while the browser version still works.
Those working pieces help define the boundary.
Instead of saying “the project tool is broken,” I might write, “I can open the workspace and read existing tasks. The problem begins when I select Create task. The form opens, but selecting Submit produces no visible response.”
Now the support person knows that sign-in and basic workspace access are still functioning.
Action: I select Present now and choose one browser tab.
Expected: The selected tab should appear as the content I am sharing.
Actual: The meeting says I am presenting, but the other participant continues to see my profile image.
What still works: Audio continues normally, and I can still see the other participant's video.
I use simple contrast words
I do not need complicated sentence structures to describe a difference clearly.
Words such as normally, instead, but, while, before, after, still, and only do a lot of useful work.
“The desktop app does not update new messages, while the browser version does.”
“The first file uploads normally, but the second remains on Processing.”
“The camera works before I enter the meeting, then turns black after I join.”
These sentences are simple enough to read quickly and specific enough to narrow the problem.
I replace “not working” with a clear difference between the result I expected and the result I actually saw. Mentioning what still works often makes that difference even more useful.
Replace Vague Words With Observable Details
I unpack words such as slow, weird, broken, and random
Everyday words are helpful until one word can describe several very different experiences.
“Slow” is a good example. A page might take a long time to appear. Typing might lag behind my keyboard. A file might download slowly. An application might open normally and become less responsive after I use it for an hour.
If I write only “my laptop is slow,” the support person cannot tell which experience I mean.
I replace the adjective with the action that feels slow.
“After I select Search, the page shows a loading indicator for about 20 seconds before the results appear. Other pages in the same application open within a few seconds.”
That description is far more useful without being more technical.
I turn “sometimes” into the pattern I actually saw
Intermittent problems are difficult enough without vague frequency.
If I can remember how often the behavior appeared, I include that.
“The microphone stopped sending audio during three of four calls this morning” gives more information than “the microphone randomly stops working all the time.”
If I cannot find a pattern, I say that directly.
“The problem occurred twice today during different tasks. I have not found a repeatable pattern yet.”
That sentence is honest and still useful.
I use practical estimates rather than false precision
Duration can turn a vague complaint into something another person can picture.
If a screen pauses briefly, I estimate whether the pause is closer to two seconds, twenty seconds, or several minutes. If a connection drops after a period of use, I describe the rough interval.
I do not invent laboratory precision. “About 15 to 20 seconds” is usually more appropriate than “17.6 seconds” unless an actual diagnostic tool produced that number and the precision matters.
I describe the visible change
I pay attention to what changes when the problem begins.
Does the button turn gray? Does a loading icon remain on the screen? Does the status change to Reconnecting? Does the application window disappear? Does an empty area replace the content that was there before?
Those details help because another person can recognize them in the product.
“The video call gets weird and laggy all the time.”
“Incoming video freezes for roughly 10 to 20 seconds while audio continues. The video then catches up without me leaving the meeting.”
I do not avoid ordinary language; I make it specific. Duration, frequency, visible state changes, and concrete failed actions turn vague descriptions into useful observations.
Describe the Shortest Sequence That Leads to the Problem
I begin close to the point where the problem starts
A technical problem often happens at the end of a long work sequence. That does not mean I need to describe the entire sequence from the beginning of my day.
If an upload fails, the useful starting point may be the page where I am already signed in and ready to select the file.
I might write, “I open a saved expense claim, select Add receipt, choose a JPG file, and select Upload. The progress indicator reaches the end, then the receipt area becomes blank and the file does not appear.”
That sequence is short enough to follow and complete enough to show where the behavior changes.
I use the exact labels I see
I do not worry about whether a control is technically a button, link, menu item, or command.
If it says Share screen, I write “I select Share screen.” If a section is labeled Billing, I write “I open Billing.”
Using the product's visible wording gives the support person the same landmarks I used.
I stop the sequence at the first unexpected result
Once the failure appears, I do not need to keep adding unrelated actions merely to make the reproduction steps longer.
The important point is where the normal path stops.
If I select Submit and the page remains on Loading, that may already be the end of the useful sequence. What I did ten minutes later belongs elsewhere if it matters at all.
I say whether I can reproduce the behavior
Some problems happen every time. Others appear once and disappear.
I make that distinction explicit.
“I repeated the same sequence three times, and the upload stopped at the same point each time.”
Or: “This happened once during the 10:00 a.m. meeting. After I left and rejoined, the problem disappeared, and I have not reproduced it since.”
Neither version is better. They simply describe different kinds of evidence.
GitHub's official issue-form documentation reflects the same basic structure by separating current behavior, expected behavior, reproduction steps, and environment in bug-report forms.
Official reference: GitHub Docs — Syntax for issue forms
I can explain a problem without technical jargon by describing a short sequence of visible actions. I start close to the failure, stop when the unexpected result appears, and state whether I can reproduce it.
Use Comparisons to Show the Boundary of the Problem
I look for a nearby situation that behaves differently
Comparison is one of the most useful tools I have when I do not know technical terminology.
I ask whether the same account works somewhere else, whether one file behaves differently from another, or whether one feature still works inside an application that is giving me trouble.
For example, “The document opens in the browser, but the desktop application shows a blank window” creates a clear boundary without explaining why the two versions differ.
Likewise, “My headset works in the system microphone test but does not appear in the meeting application's microphone list” gives support a useful contrast.
I change one meaningful condition at a time
If I change five things at once, the comparison becomes difficult to interpret.
Suppose I move from my laptop to another device, switch browsers, use a different account, connect to another network, and try another file. If the problem disappears, I know something changed, but I do not know which difference mattered.
When it is safe and permitted, I prefer a simple comparison.
Same laptop, different approved browser.
Same browser, different file.
Same account, browser version versus desktop application.
Those comparisons are easier to explain and easier for another person to use.
I do not turn a useful comparison into a conclusion
If something works in one browser and fails in another, I do not automatically announce that the failing browser is broken.
There may be an extension, policy, stored session, compatibility issue, or another cause I have not considered.
I report the contrast itself.
“The upload fails in my managed Chrome profile and succeeds in the approved Edge browser on the same laptop.”
That sentence gives IT a strong clue without forcing them to start from my explanation.
I stay inside approved workplace boundaries
I do not perform unsafe tests merely to create more evidence.
I do not disable security software, remove device management, upload company files to a personal service, install an unapproved application, or use an account I am not supposed to use.
A clean comparison is useful only when the comparison itself is appropriate.
The browser version works, while the desktop application does not.
The behavior changes when the permitted network connection changes.
One file, meeting, record, or folder works while another does not.
The application remains usable, but one specific function fails.
I stay within approved workplace tools, accounts, networks, and data-handling rules. If a test would require changing security controls or moving confidential information somewhere it does not belong, I leave that step to the appropriate support team.
Comparisons help me show where a problem begins and ends. I report “works here, fails there” without pretending that the comparison proves the root cause.
Use Error Messages and Screenshots Without Overinterpreting Them
I preserve the wording the software gives me
If an application gives me an error message, I do not need to rewrite it in more technical language.
I copy the relevant wording accurately when it is safe to do so.
“After I select Send, the page shows ‘Unable to complete request’ and error code X123.”
That is better than changing the message to “the server rejected my permission” unless the software actually says that.
The original wording gives the support person something they can recognize or search without my interpretation getting in the way.
I explain when the message appears
An error message has more meaning when I connect it to the action that produced it.
“The message appears immediately after I select Confirm. When I close it, I remain on the same page and the request does not appear in Recent submissions.”
That tells the reader what happened before the message and what state remained afterward.
If the message disappears quickly or the application closes after it appears, I include that behavior as well.
I use screenshots as supporting evidence
A screenshot can be helpful when a visual state would take too many words to describe. It still needs a sentence of context.
“Screenshot attached” forces the reader to decide what matters in the image.
I prefer: “Screenshot attached showing the Upload button still gray after the progress indicator reaches 100%.”
Now the written description and the image point to the same observation.
Microsoft's current Visual Studio problem-reporting guidance likewise emphasizes clear reproduction information and supports screenshots and diagnostic material where they are useful to an investigation.
Official reference: Microsoft Learn — Report a problem with Visual Studio
I check what else the screenshot reveals
A screenshot of my work screen may contain far more information than the error I intended to show.
Open tabs can reveal project or customer names. Notifications can show private messages. Documents behind the error window may contain confidential material.
I crop or redact unrelated information through approved methods when necessary.
I also keep passwords, one-time verification codes, recovery secrets, private keys, and other credentials out of ordinary support requests.
“I open the Benefits page and select Update details. The form opens normally. After I change my phone number and select Save, a red banner appears saying ‘Your changes could not be saved.’ No error code appears. The form remains open, but after I refresh the page, the old phone number is still there.”
This description says nothing about a database, validation service, server, or account configuration. It does not need to.
The action, message, and final state already give support a reliable starting point.
I preserve exact error wording and explain what happens before and after it. Screenshots support that explanation, but they do not replace it, and I check visual evidence for unrelated sensitive information before sharing it.
Turn the Observations Into a Natural Support Description
I put the information in the order another person needs it
Once I know what I observed, I do not need a complicated formula to explain it.
I name the place where the problem occurs. I describe the action that triggers it. I say what I expected and what happened instead. Then I add repeatability or one useful comparison if either one helps.
The result should sound like normal English rather than a diagnostic worksheet.
A camera problem can be explained without diagnosing the camera
“Before I join a meeting, the camera preview shows normally. After I select Join, my video appears for about two seconds and then turns black. Other participants can still hear me, and I can see their video. Leaving and rejoining produces the same result. The camera preview outside the meeting continues to work.”
The description contains no theory about drivers, permissions, bandwidth, hardware acceleration, or codecs.
It does not need one. The behavior already has a clear boundary.
A form problem can be described as a sequence
“I can open the travel request form and complete every required field. When I select Submit, the button changes to Submitting for about five seconds and then returns to Submit. No confirmation appears, and the request does not appear in My Requests. I repeated the process twice with the same result.”
The underlying cause could sit in several places. That uncertainty does not make the description weak.
The support person now has an action, a visible change, a missing expected result, and evidence that the behavior repeats.
An intermittent remote-access problem can stay factual
“While I am connected to the company VPN, the internal project page occasionally stops loading and eventually shows a timeout message. During the same period, public websites continue to open. The internal page begins working again after I disconnect and reconnect the VPN. This happened twice this morning, roughly an hour apart.”
I have not called the problem a VPN server failure, a routing issue, or an internet outage.
The person investigating it can decide which explanation fits the evidence.
I remove sentences that mainly communicate frustration
Frustration is normal when technology interrupts work, but it rarely needs much space in the problem description.
“This ridiculous issue has wasted my entire morning” describes my experience.
“The camera failure interrupted three scheduled client calls because my video turned black immediately after I joined” describes the operational effect.
The second sentence gives the support person information they can use.
I reread the finished description without imagining my screen
My final check is simple.
I pretend the text is all I have. Can I tell which action begins the problem? Can I picture the unexpected result? Do I know what should have happened? Can I tell whether the problem repeats?
I also look for vague references such as “it,” “that thing,” or “the normal page.” If the reader could reasonably misunderstand what those words refer to, I replace them with the actual application, feature, file, or page name.
This editing pass does not make the description more technical. It makes the description portable.
The goal is not to prove how much technology I understand. The goal is to give another person a reliable picture of what the technology did.
A strong plain-English description combines context, action, expected behavior, actual behavior, repeatability, and a useful comparison when one exists. Technical jargon is optional; clarity is not.
Frequently Asked Questions
Describe what you can observe. State what you were doing, what you expected to happen, what happened instead, whether the behavior repeats, and what still works. Use visible application and interface names rather than guessing at the technical cause.
Yes. Clear uncertainty is more useful than an unsupported diagnosis. If you noticed a possible relationship, describe it as a possibility and keep it separate from the facts you directly observed.
Name the specific action or function that fails. For example, explain that the laptop turns on normally but a meeting application cannot use the microphone, or that the browser opens the company portal but one page remains on Loading.
Describe the frequency and any pattern you have actually observed. Include how many times it happened, what you were doing, approximately how long the problem lasted, and whether it recovered by itself. If you have not found a pattern, say so.
Avoid presenting a guess as fact. Start with the observable behavior. If your theory may be useful, label it clearly as a possibility and explain which observation made you consider it.
Include the shortest sequence needed to reach the problem from a relevant starting point. Use the visible labels on the interface, stop at the first unexpected result, and state whether repeating the same sequence causes the same behavior.
Usually not by itself. Add a short explanation of what you were doing, what the screenshot shows, and what should have happened instead. Check the image for unrelated personal, confidential, or authentication information before sharing it.
State where the problem occurs, what you do, what you expect, what happens instead, whether it repeats, and one useful comparison if available. That structure works even when you do not know any specialist terminology.
Conclusion
I no longer treat technical vocabulary as the price of entry for asking IT for help. If I do not know whether a problem involves authentication, networking, permissions, hardware, a browser, or an application service, I do not have to choose a label simply to make the description sound legitimate.
I begin with the part I can verify.
I state what I was doing. I explain the result I expected. Then I describe what appeared instead. If the behavior repeats, I show the shortest sequence that reproduces it. If another approved situation works differently, I mention the comparison without declaring that I know why the difference exists.
That approach makes technical communication much less intimidating. I am no longer trying to translate an unfamiliar problem into vocabulary I only partly understand. I am describing a sequence of events in ordinary language.
This is especially useful in remote work. A support person may receive my description after I have stopped working for the day. They cannot ask me to point at the screen. The words have to carry enough of the experience that the problem still makes sense without me standing beside it.
A sentence such as “the app is glitching” does not travel well. “The app opens normally, but selecting Create report leaves the page on Loading for more than a minute and no report appears” does.
I also try to preserve uncertainty instead of covering it with jargon. If the problem happened once, I say once. If I cannot tell whether anyone else is affected, I say that. If a comparison suggests a clue, I report the clue rather than converting it into a diagnosis.
That restraint gives the support person cleaner information. They can build technical explanations from observations that have not already been distorted by my guesses.
Clear problem descriptions are therefore less about knowing the right technical nouns and more about noticing useful differences. What changed? Where does the normal sequence stop? What still works? What exact message appears? Can the same behavior happen again?
Those questions give me something concrete to write even when the technology behind the screen is completely unfamiliar to me.
Before I send the description, I read it once from the other person's point of view. If someone who cannot see my screen can picture what I did and what happened next, I have probably explained enough for the investigation to begin.
The next time a remote-work tool behaves unexpectedly, do not start by naming the cause. Write three short sentences first: what you did, what you expected, and what happened instead.
Then add whether the behavior repeats and, if useful, one safe comparison that shows where the same action still works. If another person can picture the sequence from those sentences, you already have the core of a clear technical support description.
Sam Na writes about remote-work systems, asynchronous collaboration, job-search organization, workplace technology habits, and practical communication that reduces unnecessary friction across distributed teams. His focus is on helping people turn confusing work situations into clear, manageable next actions without requiring complicated systems or specialist language.
Contact: seungeunisfree@gmail.com
This article provides general information about describing workplace technology problems to IT or technical support. The right reporting process, troubleshooting method, terminology, evidence requirements, and communication channel can vary by employer, application, device, security policy, and the seriousness of the issue. Before changing managed settings, sharing diagnostic information, handling a suspected security incident, or taking an action that could affect company systems or data, check your organization's current guidance and official support process. For important technical, privacy, security, access, or compliance decisions, it is a good idea to confirm the appropriate next step with qualified staff or the relevant official documentation.
Official GitHub documentation showing structured fields for current behavior, expected behavior, reproduction steps, environment, and additional context in issue forms.
Official Microsoft guidance covering clear problem reporting, reproduction information, screenshots, and diagnostic material used when investigating software problems.
