A useful bug report says what you did, what you expected, what happened instead, where it happened and how often. Add a screenshot or a short recording. Leave out guesses about the cause. "It's broken" is a feeling, not a report.
The six parts
Steps. List what you did, in order, starting from a known place such as the home page. Engineers need to repeat the bug, and they can only repeat what they can read.
Expected result. Say what you thought would happen. The gap between expected and actual is the bug.
Actual result. Say what happened, in plain words. Copy any error message exactly as it appears.
Place. Name the page or feature, the device, the browser and the app version if you can see one.
Frequency. Say whether it happens every time, sometimes, or once. "Three times since Tuesday" tells an engineer where to look.
Evidence. Attach a screenshot or a short screen recording. A picture of the error settles most arguments about what the error said.
An example
Weak: "Export is broken."
Useful: "I clicked Export on the Reports page once. Two files downloaded. I expected one. Chrome on macOS, signed in as an admin. It happened three times since Tuesday."
The second report takes forty seconds longer to write and saves an engineer an afternoon.
What to leave out
Leave out passwords, access tokens and private data about other people. Leave out the theory that "the last update must have done it" unless you saw something that points to it. A theory can send an engineer in the wrong direction. A clear description of what happened cannot.
If you receive the reports
Most reports arrive incomplete. The missing part is usually frequency or place, and a short follow-up question gets it. Ask once, in the channel the user wrote from, and attach the answer to the original report so nobody has to ask again.
SylvieSI does this in Mobius. When a message lacks a step or a place, the Triage agent drafts the question, and a person, or your reply policy, sends it. The answer joins the original message.