Often, when I remind people that such details help us narrow down possibilities so that we can get to a working theory and thus solution faster, I hear back, "But that's your job."
Yes it is. But as the user, you know your environment and operational context, and if the issue is not one that affects all scenarios, I may not find it because I may not do things the way you did or use the same configuration as you.
Then the ticket gets tagged "Cannot Reproduce" and essentially ignored, or it goes in the pile of tickets that will take a lot of discover -- a pile that developers seem to avoid going back to because there's always something newer to deal with.
The details add another critical component: They give the project manager and developer a finer picture that helps them come out with the best solution. Often, the issue isn't as narrow as the user's specific case. I've seen all too often developers fix a specific issue but not be aware of underlying implications that end up surfacing later, and make us all wonder "I thought we fixed that -- what happened?" No, we fixed a symptom, not the cause -- but we didn't know that.
We can't always see those underlying lurking issues even when we have the details. But we almost never can see them if we don't have the details. The finer points matter not only for discovery but also for solution engineering.
4. Don't tell us how to fix the problem
It's very useful to provide context through details. It can sometimes be useful to provide theories as to causes, as long as you have sufficient knowledge to propose reasonable theories -- you don't want to inadvertently lead the tech team on a wild goose chase that ends up delaying the fix.
You should also refrain from telling the tech team how to solve the issue. Often, there's more to the story than the user sees, and the right solution may not be so obvious. Often, users propose solutions that aren't scalable to the bigger context -- meaning other users in the system. In fact, I find that most user-proposed solutions would cause more problems than they solve.
Rather than say how to fix the problem, explain the desired result. Not only might that provide a clue as to the underlying issue, it gives the developers context to consider for the solution that they come up with.
It's really common in the issues I deal with for that extra context to help developers see a better approach than their initial solution brings. Why? Because, like you, they tend to focus on the specific issue at hand and look to solve it. If the issue is part of a larger workflow or process, it can't hurt to say, "This is doing that but should be doing this, as part of doing this larger thing. Please make sure that the larger thing isn't affected by the solution."
Sign up for Computerworld eNewsletters.