The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
I am a web developer and I often get emailed with bugs that need fixing or for new features.
For example I may get an email saying something along the lines of:
on page X it doesn’t jump to the respective field, you need to scroll down the page
But the page in question could have multiple fields.
The problem is that the people emailing these issues are usually quite vague and I never really know the best way to get them to clarify what it is they're asking.
You know that you will have to ask several questions, and you do not know all the questions from the start.
Having this in mind, contact them saying/writing: "In order to help you and solve the issue, I will need to get in contact with you and ask you some questions and try some things. Could you give me a time slot of about 10-15 minutes in which I can call you?"
This way the person is prepared that this will take some time. And they can decide when this will happen. So as a result they are far more relaxed and willing to answer your questions.
Issue tracking systems are almost never configured in a way that is usable for actual end-users. They're too long, too complex, and there are usually too many fields asking for information that end-users don't have easy access to. It is possible to set-up an issue tracker that STARTS with simple user-centric entry forms which then snowballs into more complete forms that only developers can see and edit.
Unfortunately that is a long and difficult project in itself. As an example, in my workplace, the IT helpticket system has a dropdown which lists literally hundreds of internal applications/systems. Many of these are named in a confusing way that only makes sense to the people managing these systems. Multiple items seem like they're the right thing but have cryptic prefixes that makes one wonder if they've selected the right item or not. As a result, folks have learned to just select "OTHER" and just describe the application which has a problem. My workplace's issue tracker is actually very good, others that I've seen are filled with mandatory fields, nothing named "OTHER", and no way to just provide a simple description of the problem.
Asking for screenshots is totally reasonable, but keep in mind that many people simply never take screenshots because they don't know how, nor do they necessarily know how to attach a screenshot to an email or a web form. It might be hard to believe, but it's true. If you ask for screenshots, you have to show people HOW to do it and HOW to attach it-- down to the keystrokes.
The best thing you can do is to be responsive to users when you get a vague issue report. Respond back with what information you need and provide a link to your CMS that shows examples of good issue reports (as well as stuff like how to take/send a screenshot). Instead of taking a tone of rejection, take a tone that demonstrates a willingness to help. Configure your issue tracker to not respond with words like "INVALID" or "REJECTED", those might be fine for internal developer work, but to end-users who are having problems, they're utterly rude.
Finally, you will find that there are always some users who are willing to go above and beyond in reporting issues. I call these "alpha-users". Some of these users may be willing to act as an intermediary that can help others to file issue reports in a way that's usable for you. If your scale is such that you can reach out to these people you can "enlist" them to help out-- it's something that they often enjoy and it spreads good practices much faster than a stern policy or persnickety issue tracking systems.
Followup questions from management:
Tfish, why isn't feature X done on the website; we really need that for Black Friday promotions in four days time?
Why are you working on / thinking about feature Y (an emailed request that "can you just quickly...") when we all agreed feature Z was far more urgent?
You need to start getting much more assertive, or your problems are going to cause you to loss of sleep, money, time and professional reputation.
You have the issue tracker in place; escalate to your line manager that people are bypassing it and making direct requests. Politely ask that you're allowed to remind them to use it. If it's an external customer, as your company's account manager to do this.
For some users, you can probably soften that to "Please attach screenshots to the issue tracker ticket" or even "What's the ticket number".
Your response should be "I'm only allowed to work on tasks given to me by [line manager]. Please use the support tool". If its a followup email asking for progress update, forward to your line manager.
The above will take weeks/months; you need to be patient and most importantly depends on support from management.
If management has said "just deal with it (it won't take long)" - do what you're told. Skip to the Time Tracking section below.
There will often be occasions (certainly initially) where you have to drop what you're doing an react, maybe for political or financial reasons. That's fine. Just follow the process yourself. Create a new ticket and fill it in, assigned to yourself. If you need more info, email, including the ticket number:
"Hey Mary, I've opened a support ticket 12345 for X which you asked me about, but I need you to send some screenshots. Please can you attach them to the ticket or email them to me and I'll do it."
It's probably worth saving these to reuse as templates.
Time Tracking
Finally - most importantly - keep a really detailed track of the time you spend working on things and especially
If the issue tracker doesn't do this, keep it in a spreadsheet (make sure you have backups). You can use this to send your line manager a weekly summary. If you're spending 60% of your work time on allocated tasks 20% on support work and 20% on admin, they will really want to fix this.
If the bug report comes from QA, you might complain to QA. It's their job to create bug reports that allow you to fix the problem with minimal effort, and they should know how to fill in the right information. They may have a new inexperienced team member, or sometimes there are problems that come up totally unexpected, in that case it's more difficult.
If this comes from a customer, it's about the best you can expect. Customers are not experienced bug reporters. (Ok, if one of our devs or QA uses a third party product, uses as a customer and not tests, that company may be lucky and get a perfect bug report). You live with it and do your best; if you are lucky you can pass it to QA and ask them to test that area and get a good bug report.
The premise of the question is false because in the first place there is nothing impolite about asking to clarify.
There are multiple fields on page X. Which one do you mean?
Is already sufficiently polite.
In general, bug reports should contain reproduction steps, expected behavior and observed behavior. The bug is hopeless until all three of these are known. If they are not known, your first reaction should be to ask for those which are left out.
