Empathy in Product Development – Let’s Talk Emotions!
04.04.2017 | 6 min read
Cooperation and trust are the foundation of every strong team. To build both, all team members have to understand and accept goals, trust the process, have shared vocabulary and take responsibility for their role. It’s not easy, but when you achieve it, the sky’s the limit. Here’s more about empathy in product development teams.
What had the biggest impact on my decision to switch my career from architecture to IT? The overwhelming need to work in an interdisciplinary team. I’ve always believed that a well-coordinated group is stronger than one person, even if this person is a genius. The opportunity to work with people who have different perspectives, yet still share the spirit of building a common solution, is priceless.
Two heads are better than one
People are different. It’s natural that with a different type of personality comes a different work style. I like to see teams through the lens of Belbin’s nine team roles:
- Leaders, who have the ability to see the big picture, can define priorities, locate the resources and motivate others.
- Plants, who are constantly thinking up lots of innovative ideas.
- Implementers, who need to move forward by nature, and turn all their ideas into life as quickly as possible. Chaos is their ally, but they tend to be impatient. They are doers.
- Monitor evaluators, who calmly think over every aspect of the concept, finding all the pros and cons.
- Resource investigators who can build bridges with their outgoing and straightforward manner.
- Team workers, who nurture the team, maintain a good atmosphere and help to stave off conflicts by paying attention to every team member.
- Coordinators, who need to control chaos – they are able to organise meetings and manage the process.
- Completers, who are perfectionists caring about every single detail, however, they tend to focus only on current tasks.
- Specialists, who have in-depth knowledge about specific areas critical to a project.
There is never a personality that entirely corresponds to one given type. Usually, one personality is dominant in a person, but one or two others are somewhat active too. As you can see, some personality types are conflicting, such as the Implementer and the Coordinator. However, if you remember about empathy in product development, contradicting characters become complementary and prove that two heads are better than one.
Empathy in product development
Cooperation cannot exist if team members fail to understand what the business goals are and for whom they are developing the product. When it comes to user research, I find that my responsibility is not only to collect feedback from the users and monitor their actions, but also to build the awareness and empathy in my team members. There are a few ways to do this:
It’s sad but true: no one actually has the time to look into the documentation written by designers. Speaking of empathy in product development, that’s a challenging point for many designers. The only way to update the team is to organise a meeting. Be prepared that the idea of holding meetings might be met without much enthusiasm. No one likes too many meetings in their calendar and more than none is always too many, especially for developers.
In product teams, contradicting characters become complementary and prove that two heads are better than one.
The first meeting with my team concluded with a long discussion. Everyone realised that there are real people “on the other end”, who have to deal with all the bugs and confusion. The more people reported the same request, the stronger the message was. Letting go of current tasks and a feature-centered approach isn’t easy, but it’s amazing to watch what happens when people actually do that.
My team invented the so-called Happy Points based on the feedback they received. Happy Points are derived from a number of repeated users’ requests. The more repetitions, the more points the request gets. Next to the regular Story Points in SCRUM they play a key role in defining priorities and planning sprints.
Highlighting quotes can never be as effective as showing what real users do and who they are. This is why I like to use screen recording tools. A visual example with basic info about the user strengthens the feedback and makes it more plausible.
This is also the reason why Personas are popular in product design. They are evidence-based descriptions of a typical user or target group. Archetypes with goals, concerns and needs. Personas provide solid support in building awareness in your team members. Placed somewhere where everyone can see them, they act as a reference point.
Another excellent method is to invite your team member to be an observer during usability tests. Watching a real person deal with the interface can be an eye-opener.
Put them in your users’ shoes
Informing your team members might sometimes not be enough to induce empathy in product development. People are emotionally egocentric. Their emotional state can distort their capacity for empathy, especially if other people’s situation is entirely different to their own. This is why informing and showing should be combined with putting your team’s members in users’ shoes.
It would be perfect if your team members used your product on a daily basis. When they experience the same difficulties as other users it’s more likely they will empathise. If you don’t have that luxury, at least ask one of your team members to take part in a pilot usability test. It will not only change their perspective but also help you prepare for the research.
When awareness and empathy are in place, team members are ready to build shared responsibility. This is my favourite part. I’m a strong supporter of engaging developers in the design phase as quickly as possible and keeping them active throughout the whole process. I figured out that you can reap more benefits this way.
To cut a long story short (you will find a detailed version in another post): we support each design phase by tech research. Developers put their insights on the table and assume the user’s perspective at the same time. They judge how much time the designed concepts would take to implement. We brainstorm and work out a general idea. We slice it into smaller chunks so that each chunk can be completed during one sprint. Each part meets the business goals and makes sense from the user’s perspective. As a result, design, implementation and process go hand in hand.
Each team member, as a co-author of the idea, is prepared for the planning. Everyone knows what’s going on in the backlog and feels comfortable with priorities. Estimation is easy to conduct.
One for all, all for one
Maybe this heading sounds a little lofty but working in a well-coordinated team really gives lots of satisfaction. Team spirit, synergy and fun on the one hand. Trust, professionalism and honest communication on the other. Of course, let’s not forget why we’re here. Every team exists for the sake of developing a product and the job has to be done. Yet, you decide how it will be done. Co-operation, trust and empathy in product development pay off with high performance, which will make your team achieve goals that no specialist working alone could ever achieve.