In conversation with Mo: What it’s like doing research as a Product Designer
In my previous article, I wrote a Guide to User Research for UX Designers. Here, I wanted to see how user research is done in a real context.
I had the privilege and pleasure of sitting down and chatting with Mo Bashagha, a Product Designer working at Facebook. Mo previously worked at TransferWise, Apple + IBM and IBM iX.
I was interested in finding out about his experience designing at TransferWise, a fast growing technology startup that lets its customers transfer money abroad quickly and easily.
Here’s a transcript of the conversation we had:
Mona: How did you find the experience of working as a Product Designer at a startup like TransferWise?
Mo: Empowering. Product designers had a lot of responsibility. As a product designer you had a lot of power to influence the direction of the product. You can nurture ideas, your own or your teammates, and communicate them in a way to win over the team. Getting those ideas on a roadmap and actually have them built. I think that’s the good part.
TransferWise is a fast growing company, so there were many areas of opportunities for you to go out and be fairly entrepreneurial. For instance, we’d be addressing one part of the market but then there’s also a completely different part of the market that we’re not addressing. You could send out a survey to 200 people and find out their use patterns and try to identify opportunities in your current product based off of that. As a product designer, you have the skills to make a difference in the company. You might be only a small part, but you’re big enough to have an impact.
Mona: Were you the only designer on the team?
Mo: I joined TransferWise when it was already a very successful company of about 500 people at the time. There were 7 product designers at the time.
Mona: Was that 7 product designers across the entire company or within your team?
Mo: Over the entire company. If you think about the surfaces we looked after — web, iOS, Android and everything from the account page to transfer flows to everything else that’s going such as the help experience… I guess its a fairly wide remit.
Mona: That’s incredible. What were some of the challenges doing research as a product designer there?
Mo: Product designers were mostly responsible for their own research. We had one researcher who acted more as the center of competences… if I was going to send out a survey, I would write the survey, book in some time with her and get her to review it. If I was going to run usability testing, I would write a test plan, review the plan with her and then go and conduct the testing myself. It was more of a sense check to make sure I wasn’t asking leading questions or doing anything incorrectly. But overall, one person cannot scale to do research for the entire company so product designers really had to own their research.
One part of me thinks that yes, it’s brilliant for designers to do research because you’re engaged and being thoughtful about how you’re designing and how you think about the problem. But I also know I’m not doing the best job of research so you definitely have gaps. It’s like trying to hack together a profession in the same way that other companies get product designers to write the content. Yes, I’m sure plenty of product designers are fairly good writers but realistically they’re not going to do as good of a job as a content strategist, they’re not going to be thinking about tone of voice in the same way and make sure there is consistency across the entire product.
Mona: As one of the very few designers in the company and to have to do research on top of design, how did you juggle that? How did you get buy in from your team to do research?
Mo: Thankfully for me it didn’t take much… sometimes I did have to push back on the team, actually show them the research and make sure they did not push ahead and go build something. I think the easiest way to get buy in was just to go and do it. But bring your team on that journey. Share why you’re doing research and what you’re going to do. If you’re doing testing you get the team to attend as many sessions as you can but for those who don’t make it, show them the learnings during weekly team meetings. During those meetings, spend 10–15 minutes running through the tests and don’t just talk them through a slide deck with lots of words. Show them video clips or quotes from real people talking about the things the team has already built. As soon as you show real people struggling with something or being delighted, that really has an impact for someone on the team whereas before that everything they were doing was fairly abstract.
“I think the easiest way to get buy in [from the team] was just to go and do [the research].”
Mona: So getting them to understand how real users are being impacted by their work.
Mo: Yeah, exactly. And you don’t have to pay a huge subscription to usertesting.com to get going. You can do whatever research you can do. Often if you’re working on a product that already has an existing customer base, just reach out to customers and do interviews. If you can record audio or video and feed that back to the team, that removes blockers for future work that you want to do. In the same way, surveys are pretty cheap to do.
Mona: What were some frustrations or difficulties? What didn’t go as well as you would have liked?
Mo: Especially with in person research sessions, there’s a fair bit of overhead… you’re doing all the upfront research, the design work, you’re trying to build prototypes and also trying to recruit for users. Recruiting for participants for user testing and people dropping out. Arranging sessions, gift cards etc takes a fair amount of work and lead time as well. And if you’re working with agencies to recruit, which we did. If you’re not on top of your planning, which is what I quite like to do, you’d have to wait 2–3 weeks before you can even conduct the sessions and if your team is eager to get going right away then it can feel like a blocker. That can be a potential frustration. You don’t want to feel like what you’re doing is preventing the ball from moving forward.
Mona: How did you overcome that challenge?
Mo: I think it’s just a case of being organized with future sessions and understanding the work that was coming through and knowing ahead of time when you thought designs were going to be done and ready. Speaking to engineers to understand what their future roadmap looked like. If they were working on a current feature, knowing when they were going to be done, realistically, when they would start building the next one and working backwards from that. And as I mentioned, usertesting.com really sped up some of the things that we did. For a lot of things we could get results back in a couple of days.
Mona: What did you learn about design and research during your time at TransferWise?
Mo: I hadn’t really worked in a product focused company before. At Appe+IBM, we were building a brand new enterprise product for a handful of airline engineers and there weren’t big numbers that we could do A/B testing with, for instance. Before that I was working in a consultancy where I would go in and do design workshops, come up with some cool ideas, present it and then disappear. Those were quite different environments.
TransferWise was the first place I worked at that was a true product company. We were building a product, we had a big user base, we could do decent research, we could do surveys and we could understand metrics and impact work. So it really helped me grow from a fairly naive understanding of product. Product thinking is an absolutely fundamental skill set to allow product designer to influence their teams and roadmaps. Understanding the problem space, how to ship, how to prioritise and how to experiment. That also goes hand in hand with how you should think about your research as well.
Mona: For designers out there who want to join startups, what’s a key takeaway you would give based on your experience at TransferWise?
Mo: Don’t be afraid to lead. I think that besides a product manager, a designer can be the most influential leader in a team.
“Besides a product manager, a designer can be the most influential leader in a team.”
I think you can push and really make the case and drive research forward. Don’t wait for permission and just prove the value. You can really influence the product roadmap. You can take initial ideas and concepts and make them a reality. Because you’re the person that has to create and stitch together flows, you can really understand the problem space and the solution much better than a lot of people can. So don’t be afraid… especially if you’re joining a company with few product designers. Oftentimes they haven’t worked with designers before and they don’t understand the value of design, so that’s your place to then educate and show what design can do.
I say that with the caveat that its not leading in isolation. Leading also means that you can be the glue. It means building really close relationships with your engineers and product managers. Those relationships will really help unblock your work and get quality products out there.
Mona: Excellent. Mo, thank you so much for sharing your experiences with me.
Check out the latest article I’ve written:
Builders and Creators, Effective Entrepreneurship, Small Bets and the Resonance Test
Connect with me on Twitter.
