Background
From failure grows opportunity. This research project had not so positive roots as it grew out of a failed feature development where miscommunication between the Product and Engineering caused a mess of a workflow. The failure to communicate customer needs to the rest of the team resulted in a add-on that later had to be pulled back as it ended up solving a problem that simply was not there.
Seeing the wasted time and drop in motivation, I embarked on a journey to improve communication between different stakeholders of different backgrounds and explore the common pain points a tech company faces.
The overall research took a few months and consisted of some interviews, two workshops and a lot of teambuilding (it's always more fun to discuss things over a beer). The "testing ground" for my findings was a high-priority project for building a money-laundering risk re-assessment feature developed for Penneo KYC.
Pain Points
(These are some findings from interviews and feedback from various team members)
- Little understanding of WHY something was being built
- Limited time to understand the project's background - no time to read extensive documentation
- Developers not communicating directly with customers - always having a middle-man
- Insufficient way of presenting customers' needs and motivations
- Project not visualized in a human manner
- Lacking resolution strategy - not clear from the beginning who works on what
Communicating between two "Guilds" - Engineering & Product
Engineers
For understanding the engineering POV I conducted a few interviews with different developers across two teams. The conversations happened in an informal manner and were judgement-free, where feedback, even negative, was encouraged. I talked with engineers not only from my close team but also other product teams across the company.
Main findings were as follows:
- Sometimes hard to understand what the Product team wants them to build
- Feeling very far from the actual customer
- Designers tend to be very productive with their designs - hard to give feedback
- A project should be something that is shared not that comes from top down
Product
With the Product team I went with a different approach - a workshop where the participants could not only explore the pain points from their perspective but also try to understand where the previous feedback from the engineering team could stem from.
It is important to note that the workshop participants all came from different product teams. Read more about the workshop below.
Rihla - PM/UX perspective workshop
Time to write your Rihla*
* Rihla - An Arabic word for a journey or the documentation of it.
For the PM/UX overview I decided to engage in some group fiction writing in a speculative design workshop. Since dealing with a potentially sensitive subject, this approach helped the participants to hopefully step out of their everyday lives and approach the topic in a more creative and round-the-corner way.
The participants were asked to embark on a journey across new landscapes - visit the lands of designers, product managers and engineers - and document their journeys in their own personal notebooks for people back home who could not join you.
Overall there were four goals:
- Describe the place you just arrived: How is the architecture? How does society work?
- Describe the people: Who are they? How do they live? How do they party?
- Advise diplomacy: How is their communication style? What are the main pain points?
- Create a visual entry with pictures to take back home (included props).
Main takeaways
Not surprisingly, the communication problems obviously had roots from both sides. The main difference between the "people" was mostly about attitude and "language" spoken: a person from a different background (engineers) could have a fundementally different understanding of what is required. An idea, completely clear in the minds of Product could be perceived in a distorted way by an engineer.
A lot of talk involved around using "translators" - those being tools like Figma, Miro, etc. that would help bridge the communication gap. Involving engineers early in user research, inviting them to participate in meetings, etc. was also seen as a positive measure for team collaboration.
Besides communication, overall undersandment of each others roles (and sometimes even disrespect) was brought up as an issue. Unfortunately, especially towards the Designer role. However, again, bringing the engineering team closer to users was seen as a counter-measure against this problem.
An example of one "Rihla" made by one of the participants.
The Heist - Internal team workshop
The final workshop was an internal workshop within my own team, co-created with the engineering lead. While the overall research targeted the whole company, it made sense for me to bring the finale back to my own home grounds.
The workshop itself was built around the idea of a heist - the team had to work together to steal a jewel, exploring opportunities and challenges on the way. The overall goal was to of course reflect back to my previous findings and the hypothesis of improvements I had created. It was also a great opportunity to check the overall health status of the team.
Exercise 1 - "Know Your Casualty" (KYC)
In the first part of the exercise we aimed to discuss our customers’ needs and motivations: what we know, what we don’t know and what we want to find out about more. This helped us understand more about the team’s motivations and areas of interest regarding our customers, but also what is communicated well and what is not.
The second part of the exercise moved back to the familiar topic - PM/UX communication with engineers and potential improvements.
Main results
- Engineers would also like to be closer to the customers
- More usage of Miro, user flows, etc. , please
- Regular feedback loops are a must
- It's hard to synchronize excpectations
- Sometimes it feels like too much is expected
Overall, the previously mentioned hypothesis of better team engagement throughout the project was something that the team themselves put emphasis on. Sitting in on customer interviews, asking for feedback during project work and generally observing how the users interact with the product were all mentioned in high regard. User flows and other similar tools were also said to be helpful understanding user perspective.
Exercise 2 - Trust Your Team
In the second part the participants were given a map of the jewel's location with multiple enterence points. They were then asked to make use of the team's skill to steal the target as a warmup exercise.
Fom there on we moved the focus more towards the team members - evaluate yourself and your position. Answer these questions by drawing the answers:
- What can I bring to this team?
- What does the team expect from me?
- What do I expect from the team?
- What are the expectations for us from the company?
Finish the exercise by evaluating the tools you have for the heist - what is our protection against "getting caught" - loss of morale, potential issues, etc.?
Main results
- Main expectations for oneself: provide high quality work and be a good team member
- Team activities are very important: one should be friends with their team members (play foosball together, for example)
- The role of social gatherings is high
- Negative feelings mostly connected to high demand and unexpected problems
When it came to team work and self-positioning oneself within it two clear themes emerged: providing value and the social aspect of a group. It was clear that everyone’s contribution should be valuable and of high-quality, as it affects not only other’s work but also the overall customer satisfaction, that is regarded highly.
Another important aspect was the social dynamics of a group. Having good relations with your teammates is something that was considered very important. Not only does that create a good and comfortable environment to work in, it also eases the overall communication between different members, making it easier to review each other’s work and provide feedback/help.
Overall conclusion (short version)
What to pay attention to during a feature development?
The most outstanding aspect of this research was the importance of collectively understanding the user needs and motivations when working on a product. This understanding influenced not only the quality of work but also the team members motivation to continue with the project and overall outlook of their job.
So how do we ensure that every team member has a good level of understanding the users needs?
1. Involve engineers (and other stakeholders) from early on
It is tempting to work in a bubble of PM/UX, do your research, create prototypes and do handovers, but design should be a collective action - harvest the knowledge of people with skills different from your own, they might see something you have missed. This approach involves low-fidelity prototypes, creating scenarios, motivation maps or just regular discussions where people feel free to express their opinions. Involving a backend engineer in a brainstorming session can help uncover paths others might not think of.
2. Involve engineers in user interviews
Having a middleman creates distance, which leads to lower engagement with user needs and, inevitably, loss in motivation. In the “test” project during this project (Risk re-assessment) both the PM and the designer ensured at least one engineer was present during user meetings so they could hear first-hand what the client expected to be delivered.
3. Use “translators” to bridge perspective gaps
It can be hard for people from different professional backgrounds to sometimes understand the other side’s perspective. It might seem “they” speak a different language - what seems obvious for one side sounds gibberish to the other. In order to combat that, luckily, we have our hands on a number of “translator tools” - these tools involve user flows, Figma prototypes, and even just presentations, where the motivation for choices made by the PM/UX are explained. From the other side of this conversation (engineers) the “translators” deal more with translating code to something tangible - storybook, testing in staging, etc.
4. Tell a story
Storytelling could be considered one of the “translator tools” and as every good story it has characters with wants and fears, not to mention a goal to reach. Storytelling makes your research more human, it engages the audience to understand what is happening, and most importantly - why it’s happening.
As with every great story, it should be told in an interesting way. Using humor or ludic details can help make people listen and actually contribute more to the conversation. It can also help overcome shyness or other social restriction that can arise from some personality types. Using props, whether digital or physical, can also increase engagement.
5. Loop back
Even though often idealistic, it is still a good idea to loop your team’s decisions during development phase back to your customers. This is of course unrealistic for every small change made to the so-called “original” design, however, when relating this to the topic at hand, it can, besides making sure the project develops on the right path, prevent the potential lack of motivation among the team. It is hard to find a more unmotivating situation than where you find your previous work is completely irrelevant.
Other important factors (also trying to be short)
6. Respect for each other’s perspective
This project did not focus too much on difficult group dynamics among people with different backgrounds because that was never perceived a problem within my own team. However, while conducting my research, it tended to unfortunately come up. From the little knowledge I managed to gather, it seemed to stem from the same problem - not really understanding why your team member of a different professional background had made certain decisions. Hence the proposals above might ease the pain of this specific problem as well.
7. Have a strong team culture
As cheesy as it might sound, the people who we trust to share our emotions with are also people we tend to like working with. Having a strong community among your peers was by many a factor brought up when talking about expectations within the team and valued highly. Hence, a strong outside-work culture is something that should be encouraged.
8. Vent, but don’t overfocus on the negative
Venting at workplace is completely normal phenomenon that one shouldn’t be ashamed of. In fact it can actually be therapeutic. Being able to vent to your co-worker about an irritating situation at work can help relieve pressure and feel more positive as a result. It can create a sense of community, especially when the situation is relatable and has also irritated the other person, help people feel supported and heard. However, just as with everything, venting needs to happen in moderation. It is a risk that it becomes overly negative in which case the result will not be relief but rather dread and negative outlook of others and the workplace. Some examples on how to make your venting sessions be pressure-relieving, not only completely negative:
- Listen and be supportive
- Vent in a structured manner: Agree that there is a place to express negative emotions but end with a constructive, more positive, note: yes, the situation is not ideal, but what can be done to improve it?
- Don’t fall into gossip
- Follow up: Check in on the situation with your co-workers, especially after discussing potential solutions.
