# 13A Describing a Problem Before Trying to Fix It

Yesterday I opened the course page and noticed that the topic menu was empty, although I expected several saved topics to appear.
I had been reviewing the lesson content, so the missing options interrupted the task and made it impossible to continue normally.
Before changing anything, I wrote down the page I visited, the action I took, and the result that I actually saw.
I also described the expected behavior, because an empty menu might be correct in one situation and a problem in another.
The page itself loaded successfully, but the request that should have retrieved the topics returned an error instead of the expected data.
At that point, I could distinguish the visible symptom from the particular operation that failed behind the interface.
I checked whether the issue happened again after returning to the page and whether another lesson showed the same missing options.
These observations did not explain the cause yet, but they gave the investigation a much clearer starting point than a general complaint.
When I asked for help, I included the relevant error message and avoided adding guesses that I could not support with evidence.
A clear account of what happened made the next conversation shorter and helped the other person focus on the actual failure.