Bridging the gap between two teams

This is a playbook relevant for UX Designers needing to collaborate with a completely different delivery team.

In today’s retail world, customers use multiple channels to interact with one company. The complexity of our digital product sometimes leads to one product consuming resources from a different product, for example, a mobile app consuming web pages. My team is in that situation, and it was critical to have some alignment between the native components of the app and the web pages, especially when these elements funnel tremendous amount of money. Problem is; it is an entirely different team that works on these web pages, and they have a different set of objectives and priorities. You have guessed it, that created an inevitable gap in the user experience.

Facing this situation, I had two choices; number one, cry and hope that someone will bridge the gap for us. Number two, take ownership of the problem and create a seamless experience with two completely different platforms and teams. I picked number two, no one told me to do this, but I saw an opportunity to bridge a gap and improve the quality of a product, so I took ownership of it. Here is the playbook I used along the way, and I hope it will be useful to you.

Step 1 – listening, asking questions, and removing fears

My first move consisted of a slight shift in my mental perception of the situation; let me explain. The dynamic of my team is different from the other team because we have different ways of working. I had to accept that the other team will not behave the same way as my team, recognising this difference automatically removed frustrations. It is a bit like going on a holiday in a different country where English is not the native language, by accepting it, you will see the trip from a different point of view and be more willing to face difficulty.

My next move was to take the time to listen to everyone perspectives on my team, so I collected comments and concerns on a design we didn’t do. The point of this exercise was to make the integration of the web pages a bit better in the app, so I needed to bring our concerns to the other team. I don’t believe that coming with problems is helpful, so on top of our comments and concerns, we created alternative solutions to discuss with the other team. As you may have guessed, not everyone on the other team was happy to see me, the outsider ready to change their existing plans.

My approach to getting these alternatives solutions across the line was simple; I listened to stakeholders from the other team in a 1:1 setting. I took the 1:1 approach because it is easier for me to build a relationship and it removes the pressure from a group. Be prepared to face all sorts conversation, it is a rollercoaster.

While collecting comments and concerns in 1:1, I sometimes heard the belief that the app will cannibalise their website, it was a surprise because it wasn’t the intent. To overcome that belief, I often repeated the vision of the mobile app and explained that we were not here to compete with them. Stating the vision and addressing underlying fears helped to make conversation safer. It was not a smooth ride, but it was definitively worth clearing the air before moving further.

A key artefact throughout the process was a diagram showing the native elements of the app, and the web pages we consume in the app. I used one colour to show the native app elements and a different colour to show the web elements we consume in the app. I used this document every time the two teams met, it was the starting point of every conversation between the two teams. Having that diagram kept the conversation focused, I often showed the diagram and said “this is the part we will discuss today, this part as a significant place on the app because (insert impact on customers here)”.

Step 2 – bring the highest level of transparency possible

Before doing any design work, we needed a plan to make sure we were accountable to ourselves, we needed milestones with deadlines and a shared goal. I proposed a high-level approach to tackle the integration of their web elements into our app and ask stakeholders on both teams to contribute to the plan; it increased buy-ins and created a sense of ownership.

Once we had a plan I started the work. I did a prototype in Axure showing the integration of their web pages into our app with the alternate solutions we discussed in the 1:1 conversation. I also regularly solicited feedback from the designer on the other team, and technical leads from both teams, to make sure I remained on the right track with the prototype.

Then I decided to bring everyone in the same room to review the prototype, and to my surprise, such exercise never happened before. The mobile app team attended design critiques of our work, but we never reviewed a design that we consumed. I can tell you that I was a bit nervous before that big review with everyone on the table, but it ended up being great thanks to these 1:1 conversation and continuous inputs from the team. I started the meeting by stating our vision again, explaining that we were not here to compete with them, and show that diagram I mentioned earlier.

Step 3 – bringing the customer lens

My team is using a dual-track agile approach, while the other team is using a waterfall/Agile approach with less face-to-face customer interactions. Because we have frequent face-to-face customer interactions, we had a hunch that there will be some remaining usability issues with the prototype; I needed to have the customer voice in the room to complete the puzzle.

A usability testing was part of the plan we created. I did the usability testing with our own research budget, in my own time, on top of my day-to-day activities. This is the key here, generously give time and resources without impacting your team. If you have to collaborate with another team, there is a good chance that at some point you will have to give something to strengthen the collaboration, there is no way around it.

After running the test, I showcased a video of customers using the prototype we made, we realised that some parts of the prototype needed more work and for the first time, the other team saw value in iterating further on the design and integrating some of our suggestions. Our shared understanding of the customers’ pain points changed the dynamic between the two teams because we had a shared goal; making the life of the customers easier. After showcasing the highlight video from the usability testing, I could see that we were aligned and that the discussion could progress with a common goal in mind. We created a new path to better integrate any web pages into the app.

Take ownership early

Do you remember the choice I had at the beginning? The “let someone else figured out” option is something I would never recommend to anyone. The real breakthrough was to make the first step, dive head first, and orchestrate a collaboration between the two teams. It was uncomfortable at the beginning, but this is what I needed to do to bridge the gap.

The moral of the story is simple; if you see something that is negatively impacting your team and your product, take a deep breath and go on an adventure to resolve the problem. If that means creating a new type of collaboration with another team that operates differently, just do it, this is where most of the fun happens.

Recap of the lessons learnt along the way

• Take ownership and orchestrate a collaboration, don’t outsource it
• Admit that teams are different, it is like going on a holiday in a different country
• Stakeholders better voice their concerns in 1:1 conversation
• Repeat the vision of your product every time you address stakeholders
• Address fears swiftly
• Invite both teams to participate when conceiving a plan with milestones and deadlines
• Generously give time and resources without impacting your team
• Bring the customer voice into the conversations when both teams are ready
• Let everyone see and take part in the work.