Talking about research ops with Tomomi Sasaki
We are Central, a design team that creates digital products such as websites and applications. We also regularly organize Umami Talks: live interviews with people who create digital products for a living. So far, we’ve interviewed CEOs, CTOs, product managers, developers, user researchers and designers. Our goal is to get product people together to exchange ideas.
This article is a slightly edited version of the chat we had with Tomomi Sasaki.
Tomomi is a partner at AQ, which is a digital design studio made up of 9 to 12 people working in Paris and Tokyo. Tomomi, who currently lives in Paris, is a UX Designer with an affinity for user research.
Hi Tomomi, how did you end up becoming a designer at AQ?
I joined AQ as a Project Manager. I realized that the secret to more successful projects, which is what I wanted as a project manager, was for me to understand UX design and to raise everyone’s expertise in design. So I made opportunities for myself to learn UX on the job. I did a lot of studying on my own so I’m kind of an old school UX designer in that way.
I also do research. At AQ, we don’t call ourselves ‘researchers,’ but we do research as part of our design practice. We do quite a bit of our research to help American and European companies figure out what to do in the Japanese market.
How do you go about doing that?
It depends on where the company is in the product’s life cycle. If they already have a product, we might just go and see what the feedback is. It’s the same as any UX research except you’re in a culture that the product team probably doesn’t understand. So we try to see how we can translate the feedback that we’re getting. A lot of times, it’s not unique to Japan, it’s just bad UX.
I'm often asked ‘Does this icon work in your visual culture?’ and the answer sometimes is ‘No, it’s just a bad icon in general.’ So that's kind of part of figuring out what’s good design and what’s impacted by the visual culture. Of course, there’s a limit to what you can change in a product. We’ve gotten quite good at assessing what’s customizable in a product and giving our advice in terms of what can be fixed right away.
What kind of struggles have you noticed when companies try to internalize user research?
I think user research is always hard to do. We all believe that we should speak to humans and meet people, because that’s what designers are here to do. But it’s not always easy to integrate that into our processes.
First, because the timelines within a project can be quite different. If you’re doing 2 one-week sprints, a two-month research project will get reactions like ‘Oh, we don’t have time for that.’ So there’s this kind of mental model of different time spans that are hard to integrate into the pace of the company.
Second, research is inherently cross-disciplinary. You can’t just go do research and be done. We need to use whatever we learn. Unless that lands somewhere, unless we know how to work with a different department or a different discipline, there’s kind of no point. Organizations tend to be very siloed. So, it’s not just research that has a hard time. I think every discipline really needs to be able to work with others in order to be valuable.
Why did you decide to invest time in changing the way user research is done and how the results are presented?
I have plenty of horror stories. A way that a typical user research project would be assigned is that researchers would say ‘We’re thinking of doing 15 interviews to figure this thing out, here’s the list of questions, here’s who we want to talk to, here’s the deadline. You can expect a report and a presentation.’ This is a pretty typical setup, right? It’s very, very waterfall.
This is the way we used to design when I started. A lot of times, there's this reveal at the end where you say ‘This is what we found out.’ And then people say ‘Oh, we weren’t trying to answer that question’ or ‘We knew that.’ It’s so detached from the process of the organization that it ends up being frustrating, uncomfortable and pointless. It also makes it hard for people to do more research because it’s not landing. That's kind of always been in the back of my head. Also, since we want to advocate for user-centered design, how can we make user research more accessible, inclusive and more valuable? We’ve been experimenting with 3 things.
The first is making the process more democratic. What are different ways in which we can start to share what we’re learning so that it can reach more people within the organization? It doesn’t have to be a huge thing. Maybe it’s just small insights that will make people think in a slightly different way.
We try to involve more people in the process at different points. Not everyone can always go to the field and talk to users, but if they can, that’s great. We always encourage our clients to go to interviews and be an active part of the research team even if they’re not researchers. We do a lot of workshops to get to what it is that we’re going to report, and do the analysis together.
The second idea is diversifying modes of delivery. We’ve always had this idea of MVD (minimum viable documentation). I don’t like writing reports, but there’s this business culture of being evaluated based on the thickness of your report. Especially if you’re on the consulting side. That’s a really deliverable-based business. But it takes a lot of energy and coffee to deliver that and then few people read the PDF and then it’s lost forever. I really hate that.
We’ve experimented with delivering via websites like Tumblr to share what we’re learning during field work. It’s available to everybody in the company and we tag information so people can look for specific topics, people, or segments of customers.
There’s also an idea I really like that I heard about through a design research company called STBY (pronounced ‘standby’). On their website, they talk about fast and slow knowledge sharing. It’s based on Daniel Kahneman’s book, Thinking, Fast and Slow, on how your brain has both fast and slow modes. So the fast sharing could be a Tumblr that you check once in a while. And the slow sharing could be a bigger presentation at the end of a 6-week project.
The third one is about visualizing. I was complaining about writing reports but not everything has to be text. How can we take the insights and turn them into a model, or a map, instead of 10 pages of text? In the UX field, we have models like journey maps, which is a great start. But there are different models and ways of abstracting findings. A lot of this exists in sciences like psychology, in which they have the frameworks for expressing various ideas. I'm always interested in learning from these existing models that academic researchers have figured out over decades. Designers don’t always have to be working on a journey. And researchers need to be able to communicate what they find in other ways than bullet points.
Can you give us an example of a research project that you delivered using this fast and slow approach?
We did a foundational research project in Japan for a job-search site that was looking into how people look for jobs and how employees place ads online to look for people. It’s a fairly broad topic and it was a pretty long research project.
We had workshops in a room that was quite visible within the client organization. People would come in and hear the debrief and together we would start mapping and synthesizing. Everybody could contribute to making the links between what we found so they could already start using our findings. Sometimes, they’d come in with a completely different topic and then we could go out and explore some more. That iterative process was a lot of fun for everybody. It also meant that different people that were visiting the office, from headquarters for instance, could just join and that would already disperse the knowledge in a way that wouldn’t be possible with a report delivery.
In general, we try to make posters out of the models we make. We try to figure out what visual models the clients can really take for themselves and refer to in various conversations. Things to reference to is super important.
How do you combine user research with design sprints?
For a design sprint to happen, you need 2 bits of research. The first bit of research happens before the sprint itself, and is oftentimes delivered as a presentation or experts coming in to share their knowledge. It’s very short but very powerful to get everyone on the same page about what the problem is and what we’re trying to do. A design sprint has to start with understanding whom it’s trying to serve and in what context. You shouldn’t do a design sprint unless you have these insights. Otherwise, you’re not working around evidence of what problem you’re trying to solve. And it doesn’t have to be research especially done for the sprint. It can be past bodies of research.
The second bit of research happens at the end. It’s validation. I think what was so revolutionary about design sprints is that you have to validate your results with actual customers or someone who’s as close as you can get to an actual customer. This is usually done in the form of interviews where you show people the prototype and you see if your hypothesis was correct or not. That’s part of the process.
Could you tell us more about the Slack community for research ops?
Sure! There’s a public Slack group for researchers interested in the topic. I think it started in March. The people who created this group wanted to scale research, and especially qualitative research because it is quite resource intensive. I found this really interesting because, in our field, we need to understand people in parallel to data. Without context, we don’t know what to do with data. I think there’s been quite a sharp increase in interest in research. That wasn't really there before. The mentality was more ‘Oh, we know what we need to know.’ But there’s now a general acceptance that actually, we don’t know, but let’s find out!
All kinds of companies, not just in tech and digital, are starting to incorporate qualitative research within their organizations. But because it’s so resource intensive, it’s hard to scale. So people have started to experiment and build a lot of knowledge around how to do research in different contexts. The idea of the Slack community is to get together and share what we know because we’re not moving fast enough to actually address problems and have the impact that we want to have.
And you’re organizing a workshop on that topic in Tokyo, right?
There’s a global series of workshops that are going to happen over the next couple of months where volunteers in various cities will have meet-ups and there will be a canvas that everyone will share. They'll discuss what they think research ops is (there is no strict definition) and define it together. People will also be able to share the challenges they’re currently working on and what they need help with. The idea is to get input from practitioners and have a working definition of what it means and what we can learn from each other so we don’t all make the same mistakes. We’re really treating it as a research project. I think this is a brilliant idea.
I and my colleague raised our hands to run the Tokyo workshop. One of the principles of the community is to be global. These conversations tend to be quite US-centric. I live in Paris but I really wanted Japan to be part of this conversation. I’m really excited to get different perspectives on this topic of research. We do quite a commercial version of it at AQ. But if we get people who are doing research in a civic context, who are meeting immigrants to see what their needs are, this is a completely different set of challenges that we don’t have. I think we can learn a lot from each other.
You and a colleague recently created a Slack bot called Meekee, as a side project. Can you tell us more about Meekee and your take on side projects?
Meekee is short for ‘meeting keeper’. If you integrate your Google calendar with your Slack, it will look at your calendar and notify you 3 minutes before your next meeting starts. I was really insistent that it be 3 minutes. If it’s 5 minutes, you just ignore it, you forget, and then you’re late to that meeting. If it’s 1 minute, it’s not enough time. So it’s just this tiny bot that we built.
What was really important about that project is not the bot itself. As an agency, as an external design team, we need to be experimenting at a faster pace than our client work allows. A lot of the value that we bring as an external team is that we’ve worked on lots of projects. We can bring in all those sources of inspiration. It’s really important to switch between exploration and exploitation. Sometimes we can’t do something on a client project because it’s too risky. Maybe I’m just not good enough yet. Maybe I want to use this tool, but I’m not completely sure. There’s always this balance to be found: we need projects to succeed but we need to keep trying different approaches and keep learning.
I think as an agency, some of that just needs to happen outside of client work and that’s really hard to sustain. The minute there’s a client deadline, that project is pushed to the side. We’ve had so many zombie projects that people just pretend they’re going to work on one day but they know they’re not. This is quite harmful, I think, especially if it’s your baby.
A side project also needs to be linked to learning that makes sense for the business. It can’t just be a personal passion project because that interest needs to be shared by at least 1 or 2 other people. So Meekee was really interesting for us because it gave us the chance to explore bots. It was a big topic when we started. It was something we needed to look into and we couldn’t afford to wait for a client to ask us to design a bot because by that time, it would be too late. And all the reading in the world is not going to teach you how to design an interaction without a screen.
We managed to make Meekee despite the many client deadlines that stopped us from working on it for certain periods of time. We kept that interest alive by expanding our knowledge. The goal was not just to launch a bot but to explore everything around it.
How did you share what you learned with the rest of the team?
To share what we learned with the whole team, we organized an ‘ask me anything’ session. I think we always share less than we want to because it’s yet another thing that we have to do. It’s hard enough getting that project out the door, do I need to prepare a presentation for my colleagues? So this is one of the things we tried, where we didn’t have to really prepare anything. We also have a meet-up that’s very similar to Umami Talks and that’s encouraged many of our colleagues to present their ideas as well. That’s part of leading a team: creating an environment where sharing and learning happen naturally (or look like they’re happening naturally).
Thank you very much to Tomomi for her great talk. Many thanks to Nádia for making another amazing Umami portrait.
Want to attend an Umami Talk? Register on Meetup and check out our Umami website.
