Creating Effective Partnerships Within Teams
[S] A year ago if you’d asked my what my design or research process was, I would have probably said something like “To start with, I need to understand the problem we’re trying to solve.” But with slightly more experience I realised that the first step in any design process is making sure that all your team members feel included and supported.
[M] When I first started, all I cared about was mastery of my work. I’d always talk with others about how I could grow as an individual contributor by improving my execution. I quickly learned that I was part of a much bigger picture and that it’s a collective responsibility to learn how to work with others and teach people how to work with us.
Most of the time, people want to do the right thing but poor communication and a lack of mutual understanding can get in the way. But when we communicate well, we create effective partnerships and effective partnerships create better products and make your life at work better. Between the two of us, Sophie and I have worked at a lot of places and throughout all these roles we’ve seen good collaboration and we’ve seen bad collaboration and we are still exploring the question: what does it mean to work as an effective team? Today we are going share 4 important lessons we’ve learned over the past few years about great collaboration.
1. When it comes to effective collaboration, there isn’t a 1 size fits all method
[M] If you have a set framework, a way of approaching a design problem that you go back to every time and that you know works for you, then chances are those approaches won’t work for everyone that you work with. There is also a good chance that the approach which worked perfectly for the last problem you tackled isn’t the best or even an appropriate method for the next challenge. As a researcher or designer you have to understand the problem you are solving and the people you are working with and tailor your approach to suit every new problem and environment you encounter.
[S] Figuring out these problems and especially these partnerships is an ongoing process. Figuring out together what works is always an iterative process: one where you define the problem, try a solution, communicate with your partners about what is and isn’t working for each of you and then iterate again.
While working at a previous job I was creating mockups where the copy had to fit into the designs, but the nature of the copy also heavily influenced our design decision. This meant that we had to develop both in parallel with a lot of back and forth between UX design and UX writing. At first I would upload a copy of the latest designs to our internal mockup-sharing platform, the UX writer would email me suggestions for new copy, I would add them to the designs in Sketch, export a new version, upload it to the platform, and then repeat the whole cycle. After only a couple of days we both grew frustrated of how inefficient this felt, how slowly we were moving and how it was hard to include anyone else in this conversation to get their feedback.
Next I tried sharing my Sketch file with the writer so they could test out copy directly in the designs. While they knew how to use Sketch, pretty soon they told me that they felt really uncomfortable meddling with my work. Even though I said not to worry about it, they were always worried that they were going to break something or delete important work - ultimately they just didn’t feel comfortable, they felt like they were intruding on someone else's space so, we looked for a new solution. Whenever you’re faced with these problems, you have to ask yourself “what are the most important things for this project?”. These priorities will change with every new problem you work on, so it’s important to constantly reassess. For this project, our top priorities were:
- speed of iteration
- try out many divergent options with low cost
- easily being able to comment on each other’s work
- the ability to quickly share work with and get feedback from the broader team who spanned across Sydney, Tokyo, New York, Seattle and California
In the ended the process we settled on was that I would export blank template versions of my designs and put them in Google Slides. The UX writer could then add text boxes on top of them and we could both edit the copy, try out new ideas simply by duplicating slides, add comments to every design and share it out with the whole team.
Having this level of freedom allowed us to iterate quickly without anyone feeling worried about “messing up” the designs. We had to rethink our approach multiple times until we both felt comfortable and ultimately we found one by picking a medium to share our work that lends itself to editing and commenting. We also made sure to use a common platform where we all felt comfortable. This gave design, PMs, writers and engineers across the team the feeling of being able to contribute their ideas equally as this was a shared space and not any single role’s domain.
[M] In other projects, iterating on a process could mean sitting down with other people to learn how they work. In one role of mine I was doing a lot of lengthy evaluations for clients’ websites and apps. During that time my handover process to deliver change recommendations would be me handing an engineer an 80 page .pdf file. These reports didn’t go down well with the people who had to read them - they were thorough but a pain to read, and very difficult to understand, so we had to figure out a new way to share these insights.
Instead of just handing over a report I started sitting down with engineers as a first point of contact and by doing this I was able to more effectively understand their constraints and thus more effectively communicate. It turns out that I’m not the only one who has constraints — so do the engineers. They’re dealing with archaic CRMs, their own conflicting stakeholders, and weird wacky frameworks.
When I actually sat down with them and spoke to them, rather than just handing off this report, we could understand why they did things in certain ways. I came to realise that it’s helpful to acknowledge that not only are our teams and verticals different, but so are our individual ways of learning. The times that we did sit with the engineering or content teams to share research findings we were able to learn more about each others’ problems and have a meaningful conversation.
2. When working in a team, it’s not just about how you work with others. You also need to help people understand how to most effectively work with you.
[M] Sometimes we handoff work when really we want to do is a hand-shake. Both design and research can be guilty of being a “handoff” experience, especially when there isn’t a well established culture around “hand-shakes” with iterative, continued collaboration between disciplines. One of my previous workplaces was a great example of this. We were all working towards different goals, and had no shared idea of what we were trying to achieve—no one even knew what my job as a user research really was! A PM on my team wanted to do research around a particular problem so they asked my design manager to ask me. So I asked my manager what the goals were and they said they would asked the PM, and then my design manager came back to me. After many rounds of what was essentially telephone, I handed over the research I had done and it wasn’t even close to what the PM actually wanted. This could have been easily prevented if we had just involved each other throughout the whole project and taken the time to communicate with each-other what we really needed.
[S] This story happens a lot across the industry, a similar example is when a designer hands off mockups to an engineer. During most of my previous roles a key part of my design process was inviting both front-end and backend engineers to look over some of my rough, early stage sketches so we could talk about how this these design may potentially work as a real system. Talking with them at these pre-wireframe, messy whiteboard stages when we were still trying to build a hypothesis of what might work meant that I was able to understand how my sketches would translate to real life code and what the potential technical constraints may be, which was tremendously helpful. This also let me ensure that what I was designing was actually feasible and that I wasn’t sinking countless hours into designing concepts that were fundamentally deeply technically flawed.
On the other hand including developers so early on also meant I could take full advantage of the technology we had. Often I would be designing something and a backend engineer would suggest a shortcut like a way we could pull data from somewhere else in the system to avoid having to ask users to type in extraneous information. Other times we could shave loading times in half, personalise content, auto-suggest options or even borrow UI and UX patterns from other places in the product that I didn’t know existed. Engineers, as the people who actually build these systems, often have a depth of knowledge of a particular system that you might not have insight in—especially when you’re new to a team.
[M] In most of my previous roles I was the only UX researcher and in most of those workplaces, many people had never worked with a researcher before. This lack of understanding of my role, and more broadly of how user research contributed to product development, often caused misalignment between myself and the rest of my team. At one job I had, a PM wanted me to do some research and so I asked my manager to ask the PM for a brief so I could get more context about why I’m doing this research. I received the brief and in it brief the stated the goal of the research was to …conduct research.
At first I was confused, upset, and felt like no one was trying to work with me. However I quickly realised that it was my responsibility to help the rest of my team understand how they could work with me. I had naively asked my design manager to ask the PM for a brief, thinking that they would understand what I wanted.
To fix this situation I ended up sitting down with the PMs and together we broke down their original brief so I could really understand what problem they were trying to solve. A designer on my team later told me this is called a “reverse brief”. We ended up making a standardised template for requesting user research that everyone could use. This created a framework that no only PMs but managers and designers could use when trying to communicate what they wanted to learn and what problems they were trying to solve rather than simply asking for deliverables.
3. Teamwork should be in every touchpoint of the process.
[M] Once all team members are on the same page, in order to make them feel included you need to involve stakeholders and stay transparent at all touch points. Teamwork is an ongoing relationship and you should be clearly communicating and sharing ideas throughout your entire process. It can be tempting to have a great kickoff meeting with everyone present and then just squirrels away in a corner to try and figure out solutions. This is even more true when you’re working on particularly difficult and complex problems where it feels hard to communicate to anyone else. However these complex problems are the times when more than ever, your team needs to be included in every step. Taking time to explain your thinking to others, collect their input and even just keep them informed of what’s happening are all going to help you structure and further your own thinking and help you work together more effectively later on in the project.
- Kick off with a variety of important stakeholders; review any past work that your team has done on in this area and ask “have we tried this before?”, “What do we currently know about this?” and “What do we need to test, investigate or find out in order to be successful?”
- In research this could mean identify relevant research questions together and sending study announcement to relevant teams
- In design this could mean coming to a clear consensus with the rest of your product team on what problem you’re trying to solve, what success will look like, a vision for how the user experience, product or world will be better once you’re done and a clear plan for how you can measure this.
- In user research this can mean creating a note taking template and going through this with your observers to help them talk reliable and relevant observation notes. Often you might need to teach other stakeholders how to take good observation notes, to help them help you. This could also mean inviting a broad range of stakeholders to watch user research — having PMs and engineers watch even one user study on a project can help increase their understanding and give them the framing to make meaningful contributions to the product vision.
- In design is can mean sharing out your design early and often, well before they are perfect and even before they look half-way decent. You want to make sure you’re sharing ideas, not just final products. This can often mean you’re sharing sketches or photos of a whiteboard with the team.
- For both research and design, projects aren’t just about launching but making sure your work lands. This means having a goal for every design you create and proper evaluative measures in places such as metrics or feedback channels through which you can measure your relative success at meeting this goal. These channels will help inform you iterations, future versions and even your future processes.
- In research this may look like a post-research debrief together with your stakeholders. You may also send out insight announcements to everyone who might be interested in a format that is easy to scan, gather relevant insights from and comment on.
- In design this may look like not just throwing “finished” mockups over the fence to a developer, but instead proactively checking in during development. This will allow you to iterate on aspects design as the need arises and accounting for edge cases as necessary.
Being transparent in your process means socialising your work. This is really just a fancy way of saying that a broad range of people in your broader team and company should have at least some vague idea of what your roles is and what projects your team is working on and why. This really don’t have to be fancy or difficult, in fact it often works best if it's lightweight and quick for both the sender and receiver of the knowledge. Monthly or biweekly newsletters that everyone contributes to let the rest of the team know what you’ve been up to. Storyboards, customer journeys, new designs and other artefacts can be stuck on the wall for a quick insight into what people are doing and how they work.
[S] At Google, we realised that design could sometimes appear to be a black box for those outside the UX org. Individually, designers and researchers would work with engineers but for engineers who didn’t partner directly with one of the designers, the UX process could seem somewhat mysterious. Sometimes in situations like this, opening up lines of communication can be incredibly simple. For this problem our goal was simply for others in the office to be more aware of what the design team was up to.
So in one of the main walkways next to where the team sat we hung up printed out copies of the mockups, wireframes or whatever else we were working on. In the age of emails, especially at a tech company, physically printing out mockups might sound strange. But in reality people at Google get hundreds of email a day if you don’t feel like you have anything to do with the UX org, you’re never going to go out of your way to open a slide deck of designs or a UX newsletter. By having print-outs up on the wall people who had never before talked to a designer would stop, take note, look at the designs and sometimes they’d get really excited as this was the first time they’d seen the bigger picture for the single feature that they’d been working on.
4. Making sure you’re also doing non-work work
[M] Building a team isn’t just about launches, deadlines & projects; it’s about fostering an environment of psychological safety. To make this happen you need to learn about each other, spending time with each other, and ultimately sometimes you need to spend time together not working to learn how to work together.
A great example of this from my previous job is lunch & learns which were informal, monthly talks given by a team member over lunch about topics that aren’t necessarily work related. One time the principal designer, gave a talk on Sketch. Another time, I gave a talk on my most recent university research projects because everyone knew I was going to university but had no idea I was doing in my classes. This was a just great way to get together in a relaxed environment and learn at the same time. These events were usually accompanied by a catered lunch—if you are a manager with any sort of budget, spending it on food is probably one of the best ROIs you can getting your team together and talking. Over the lunches and talks we get to know each other’s passions and hobbies and share these things we hold so dear with each-other.
One time I helped organise a hackathon at a workplace to help build rapport across different teams. This particular workplaces was really insular, where each functional role within the product team was disconnected from others. Organising a hackathon in this environment definitely presented some challenges. Initially we even had to advocate for the need for a hackathon because there was no immediate business or personal benefit. We worked hard to get people excited about participating and start thinking outside the box - some of them had never participated in a hackathon before, let alone worked outside of their functional domains. When we asked them to suggest problems to work on during the hackathon, people were coming up with made solutions. Some of these solutions were just things in the product roadmap to be made in the near future. It was hard to explain the concept of what sorts of things you could do at a hackathon because people were tied to their teams, launches, and the idea of always having to tackle large scope problems rather than dedicating a day to minor tweaks.
This included getting buy-in from the hackathon participants, many of whom had never participated in a hackathon before, let alone worked outside of their functional roles. Before the hackathon when they were ideating problems to solve, people struggled to come up with ideas. Often the ideas participants did put forward were actually just future items in their product roadmap. Because people were tied to their teams and launches it was hard to convey the concept of a hackathon and thinking beyond the everyday and working on bolder bets. People were initially afraid of the possibility that they might fail to “execute” and make something polished. We had to help them embrace the experimentative and scrappy nature of a hackathon.
The outcome was that the day was full of handshakes, hard fun work, and high fives. We had people who had never worked in a product team before doing complicated problem solving, and using problem solving frameworks like the lean business canvas. People who had never really understood what a developer’s workflow was like learned a lot about limitations and building the best thing you can build to communicate your idea. People who had always talked to each other on Slack finally got to see each other face to face. We used Airtable to distributed people based on skill sets, location, and teams to make sure that people weren’t just going into teams that were the same people they worked with every day, which resulted in diverse approaches to complex problems.
[S] If there’s one key thing to take away from this talk, it’s that teamwork means being flexible and adaptive in your approaches and actively engaging in learning how those you collaborate with work, learn and communicate. Teamwork isn’t something that magically appears, it’s the result of taking a step back and identifying where you and your colleagues can help each other.