“The upload is broken” gives a support person a place to start guessing. “A 2 MB PNG reaches the progress bar, then shows this error after I press Save” gives them something to investigate. A useful report reduces uncertainty without needing a wall of technical vocabulary.
Separate the intention from the result
Use two short sentences: “I expected…” and “I observed…”. Describe the visible outcome before proposing a cause. A frozen progress indicator is an observation; a server failure is a hypothesis unless you have evidence for it.
Then list the few actions needed to reach the problem. Start from a recognisable screen and include the action that triggers the failure. If it happens only sometimes, say so. Do not turn an intermittent problem into “always” because it feels more emphatic.
Include a small, safe example
A harmless sample file is often easier to test than a confidential document. Note its format and approximate size. If the issue concerns an image, its pixel dimensions may also help; our guide to pixels and resolution explains why those are separate from print density.
Record the app or browser version when available, the device type and the time of the attempt with a time zone. Remove passwords, access tokens and personal information from screenshots or copied messages before sharing them.
Say what changed
If you tried another browser or a smaller file, report the result of each test separately. Change one condition at a time where practical. “Both failed” is useful only when the reader knows what both refers to.
Finish with the exact question you need answered: a workaround, confirmation of a limit, or help locating the failure. A clear report does not prove a diagnosis. It makes the next useful test easier to choose.