Design
February 15, 2018

Our Software House Internal Feedback Tool: A Case Study

Katarzyna Urban
UX Designer

The current tool that we use in our company to share feedback with others has stopped to fulfill our needs. It has turned out that we need more functionalities than we have now. Thus, we wanted to create a tool that meets all our requirements and is useful and entertaining at the same time.

Through this case study I discovered three areas that users struggled with the most:

  1. Navigation: How to group feedback and organize navigation.
  2. Feedback thread layout: My feedback request as one thread of messages.
  3. Anonymity: The option to send feedback anonymously.

Since each type of feedback differs slightly, it was quite problematic to order all of them in a simple way.

Feedback message types we want to include: request, spontaneous, reply, sent, and receive.

Feedback is organized as :

  • Received: all received feedback
  • Sent: all sent feedback
  • Awaiting: someone sent a feedback request and the user has not yet replied.

The first attempt at introducing the users to all types of feedback in the navigation was to organize it as it is typically done in an e-mail inbox: Sent and Received. Additionally, we put one extra tab: Awaiting to have easy access to all of the feedback requests from other colleagues.

Both the ‘Awaiting’ and the ‘Received’ tab confused the users. The former one misled the users. It was not clear to them whether the ‘Awaiting’ tab refers to the received or sent feedback requests that are waiting for the response. In the ‘Received’ tab users had a problem with My request which consists of one feedback thread with all relevant replies.

Feedback is organized as:

  • Received: feedback received spontaneously
  • Given: all sent feedback
  • My request: all sent feedback requests and their responses

In the second version, I separated the feedback thread from the feedback received spontaneously. I replaced the ‘Awaiting’ tab with ‘My request’ to make it clear that the tab refers to all sent feedback requests and their responses(feedback threads).

It was convenient and intuitive to separate feedback received spontaneously from the feedback request threads. However, keeping all ‘sent’ feedback types in one tab was misleading. Feedback request that is waiting for responses confused users — the message was received and the reply was not sent, yet it was in the ‘sent’ tab.

Feedback is organized as:

  • Get feedback: all feedback that a user received. It includes both the feedback received spontaneously in the ‘Spontaneous’ tab and the feedback request threads with all the replies to the user’s requests in the ‘My request’ tab.
  • Give feedback: all feedback that the user sent. It includes the feedback that the user sent spontaneously in the ‘Sent’ tab and the requests received from other colleagues that they have already or will reply to, located in ‘Awaiting my feedback’.

The best way to organize the navigation is to put all feedback types separately, considering both types of action and type of message.

What kind of information should be visible on the list? Should nested elements be kept on separate pages or rather inside a dropdown list? All the changes in the navigation have affected the feedback list’s layout.

  1. The biggest problem to deal with was each feedback request might have more than one reply to it and each of them is a separate conversation.
  2. Another problem was that feedback request, received or sent, has been put together with spontaneous feedback. It was really hard to visually distinguish between those two types of feedback on one page. Each type of feedback requires slightly different information put on the list.

Here is how we have dealt with them:

  • One list (with one feedback type) on one page — anything more and the users become overwhelmed.
  • The most convenient way to display feedback requests sent by the user with all replies to them is a dropdown list with nested elements. The user can view not only a request content but also how many replies it contains, what is the feedback’s outcome, its category, and date. Based on that information, users can quickly skim the list through and decide which elements they want to view in detail.
The final version of the feedback thread layout that met with the most approval

The users want to have the option to send feedback anonymously, but in some situations, there is a risk that the users are not anonymous even if they choose the option to be:

  • The first example: If I send feedback to exactly one person then I will know that the reply I receive comes from that person, even though it is sent anonymously.
  • The second example: when 4 in 5 people respond as themselves the 5th person cannot be anonymous either. The recipient can deduce who actually sends each message.

To avoid such problems, we are able to assure that the users remain anonymous while sending or responding to feedback:

  • The user has to send a feedback request to at least three people.
  • If the users receive a feedback request, they can reply to it only anonymously.
  • The user can reply to a feedback request only anonymously.
  • The user requests feedback from others only with the name.

“Job to be done” method, from this article, helped me define users’ motivations, get a better understanding of their needs, and give me the context of use.

#1 When I receive a feedback request, I want to respond to it, so I can give my colleague some advice and help him or her.

#2 When I prepare a presentation, I want to ask my audience for feedback, so I can find out if it was good or if it needs some improvement.

#3 When I receive feedback and the message is not clear to me, I want to discuss it with the people who sent it, so I can understand what they have to tell me.

#4 When I notice that my colleagues struggle with something, I want to send them feedback, so I can help them with my advice.

To do so, I sent a short survey to verify if people at our company have used the current feedback tool and find out whether they have had any problems with it.

Survey questions:

  1. Have you ever used the current feedback tool?
  2. What kind of problems did you face?
  3. How much feedback did you send?
  4. How important for you is to be anonymous?
  5. In what situations do you send feedback or would you send any if you have not done it so far?

The survey’s results confirmed our hypothesis and personal experience with the current tool.

Problems that have been mentioned:

  • Only one option available in the previous tool — giving anonymous feedback
  • Cannot discuss feedback in an anonymous conversation
  • Character limit

The most common situation that users will send feedback is when they are asked to do so.

The last step is to communicate users’ goals to all the people in a team.

Based on one on one interviews with our colleagues and survey’s results, I drafted some personas to help us understand users’ needs and to communicate research insights to everyone who is involved in the project.

I took into consideration all user research findings and I was ready to distinguish the main functionalities of the tool. Our motivation was to increase the number of sent feedback and give people an option to request feedback as well.

The first wireframes area draft of the tool’s general vision. Then, after each round of usability testing, they are updated with more details.

According to the Nielsen recommendation, I decided to conduct short user tests. Each group consisted of 4–5 participants. Most of the potential users were my coworkers and I was able to test each iteration of changes very quickly 🙂 It helped us to discover the usability problems at the beginning of the project and save our time in the future(areas of improvements #1, #2, #3).

Core tasks:

  1. Describe the layout’s elements on each page — can you tell me what kind of feedback is it? Is there something that confuses you?
  2. Try to find an appropriate functionality that allows you to give your colleagues anonymous feedback.
  3. You have received a feedback request. Where would you look to find it?

When the first group encounters a problem, we can fix it before the next round of usability testing. Often times, the resolution of one problem uncovers another one that was no apparent at first.

We are still during the implementation process and we will share with you the final version soon. If you enjoyed this case study or have any feedback, I’d love to hear from you. Thank you for reading!

Design Sprint
From a bold idea to prototype
Learn more
Written by
Katarzyna Urban
UX Designer

You may also like

Like what you read?
Get monthly business and technology insights straight to your inbox.