It's not uncommon for product teams to receive incomplete bug reports like below:

• “Nothing works”
• “Page doesn't load”
• “Everything crashes”
• “I don't see anything”
• “X is broken”

Avoid writing non-descriptive information like the points above ^ at all costs.

A good bug report typically follows this format:

• Title
  Try to be concise, but specific here. For example, "Broken landing page" doesn't help the reader understand whether the issue has already been reported and what exactly is wrong.
• Steps to reproduce the bug*
  It is best to try and reproduce the bug yourself before filing a bug ticket. That way you can be sure that the steps provided will lead to a bug you are reporting.
• Resulting and expected behavior
  Example: Result of operation "2x2" should be 4. In reality it is 5.
• Screen recording or screenshot*
• System information* (Operating system, browser, device, time ((including time zone))
• User ID [If relevant]
  It is usually either username or e-mail.
• Impact [If known]
  E.g. how many people are affected by the bug or how much revenue is being lost because of the bug. This helps engineers and PMs assign the correct priority.

These ^ are just some of the points taken from our How to write a bug report effectively: examples and templates, which covers best practices, examples along with copy-paste and downloadable bug report templates you can use.

* This data can be captured automatically in each bug report using birdeatsbug.com, a company I work for.