“Standardizing UX: A Roadmap For Success”: Duaa Gettani, Senior UX Researcher at Square (Video + Transcript)

In this session, Duaa Gettani discusses the importance of standardizing UX research and the different stages of UX research teams. Gettani explains that research can be engaged at any point in the product development cycle, from foundational to generative to evaluative research, and suggests standardizing research processes and normalizing research’s impact to incorporate research at all stages.

Transcript:

Duaa Gettani: Hi. Thank you for that lovely introduction. Thank you all for joining, and thank you all for joining a talk on standardizing UX research. I know that doesn’t sound that exciting, but I will do my best to make it exciting. So we’ll get right into things. I know we only have 20 minutes.

Just a quick intro of what I’ll be discussing. I’ll briefly introduce myself, talk about what the importance of talking to users in different stages of UX teams and how that manifests itself in different structures of UX research teams.

So brief introduction about me, I do come from an academic background. So I know a lot of folks in the UX field come from very eclectic backgrounds. There are more traditional human-computer interaction backgrounds, but I come from an academic research background. This is some of the research that I did at the Institute of Transportation Studies where I got my MS in transportation and some of the publications that I worked on and the research that I worked on there.

I talk about this as a way to reflect on how I got into UX. So I come from an academic UX background and wanted to get into a research space in tech and found UX research as a great way to compliment my experience. So just a quick overview of my career trajectory. I started off as a research coordinator at Google and then a research associate at Waymo and then a UX researcher as well as an ops manager. So I did help with the ops management at Lyft, the operations that are associated with UX research. Then my current role here as a Senior UX Researcher.

I think a lot of folks probably joining this talk may have a question as to how I made that transition from academia into UX. My answer to that is that what I did was that I started off by joining in as a contractor at these specific companies. So the companies here in the box are the ones that I joined as a contractor. I think that’s a great way to introduce yourself into the UX space, to understand if it is a value to you and something that you’re interested in continuing, and a great way to network and get to know other folks in fields that you would potentially want to grow within. So just wanted to give that quick overview of how I transitioned into UX in case it’s beneficial to anybody.

I will get right into what I wanted to speak about today. So just talking about research as a researcher. We understand that basic research is about talking to users. So within a UX space, within a product space, the crux is that talking to users and conducting user research is essential for creating products to meet user needs that are easy to use and have a greater chance of being adopted and successful. So setting up processes allows everyone to benefit from talking to a user. So to prevent that ad hoc talking to users and have a structured standardized process in connecting to users.

So the first layer of the onion is talking to the user. If we simplify it, that first layer is just talking to a user. That surface level way to learn about products is to just simply talk to a user. Why they use a product, how they use a product, who they are? Within Square, where I’m currently at, our users are sellers, so people building products for people. So this next layer is understanding a user’s needs, goals and behaviors. Digging a little deeper, within Square we learn where seller’s pain points are, what are their goals as a business and as small business owners?Then where you’re trying to get to, that crux is to understand a user’s pain points and address them, building a seller focused culture for us at Square across all functions in Square banking. Then that center, that sweet spot here is where we want to get to continue to build empathy.

So when we’re talking about research, and we’ve all probably seen this similar structure and we’re understanding at what stage should research get involved in. The short answer is research can be engaged at any point in the product development cycle. From foundational, so learning about people and their problem space to generative research where it’s prioritizing challenges to solve and focusing more on the solution space and then that evaluative research where you’re more tactical and iterative. So research is not meant to be a one-off surface, but rather part of an overall process. Ideally, we incorporate research at all of these stages, both when we know what to build and when we can have something we’re iterating on. So how can we do that? By standardizing research and having and normalizing research’s impact.

So where you want to be and where it’s okay to be. So we know that research structures in different companies can be very different, and that’s okay. So research can have impact at any stage. So I have this oversimplified structure of where you’ll find yourself as a UX researcher jumping into a company. So sometimes you’re the sole researcher, sometimes you’re in a mid-sized team, two to five researchers, and sometimes you’re a fully embedded team, and this is ideally where every researcher wants to be. There are challenges at each stage. So I’m going to cover a few of them, but mostly focus in on the mid space, where a lot of researchers end up being.

Sole researchers, there can be probably the biggest challenges with one researcher is that educating on how research works within your company and having impact to drive growth and drive the growth of the research team as well as prioritizing projects that will allow for that to happen. Then where we will focus today is that mid-size team, and that’s where I am Square banking. The challenges here is that you may or may not have an ops person to help with structuring the projects and there’s still challenges with prioritizing and balancing projects and balancing prioritizing the right projects and consulting on other projects.

So where do we start? There are two ways to begin to, at least the way I see it is, two ways to take in research. You either have a road mapping process, which you can combine both of these processes, and a research intake form, because a lot of the times priorities within the company change, projects change and you may not stick as strictly to the road map as you would hope.

So we’ll start with the research intake process and including this road mapping process. What we do, at least with Square, we align research road map with the product road map. This is yearly, quarterly. It’s not a one size fits all. It’ll depend on what stage of the product you’re in.

So with the stakeholder alignment process we do is that we meet with stakeholders. We then ask about various aspects associated with these wants, and we then align on timelines, priorities in a general way, and we input that into a road map that can be referenced for all stakeholders.

Then the other way to intake these research requests is an intake form. This is a lot of the times a way to allow ad hoc projects that may come up outside of the road mapping process. So road maps change, projects pop up, and that research isn’t aware of, and we want to make sure that research is always aware of these projects. So who fills out these forms? It could be a product manager, it could be marketing, it could be designers. So we have them fill out the background objectives, the impact that they hope to see out of this project to allow us to see if this is a project that we would find value in partaking in.

So inputs to consider when scoping a project, the purpose. So consider whether the work is tactical, low level, reactive or strategic, and where in the product cycle it is, whether the work is, again, low level reactive, or whether it is strategic. So we ask these questions, why are we doing this? Why do we want to know? What do we want to know? Where are we in the product development cycle? Then we think about company priority. Who is involved? Is this a high company priority? Is this a low company priority? Then the timeline, is this something that research can actually get involved with? Does research have the bandwidth for this? Will we have time to complete this project in time for a potential decision and to consider the amount of time and resources that this project will take away from other projects? The level of involvement. How much research support is required? Is this something that research can just support in a way of reviewing research plans or help in other ways, or is this something that requires research’s full level of involvement?

Then finally we look at the priority matrix and how does this fit into that structure of a priority matrix? When I say the priority matrix, I mean defining the involvement can be impacted by this priority matrix, which we folks have probably seen before. If the risk is high and the problem clarity is very low, that’s where we would want research to focus in on as much as possible and have research heavy. Because of such a high risk and low clarity, research has a great place to allow itself to be a part of the foundational structure of a work stream.

Then finally, when we were discussing defining the level of involvement, one way to structure this is to think about a full service model versus a guidance/partner, and finally a consulting/self-serve structure. So in a consulting capacity, in a full service way structure, we’ll start with that is the researcher takes on the project from start to beginning and takes on every aspect of the project, including the research design. Whether if there’s a vendor that needs to be involved in this creation of discussion guides, recruitment, the field work, everything. Then when you’re thinking about it from a guidance/partner perspective, you may have a partner heavily involved with the research with you, whether that’s a PM or a designer who is involved with the structure of the research plan involved with taking notes and synthesizing the presentation. It’s more of a partner capacity. Then there’s the consult slash self-serve model, and that’s where a researcher may not have bandwidth at all to take on a project and they’ll advise on the research approach and review any questions, discussion guides, test plans, and help with every aspect of the study, but not fully complete it on their own.

Then how does this work in practice? So I’m going to have a quick example here from Square. So a case study that I have here with Square, and this is a project that particularly came up in a road mapping in our road mapping process. The larger crux of the problem here was that multiple teams wanted to better understand the needs and perceptions and jobs to be done of Upmarket sellers as it pertains to Square banking. So we started off with meeting with stakeholders and differing stakeholders because this was such a topic that covers different product teams.

Then we scoped out these different aspects that we need to consider as the inputs for scoping. So this spans multiple product teams and impacts overall strategic, generic, and strategy early in the product development cycle. Then it can influence strategy. It was also a high risk and low clarity project. So it allowed me to think about this as a covered all of the higher levels of these inputs and made me want to really push for research to be involved with this project and invest a lot of research’s time and bandwidth into this project, because of it hit all of the inputs.

Then finally because of that, we decided that this particular project would be a full service research project, and this project would require the full support and complexity and all the logistics and it was worth the researcher’s time.

So the impact and approach of this research, what we ended up doing was we did desk research/a literature review, which you see here on the left. Then we did a question prioritization workshop with all of the differing stakeholders. Then finally a third step in this project was that we interviewed specific sellers who fell into that Upmarket category. Within these three different stages, we presented all of this data in a research deck and did a company share out throughout these different stages and also did a final share out as we went through with the different stages of this research.

Then just to quickly go over other practices to build out. When we’re thinking about research, we all see the value of those foundational projects, but the iterative launch evaluative research stage is also important. We just went through a foundational strategic project, but evaluative research can be just as impactful and important, can be a major contributor to justifying the increasing of headcount and moving your team towards more researchers. So small, but meaningful impact. You don’t always have to take on those strategic foundational projects for full service involvement projects.

So this is just a really quick overview of other ways to expand your research toolkit to document new processes, create those research templates and onboard research tools and vendors that you can easily access when needed.

Finally, advocating for research throughout research findings, whether that’s research decks, newsletters, and a research repository, and finally research readouts. That’s it. Gets you to that stage of making yourself that much closer to that goal of being a fully embedded researcher.

Amanda Beaty: All right. Well, thank you so much. You finished just in time, so everybody got to hear your whole talk. Thank you so much for taking the time to join us and thank you to everyone watching, and we will see you in the next session.