5

We often get feedback like : "it's not working" through our "Submit a Problem" form.

I'd like to gently encourage the user to tell us:

  1. I did ...
  2. And expected ...
  3. but this happened...

I'm considering 3 text boxes with the prefixes for the above (sort of Question : [ answer ] style)

Update

We already capture a screenshot (of the app only, it's in a web browser so we can only see our web page, no confidential info) And we collect their machine specs.

Proposed solution: 1. Give them an option to mark on the screenshot where the problem is. (Although, honestly, this is software for folks with brain injuries so the screens are extremely simple)

  1. enter image description here

Note that the Short Title is shown only if they have a long description and only AFTER they fill out the longer textbox. I included the "We will reply to" b/c we already have their email (from their login) BUT often it is a healthcare worker helping a patient so they may want us to reply to THEM not the "account holder"

Is there a best practice for this problem?

Improve this question

8 Answers 8

Reset to default
1

You can modify the standard 'User Story' UI into a 'Report a Problem' UI, it goes like this:

enter image description here

UI Credits: http://sprint.ly

Improve this answer
1

Adding more input field to the form makes it look more complex and therefor less likely to be filled out by the user (especially if there is nothing left to do for them). What you could try is to be descriptive with the placeholder-text. Describe to them what you'd like to know. Than it's up to the user how he wants to give feedback.

Besides that, there can be other information important for developers like operating system and browser. This so called user agent information can be retrieved from the user (here is an example: http://www.thismachine.info/). For every time there is is an error or the user fills out the form, it could be handy to send this information with it.

Improve this answer
2
  • Yeah, we get all that info already and submit it "behind the scenes", which is why I didn't mention it.
    – Clay Nichols
    Aug 10, 2014 at 0:54
  • I think the mock-up in your update makes sense. To be honest, i don't really see a reason for the title: i think you can remove that. I like what you did with the text input area. The space the user has for text seems sufficient. Maybe you could give the text above the text field some thought. Start with asking the user what he was expecting, because this is the most relevant for the user and therefor probably the thing he is most willing to give information about. The question 'what were you doing' can be hard to answer sometimes/can be interpreted in different ways.
    – Ruudt
    Aug 10, 2014 at 2:22
0

There is no "best practice" as far as I know. I think you're on the right path. Try it and see what happens. It won't be a cure-all, but it should help.

Improve this answer
0

Call me cynical, but most users won't go beyond "It doesn't work" unless there's some tangible reward.

Diagnosing the problem is your job, not the user's. Users either don't know that they could be more helpful (ie, they assume you'll figure it out anyway) or they just don't want put in the effort.

Improve this answer
2
  • 2
    Normally I would agree with you and state that users would just leave the site if they encounter a problem they can't solve. But the fact that users use the "Submit a problem" form for telling them the site is not working, challenge this notion. Maybe it's just worth a try. Besides, it's not that much effort.
    – Ruudt
    Aug 6, 2014 at 6:59
  • Some (5% or so ) of our users tend to care about the application enough to give feedback. So I'm trying to make it as easy as possible for them (while encouraging more than "it's broke"
    – Clay Nichols
    Aug 10, 2014 at 0:58
0

You might consider recording the number of bugs identified by users and implementing a badging type system much like StackExchange.

For example...if a user reports a bug that's new and unique (requires an actual fix) that user's status increases. If the bug actually gets fixed that adds some other status to the user's account.

This way the user sees how their feedback helps and you add some exclusivity to providing good feedback.

Improve this answer
1
  • A better (*and easier ) solution is to just actually REPLY to everyone who provide feedback. That way they realize that we are listening. People are more motivated by Intrinsic Rewards than Extrinsic Badges. (SO badges work (but only for some folks) b/c they provide *peer validation*( which is intrinsic. However, no one will see these badges but that user.
    – Clay Nichols
    Aug 10, 2014 at 1:13
0

You have to understand 2 things here

Problem

  • As a User, I don't have much time. The fact that I am letting you know about the bug is a big favor. Dont expect me to do too much typing.
  • As a developer, I expect details of the bug so that I can understand it better & fix it.

Now you have to strike a balance between these two. I would suggest the following way.

Possible Method

  1. (Mandatory) Serve the User just 1 textarea & allow him/her to describe the problem in his own natural language.
  2. (Mandatory) You can automatically capture the screenshot of the page alongwith other details like Browser/Device/Location etc.
  3. (Optional) From the above screenshot taken, you can ask the user to mark the area of problem.

Cons of this method:

  • Since you have taken the screenshot directly without User's permission, there are chances that there was some personal data of the user on that page. You might want to allow the User to blur out those areas
  • This is a bit difficult to implement but completely possible

Example

The classic example of this is Google Plus. On their menu they have a feedback option & it works the same way.

I would love to hear more creative ways to OP's problem :)

Improve this answer
1
  • 1
    "Since you have taken the screenshot directly without User's permission" <-- Just don't take it automatically. Always let the user decide to add a screenshot or not ("UserVoice" has a checkbox that can be checked to send a screenshot with the message). At my work, we develop an accounting/billing software. So far, most of our clients have no big deal sending us screenshots without blurred accounting values and so on (and they are germans!!)
    – Alexej Froehlich
    Aug 6, 2014 at 9:50
0

I like where you are going with the pre filled answers but I'd go with a different approach:

First, I would somehow track the last few pages that they were visiting before coming to the help center, if possible.

Then, I would gather as much information as possible from the browser/device (OS, screen size, account info, language, etc.)

Finally, prefill ONE text box with your different sections. 

What you were doing:

What you expected:

What happened instead:

This allows users to delete the prefilled text if necessary, but encourages them to fill it in if their problem fits that structure.

Making three separate boxes forces users to try to shoehorn their problems in to the different sections - they'll likely give up if it's annoying to do so.

Improve this answer
2
  • 1
    Suggestion: Put this as one Text either as placeholder or in a subline above the textarea. That way, the user doesn't even have to delete something and feels even less obligated.
    – Alexej Froehlich
    Aug 6, 2014 at 9:54
  • We do track the exact part of the app they are in and take a screen shot. We already do what you're suggesting, but nobody fills in the text after each statement. So I think that we don't need to repeat it twice. And as @AlexejFroehlich notes, this creates extra work for them to delete stuff.
    – Clay Nichols
    Aug 10, 2014 at 1:16
0

This is a tricky problem that many of us have had to face at one point or another.

The problem arises from the users being unaware of the benefits of good issue reporting, and being unmotivated to bend over backward to help you when (presumably) the tool you built just failed to help them when they needed it to.

There are a lot of great lessons to be learnt from the desktop crash reporting world on this topic.

  1. Try to intercept a broken action when and where it happens (e.g. In your 404 page template, your form validation template, etc., add a "report bug" button, and pass through details of the current page, request and response). This prevents the user from needing to describe what went wrong, and in theory gives you a big chunk of new diagnostic data automatically with very little work from the user.

  2. Capture a trace of the user's actions that can be (optionally) appended to the issue report. This can be tricky on the web but even if you're just logging the actions attempted by each user by timestamp, you can correlate the issue report with the kind of function the user was trying to perform. Doubly useful if you log failed requests. You can also send through user agent details etc. (ideally with the user's consent) to help identify browser issues.

  3. Don't expect users to know how to take a screenshot. It's a complex action on most major platforms. Don't make it a requirement of an issue report.

  4. I've had some success asking for a title and a description of the issue separately. It seems (anecdotally) that my users are used to writing meaningful subject lines on emails, and so do the same for issue reporting even if the description is a bit thin.

  5. Prefill the description text area with a template for a good issue report.

    I think I have found a bug. Whenever I try to…

    What happens is…

    I expected it to…

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.