Manager: the web app to receive feedback from your team -Case study

Aranzazu del Castillo Figueruelo
9 min readAug 12, 2019


Feedback is essential to grow and improve in different contexts of life. When it comes from people who know you, this information is even more meaningful and has a lot of impact on one’s behavior. The performance review is a common activity in workplaces, however, it is normally oriented to employees’ evaluation.

The goal of this project was to launch a software as a service (SaaS) desktop web app for companies to use internally. It was developed in 7 days of work during my 5th and 6th week in the UX/ UI Design Bootcamp in Ironhack Barcelona.

This new tool tries to offer the companies a new way to give feedback to the managers, a task that is becoming more and more important nowadays. Employees and managers want to give and receive feedback respectively because this makes the team improve and grow. Although performance review is a common activity in many companies, manager review seems to be in a second place. Moreover, companies are relying on external software services to perform different tasks, but there is still no tool for this specific purpose.

Exploring the managers and employees’ needs

Looking for trends is a good way to identify current needs. However, to confirm that this was a real need for the companies, I decided to conduct a semi-structured interview with 3 managers from different departments and 3 employees in a big startup established in Barcelona. The interviews were done in the company so the interviewees could show me how the current tools look like and how they use them.

Research results

The research confirmed that manager review was an interesting topic for the project. It was a real need for both, the managers and the employees, and there were still no good tools for this purpose. Some managers tried to encourage their employees to give them feedback because they think it’s key to improve as a manager. To do so they mainly used e-mail, surveys and one to one meetings. The problem is that this process is slow, laborious and, for some employees, uncomfortable and intimidating.

Part of the Affinity Diagram — What do the managers do currently and how

On the one hand, the managers would like to receive information in a very visual way. They’d like to know more about what motivates their employees and what type of “working approach” they prefer. They’re worried about constructively receiving feedback because they think not everybody knows how to do it. Finally, some managers mentioned that they would love to assess themselves because it helps to track the progress.

On the other hand, the employees want to give feedback anonymously and rapidly. They’d like to find something easy to fill and if it’s possible integrated into other tools (e.g. slack). Employees want to assess not only the performance but also the values and personal skills of their managers.

In conclusion:

Managers need a way to receive consistent, visual and frequent feedback from their employees because it’s useful for them to improve”

“Employees need to give feedback to the managers in an easy to complete and free from negative consequences way because the current methods are too general and infrequent”

Comparative analysis

To take some ideas, I did a comparative analysis with two existent tools for a performance review: Bamboo HR and Master QR. Both include a dashboard that condenses a lot of information, so the user can see everything at one glance. This dashboard changes depending on who the user is and offers the user the possibility to download the information as a PDF or XML file. Another important thing about these platforms is the inclusion of profiles of the HR managers and the employees.

User persona & Scenarios

At that point in the project I had tons of information and it seemed very difficult for me to translate this into solutions and prioritize features. Defining my user persona (two in this case), the user stories, the scenarios, and the use cases helped me in this process. I also used the MoSCoW analysis to define the priorities of the project.

Next, you can see the user personas I developed for this project:

On the left, the user persona represents an employee. On the right, the user persona represents a manager.

The following are some examples of the scenarios I created for this project:

- Managers:

“Carla is the new manager of the customer care department. She wants to assess herself and keep track of her progress”.

“Carla has just received new feedback. She wants to check it”.

- Employees:

“Jan feels that her manager doesn’t take his opinions into consideration. He wants to leave her some feedback”.

“It’s the end of the semester and Jan feels very happy in the team. He wants to assess her manager and grade her performance and skills”.

Facilitating the process of giving feedback to the manager


The flow of the web app is different depending on who the user is. Let’s start with the employee, Jan:

  • Once Jan logs in the platform, he sees a dashboard from where he could do three actions: 1. Search for a manager, 2. Check the notifications, the 1 to 1 request and the last comments he has made and 3. Confirm or deny a 1 to 1 request.
  • If he searches for a manager, he can access the managers’ profile and see information about them. Once there, he can request a one to one or give them new feedback, which can be an open comment or scores in a set of skills (e.g. empathy).

Let’s move on now to the manager’s point of view.

  • When the manager, Carla, logs in the platform she also sees a dashboard. There she can check the notifications, see the members of her team, read recent comments made by her team members, check the team overview about her performance or edit the survey that the employees reply to.
  • She can also access to the team members’ profile and read information about them -e.g. the working approach that they prefer- and request a 1 to 1 meeting.
  • Finally, Carla can go to her profile, change the information that she shows and evaluate herself as a way of keeping track of her progress.

Prototype evolution

The process started in paper but moved rapidly to a mid and high-fidelity prototype. This decision was made because of the type of project. A dashboard with much different data is better represented in a digital device and in this particular case, the users’ perception changed a lot from one to another.

In this section I’d like to share some of the main challenges I faced during the prototyping phase:

Challenge nº 1: the graphs

The web app includes performance graphs because the managers wanted to have the information in a very visual way. In the beginning, I included linear graphs, but people didn’t understand their meaning. Researching a little bit, I discovered a more suitable type of graph for this subject: the radar graphs.

Linear graphs on the left, radial graphs on the right

Challenge nº 2: the language

As English is not my mother tongue and the web app was in English, I always try to test this part with the users. There were at least three words that were confusing or problematic for the testers. People understood “Open” as something “public” and “closed” as something “private”. These words were changed for “comments” and “scores”, respectively. Moreover, “One on one” was changed by “one to one”, because the first one reminded the user to a “fight”, which was exactly what I didn’t want to cause.

Navigation bar with the previous names

Challenge nº 3: the quantity of information

In the beginning, I started with very little information on each screen. The users needed to do several clicks to arrive at some specific sections and this was annoying for some of them. They wanted to access the information at one glance, and they were not worried about having a denser dashboard because they were used to work with a lot of data.

On the left, the first prototype with very little information. On the right, final prototype with a denser dashboard.

Challenge nº 4: the selection of useful information

The mid and high-fidelity prototype helped me to select the information and elements that were important in each section of the app. For example, nobody considered the “checkboxes” important in the “recent comments” or “1 to 1 requests” section. They said that they wouldn’t like to delete the messages. However, they expected to have information about the date, points to discuss and points for the next meeting in the “1 to 1 request” section.

“1 to 1” section on the left, and “recent feedback” on the right.

Challenge nº 5: the color selection

Once the structure and the content were clear I focused my work on the selection of the color palette. Some of the values I wanted to inspire in the user were: accessibility, transparency, honesty, and youth. Based on them, I developed the following style tile:

Style tile showing the color palette and the typography.


This project has been developed in 7 days, but it’s still active because as a designer I have some long-term goals with it.

In 3 months, I would like to include the possibility of setting reminders. This feature would be used by the managers as a way to encourage the employees to give them feedback. I’d also like to include information about the skills (empathy, support, etc.) that are displayed in the graph and the number of people that have voted for them.

In 6 months, my goal is to include ways to compare your performance as a manager with other managers (benchmarking) and integrate the “employee performance review” in this same web app. Finally, it’d be also good to simplify the flow of some parts of the app, reducing the numbers of clicks the user has to do to arrive at a result (e.g. when the employee wants to give feedback).


This has been my first project with a real company as a UX/UI designer. This has given to me an incredible experience and a strong opportunity to improve my researching and testing skills in a very real context. I want to thank TravelPerk for the support and collaboration in this project. Without it, this would haven’t been possible.

It has been a challenging project because of the length and different versions of the workflow. This has taught me something very important: the need to focus and prioritize even more! Trying to cover everything only takes you to less detailed work. For future projects, I’d like to think better about these priorities and set realistic goals depending on the time that I have.

Let me finish this post with some additional learnings:

  • I would also like to take more time for inspiration, avoiding jumping to fast into the visual design.
  • I’d like to start using more symbols and organizing my sketch file, because is a good practice, especially If I need to collaborate with a web developer.
  • I’d like to continue working with user stories, use cases, and the MoSCoW analysis because it helped me in this project.

Thank you reader, I hope you liked the post :) Drop me a line if you have any doubt or want to say hello!