3

It seems like there are a number of different factors that need to be considered when requesting user input/interaction that has no immediate benefit to them, or if seen as interrupting their workflow.

I can think of some of these factors, but I am curious about what combination works best and whether it varies depending on the type of application or device they are operating:

  • Interaction: Whether it is revealed on a page or as a pop-up
  • Timing: At the beginning, middle or end of a task
  • Message: Phrasing it as a request or suggestion
  • Tone: polite, fun or neutral
  • Design: plain and basic with the ratings control incorporated, just a link text

Some other context I can think of are the type of application they are using (games or work), whether it is an Android or iOS app, whether it is linked to an incentive (such as feature unlock), but I don't know if there are any standard guidelines to how to combine these factors for the different context of usage.

2

When our sales people asked for a feedback mechanism in our TV app to determine our net promoter score, we went through this thought process as well. We identified a few objectives:

  1. Don't interrupt anything the user might be doing at the moment.
  2. Make it trivial to click away/ignore for users that are annoyed.
  3. Be concise, short and polite.
  4. Don't produce a "door slam" by showing up too early (we decided to show it randomly, but at most once in 6 months, and not within the first 6 months of use, so the user has had some time to form an opinion of our app)
  5. Provide some (indirect, minimal) value to the user. In our case, that was a comment field that allowed for free-form feedback, which went to support.

As examples, we never show this window in fullscreen (because it's likely that the user would be watching TV from the couch), I think we don't even show it if a TV window is open and playing back. It is a non-modal window, which allows all other functions in the app to continue uninterrupted (e.g. scheduled recordings). And we check for mouse/keyboard etc. user activity and only show this survey window when the user's been idle for a while, with our application frontmost.

The window has both OK/cancel buttons and a close box, so people can just close or hit the keyboard shortcut to get rid of the window without hassle, keeping the annoyance to a minimum for those people it still annoys.

The advantage of the freeform field was that we got honest replies from users, e.g. where some channel assignments had changed or reception problems were happening in some locales, which we found out about way earlier this way, and managed to fix for most people weeks before we'd usually have become aware of these issues through the usual channels.

So be aware that the default effect of all survey windows is to annoy the user, and actively engineer against that. If you're on the web, you can't necessarily measure user activity, but you can e.g. do something similar by placing your survey at the end of an operation instead of before, and make it easy to ignore (e.g. by keeping the navigation and some useful information around it, so users can continue their work without interruption).

1

A lot of your bullet point depend on the design and intention of the website or app. Like for instance "interaction: revealed on a page or as a pop-up". This depends on the design. Is there room for a feedback form or a label that will take people to a feedback form. The same goes for design.

The message and tone of the feedback request depends on the intention of your website or app. Maybe a nonchalant or airy tone might work for your users. I could see this work in a game or in a calendar app where people are more intimately involved with the application. Opposite of that are for example government related applications. In those types of apps it's important to stay formal.

The biggest point however is timing.
Here is excellent article, from just a few days back, about the right timing to ask for feedback.

The clue of the article is not to ask feedback when people just open the application or website. People haven't got to know it and can't judge as of yet. This might result in a bad review or frustrated users.
Don't ask for feedback when the user is in the middle of something, like when they're composing a tweet or busy ordering a product from your webstore. This also might result in a bad review.
Asking for feedback when the task is done seems to be the only option left, but there is more to consider. When the tasks are small, like composing tweets, don't ask for feedback after the first tweet. It will hardly give people the time for getting to know the application. Ask them after an X amount of tweets. When the task is bigger, like ordering something from your webstore, people already have visited quite a fair bit of your website. It's quite safe to ask about their experience.

So ask for feedback after a certain milestone is reached and ask it in a way that suits your website or application.

  • Mostly agree, though I don't think anything but a neutral tone is a good idea. E.g. Git Tower has a "Tower is feeling a little tipsy" alert when it runs into an internal error. It's easily the most annoying, infuriating thing about the application. "Bad enough it crashes, but they also wasted time being 'funny' instead of fixing this". Even better Star Trek online, which literally gives you a "Cryptic Error" (apparently one of their internal engines is called 'Cryptic'). But maybe I just lack humor :-) – uliwitness Jul 2 '14 at 8:37
  • @uliwitness humor requires timing and developers often lack that, I agree. But saying "something went wrong, sorry, we are doing our best to fix this" is always better than "an error occured, if this problem persists please contact your administrator". A nonchalant tone in languages other than english can also mean the way you address people. You have 'you' for elderly people, people of stature or people you don't know. And you have 'you' for people you do know on a more personal level. So nonchalant and airy doesn't necessarily mean funny, because like you said, it can easily be misplaced. – Paul van den Dool Jul 2 '14 at 9:15
  • I agree that the strategy depends on the context, so I was looking for some examples of good (or bad) combinations. It is not something that I have been asked to implement very often so there isn't a lot of reference to draw on other than project examples. – Michael Lai Jul 2 '14 at 22:20
  • @MichaelLai If you're looking for good examples of "funny" copy I recommend scrolling through LittleBigDetails. – Paul van den Dool Jul 3 '14 at 7:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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