What is the strategy for determining how to request for review or feedback?

Question

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.

Answer 1

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).

Answer 2

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.