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:
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 :
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:
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:
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.
Here is how we have dealt with them:
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:
To avoid such problems, we are able to assure that the users remain anonymous while sending or responding to feedback:
“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.
The survey’s results confirmed our hypothesis and personal experience with the current tool.
Problems that have been mentioned:
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).
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!