Our Software House Internal Feedback Tool: A Case Study

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.

Design challenges

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

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

#1 Navigation: How to group feedback and organise the navigation

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.

1) The first navigation proposition

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 organise it as it is typically done in an e-mail inbox: Sent and Received. Additionally, we put one extra tab: Awaiting to have an easy acces 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.

2) The second navigation proposition

Feedback is organised 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.

3) The third version of the navigation

Feedback is organised 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 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 type of action and type of message.

#2 Feedback thread layout: My feedback request as one thread of messages.

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 the each feedback request might have more than one reply to it and each of them is a separate conversation.
2. Another problem was thet a feedback request, received or sent, has been put together with a 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 details. .

The final version of the feedback thread layout that met with the most approval

#3 Anonymity: the option to send feedback anonymously.

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.

My design process

User research

The first step is to discover what motivates users to send feedback in general.

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

The second step is to ask people how they feel about the current feedback tool.

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

Ideate & Wireframe

I took into consideration all user research findings and I was ready to distinguish 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.

Test & Iterate

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 begining of the project and save our time in the future(areas of improvements #1, #2, #3).

Core tasks:

1. Describe 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.

Last but not least

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!

I also want to thank all fabulous people at inFullMobile for collaboration and help!

Cheers!

Katarzyna Urban is a UX Designer at inFullMobile, an international digital product design and development studio based in Warsaw, Poland.

Fell free to contact us: hello@infullmobile.com