As a designer working on an early-stage internal tool, Lograker, I’m eager to understand how users interact with it. The feedback collected can not only shape the visuals and interactions but also shed lights on where the technical issues are.

On the other hand, however, designers are people. As I’m designing the forms that users can submit their feedback to, there are more surveys in my inbox that I never fill out. In other words, I know that my fellow humans might not fill the surveys I design. Still, collecting their feedback is crucial to the success of the tool.

Design Challenge

Increase user feedback submission

The traditional way of including a feedback section on top of the navigation was implemented as a minimum viable solution to the feedback collection problem – All Microsoft product has this. Hence, it was assumed that the feature has good discoverability and that users would use it when encountered a problem.

The old feedback forms sit on the top navigation just like other Microsoft products

Failure

In one recent release, 9 support engineers encountered technical issues while they’re trying to use Lograker to solve a case. Nonetheless, only 1 submit feedback to report the issue.

We were lucky to be able to trace back to the other 8 users to help solve the technical issues. This incident also provide an opportunity for me to revisit the feedback collection problem.

Only 1 in 9 engineers submits a feedback form in face of technical issue.

Research

Feedback collection should be contextual and effortless

We found that most support engineers decide not to submit a feedback because they just want to focus on their job and submitting a feedback form seems like a lot of work. Worst thing worst, they can go back to the old means of solving a case, which takes up to 3 hours to solve a case or 3 times slower than using Lograker.

Understanding that our users are more passive in providing feedback, the team agreed that we need a more proactive way of asking for feedback that doesn’t disturb the support engineers while they’re trying to solve a case.

Silver Lining: Extreme Emotions

While in the research, we found that most support engineers are more passive in giving feedback and usually associate feedback giving as a barrier to getting their job done. I also noticed that support engineers tend to give feedback when they feel extreme emotions -- when they're super satisfied or disappointed with a service. That is, if we ask for feedback when support engineers need it the most, there's a higher chance of them responding to it.

Iterations

To understand how different means of asking for feedback can affect support engineers' willingness to respond, the team comes up with different ideas to evaluate the pros and cons of each approach.

Idea 1: Star-Rating Feedback

The star-rating feedback form shows up as a pop-up on the screen. This approach is preferred by the engineering manager because it's as easy and fast as one click. However, there are 3 potential issues with this approach:

1. It doesn't help the team understand what isn't working;
2. There isn't an option to close the pop-up, so it might show up at the wrong time, leading to exhausion later on;
3. Most support engineers are vendors in India or China who aspire to be converted one day, so they tend to shy away from being critical of the service FTE engineers build for them.

Idea 1: Star-rating feedback

Idea 2: Pop-up Notification

To work around the constraint of not having a data tracking system in place, I came up with a pop-up-notification-form feedback idea, which pops up when support engineers return to the page after switching between tabs, which I assume serves as a cue for task complete. This way, I hope to create a feedback collection experience that's more accurate and more strategic.

In addition, I added a button for closing the pop-up, this accommodates for cases when the feedback dialogue appears at the wrong time. If users opt to close the pop-up, it sends a push notification to the feedback tab so that support engineers have the choice to submit a feedback later on, which also increases the visability of the feedback section that sit on the top navigation.

Idea 2: Pop-up-notification-form feedback

Final Solution

I was pushed back by the engineering manager because of the extra barriars/step of giving feedback in Idea 2. However, all other engineers were convinced by my rationale. Based on the feedback, I iterated further to create more touch points for feedback-sharing.

Final solution -- More touch points for feedback

Takeaways

Best practices are not always the best solution

Designing for feedback collection is an interesting problem to solve as the answer might seem so evident on the surface that everyone thinks that they have the right answer to it.

This is also the first time I design for nudging people’s behavior, which is an area I’m super interested in. I wouldn’t have the chance to revisit the problem if it were not for Lograker’s the technical issue. Also, as the feature releases, I hope that it would shed lights on how the team can better shape the experience for the support engineers and encourage the upper management to invest more resources in UX as the product matures.