Standardising UX: A Roadmap for Success

[Applause]

hello

can everybody hear me

great

um so

my name is Dua and I know what you all

are wondering

yes like Dua Lipa exactly like Dua Lipa

uh so first of all I want to kind of

give everybody here a round of applause

for joining a session about

standardizing ux research on a Wednesday

after lunch I mean I know that doesn't

sound like the most exciting topic

um so you all deserve a round of

applause for for that effort

um

uh so just to kind of uh go through

things fairly quickly my name is do it

like I mentioned I'm a researcher at

Square specifically the square banking

research team so we're kind of separated

out uh I have a background in academic

research and then also a background in

operations specifically in ux research

operations where I started at Lyft and

then transitioned into a researcher so I

have a bit of background on processes

and standardizing things

so my experience will be coming from

that perspective uh and yes again I'm

currently at Square specifically Square

banking

so just as expectations uh before we

kind of go through all this

um there's no one-size-fits-all formula

for developing and carrying out a

research team specifically within the

context that I'm coming from uh two

fairly larger teams so I know

there's various contexts when it comes

to research for folks I'm coming to this

from that context and I just want to

kind of set those expectations and this

deck is kind of just meant as a starting

point to help you begin to articulate

the kind of types of research and how to

sort of prioritize and standardize those

research practices within your company

so basic research we know is about

talking to users and everybody in the

company should be empowered to talk to

users within the square banking context

it's sellers it's small business owners

talking to users and conducting research

is essential to creating products that

meet everyone's needs and having a

greater chance of being adopted and a

successful sort of uh feature launch or

whatever that is so and ultimately

setting up those processes allows

everyone to benefit from talking to a

user every and uh and kind of creating

and building that connection to the user

so just kind of peeling back the layers

is the first kind of basic just to

simplify that first layer it's talking

to a user and that surface level way to

to learn about products and simply talk

to a user

um and why they use the product how they

use the product and who are they that's

that base layer that anybody can kind of

do at the company

the next important aspect is to

understand a user's needs goals and

behaviors to kind of dig deeper

um and we want to understand

specifically in square banking what

sellers pain points are with their goals

for their business are we're talking to

a lot of small businesses and a lot of

small business owners

and then ultimately kind of like the

sweet spot is to get to that Center

where we're understanding users pain

points and addressing them and um you

know building empathy the goal is to

build that empathy um for the seller and

or a user depending on kind of who your

ultimate user is uh and and that's kind

of the Crux of it where you really truly

want to get to how do you do that well

so research can be engaged as we've many

of us have probably seen this

um this uh framework before but research

can be engaged at any point in the

product development cycle from Discovery

to launch but for foundational research

generally we're learning about the the

solution the people and the problem

space and then for generative research

we're going to be focusing more about

prioritizing and solving those Solutions

um and then focusing more on the

solution space so at that stage you're

usually in the Define or refine area for

a product development and then

ultimately when we're thinking about

launching a product we're thinking about

that tactical research the more

evaluative research so does our solution

solve that problem and how could it be

even better and so a lot of that ends up

being the more tactical research and

some researchers may not find that as

exciting but it's just as impactful

and then research is not to be a one and

meant to be a one-off solution it's a

part of an overall process as we see we

try to align it with product development

and ideally we incorporate um research

both when we don't know what to do and

when we know what to do and how do we do

that how do we start to instill those

processes within a company so that

research is more normalized than the

impact of research is more normalized

so where you want to be and where it's

okay to be and again this is coming from

my perspective

um where you want to be as a research

team and ultimately where it's okay for

you to be as far as as far as structure

so simple I'm just simplifying this a

little bit but at times depending on

your company you might be the sole

researcher you might be a designer doing

research and so that's that first stage

and as things kind of grow and again

this is a vague representation of

experience my experiences in different

companies as things get to grow you may

be a mid-sized team you might have two

to five researchers but you're not fully

embedded you're still supporting various

product teams you're still trying to

prioritize you're still trying to figure

out kind of the best project and then

the ideal scenario which most

researchers want is to be a fully

embedded researcher less context

switching where research and where where

you are you know not switching from

Project to project you're able to kind

of go with a project through its full

development

uh and again just again to set a little

bit more expectations uh there are

challenges with each stage obviously a

sole researcher would have their have

very specific challenges as well but

there will be challenges in prioritizing

research and standardizing research at

each of these stages

and um just out of scope for this

presentation I won't be going too deep

into methodology so this is kind of just

to give a fair framework of of kind of

research and how it's structured

so with a sole researcher I think that's

probably the most challenging stage

because there's parts of it has to do

with educating your team on Research

what's the right type of research maybe

folks reach out for research that isn't

necessarily meant for ux research so

there's a level of Education that's

associated with you know being the sole

researcher at a company

and having impact to ultimately Drive

growth so that I the the ultimate goal

of this sole researcher is to show the

impact of the research and to

potentially continue to increase that

head count and grow that team so part of

that is prioritizing projects that will

have that impact and also you know

ultimately delivering that impact

where we'll focus today is my my

experience as a researcher at Square

banking we're roughly two to five

researchers right now um so there are

challenges but we do have

um you know a a thriving research team

which is fantastic we are also

privileged enough to have an operations

uh manager an operations manager within

the team which is very essential for a

research team because there are a lot of

logistics associated with research and

I'm sure folks who have done their own

research understand this there's

recruiting there's recruiting there's

Logistics associated with vendors so the

challenges

are quite a bit if you don't if you

don't have somebody helping with the

logistics and the operations side of

things

so

um you know at this stage you may or may

not have an Ops person but we do luckily

and the challenges here are about

balancing and prioritizing the right

projects and Consulting on other

projects potentially and also making

sure that you're choosing the right

projects for those full-fledged

full-service projects

where do we start so the two ways that

we we intake research are Road mapping

or potentially a uh a research intake

form these are the two ways that we uh

potentially get research in uh at Square

uh and with road mapping uh that's

usually sort of the ideal State and

obviously that depends on how

full-fledged the road mapping process is

with other folks at the company and if

that's um you know

if there isn't any sort of ambiguity

there and then there's the research

intake form and we'll go a little bit

deeper into that

so with the research intake process we

want to obviously align the roadmap with

the product roadmap and this is again

not a one-size-fits-all formula

um so for us it's

quarterly folks could do it yearly if if

they feel that the road map would not

necessarily change as much but for us we

meet quarterly and it will again depend

on what stage of product cycle you're in

uh so with square we have a stick our

stakeholder alignment process entails

either a workshop or a meeting where you

get all of the stakeholders in the room

and that's product management design

whoever is involved and we have everyone

kind of list out the potential products

that they'll have for that quarter so

um and and then we one of the benefits

of doing it this way is that other folks

are able to hear what other product

managers are working on and so they

start to kind of almost prioritize in

their heads like hey maybe that

project's a little bit more important

than the one I'm working on maybe the

researcher's time is is better spent in

that way so it's it's pretty important

to kind of have everybody in the room

when you're going through this process

and again

time getting everybody in the room is a

challenge but I think especially when

you're um when you're prioritizing and

setting up your research roadmap it's

ideal to have everybody in the room

and just to kind of look at this sheet

right here this is kind of the ideal

output that you would have out of a

roadmap so you start to scope out the

projects based on different aspects and

then that tab right here is what the

ultimate roadmap ends up looking like so

you have your time allotted you're able

to show what you'll be working on

specific months um you'll you're able to

share this widely so folks can see what

types of work you're working on and are

able to understand why you may or may

not be able to take on their project

and again this is kind of like the ideal

output you would get out of

a uh of a one of these meetings but to

get to this point

I'll get into that a little bit uh later

but

in addition the other way to potentially

get research intake is through a

research intake form so the main reason

for this is if

potentially

roadmaps change this happens all the

time priorities change this happens all

the time as well so to have this intake

form available for folks to submit

instead of kind of just pinging you hey

I need help with research you're able to

document it you're able to you know

understand what their needs are

so what we have the anybody can sort of

submit this form but the way that we

have it is that they're able to kind of

submit not only what the project is that

they want to work on but what the

objectives are what the ultimate

solution or

um

what they would ideally get out of this

potential project so we have that

documented we're able to prioritize ours

as well so

that that's this in addition to the

roadmap is kind of how all the research

is kind of taken in

so what I just described

um is uh how you can kind of begin to

identify projects how do you Scope

projects that's kind of the next

challenge there

these inputs are are a bit of a

balancing act whether the project came

in during your roadmap process or it

came in in an intake submission process

how do you ultimately scope out and

prioritize the projects that you

actually end up working on

so first you think about the purpose of

the project

um you know consider whether this is

tactical low-level work or strategic you

know higher level potentially more

impactful work and where in the product

development cycle this potential project

is whether

um you know you know how it will

ultimately be used what kind of business

decision it will be used for so kind of

considering all of that in the purpose

and then thinking about company priority

uh if this is a high company priority

project if it's low where is this

request coming from is it a higher level

request is a more lateral request so

thinking about that when you're thinking

about scoping and priority prioritizing

projects

timeline

this is extremely important researchers

have limited bandwidth depending on you

know the types of research that they're

thinking about

so thinking about timeline is very very

essential

and not only about timeline as far as

your bandwidth but timeline is to win

this potential decision needs to be made

by so if you work on this project and

the decision needs to be made yesterday

maybe maybe this isn't the right project

for you to spend your time on uh so

consider this and then also consider the

amount of time and resources the project

might take away from other projects so

timeline is very essential when you're

thinking about scoping and prioritizing

these projects

and then in addition the level of

involvement so research can be involved

in a few different ways which we'll go

over but is somebody else going to be

leading this is this uh you know a

project where we'll be reviewing we'll

just be needing review how much

involvement does research need in this

particular project

and then finally the priority Matrix

which I'll also go over

but all of these ultimately these inputs

uh contribute to the level of

consideration so if something is high

priority but lacks purpose or the

timeline doesn't match uh with what

you're thinking that doesn't

automatically mean that the research

should be a consideration you know just

because it's high priority doesn't

necessarily mean that it's the right fit

for research so you have to kind of

consider all of these aspects into the

level of consideration when you're

scoping out a project

so

in addition I mentioned kind of the

priority Matrix and this particular

Matrix I'm sure folks have seen in the

past

one thing I do is that I make sure that

my stakeholders are involved with

helping me decide this whether this

project is high risk and has low Clarity

that's that's the the point where

research should be heavily heavily

involved if a project is low risk and

low Clarity research should still very

much be involved especially if there's

low clarity uh and and then these other

two quadrants is where you sort of

deprioritize research especially if

you're deciding between projects uh and

and again defining involvement can be

impacted by this priority Matrix and

what I mean by defining involvement

is what I mentioned earlier how research

could be a full service level of

involvement or it could be you know

where you're just the guidance partner

in a project or you are just Consulting

and and the re and potentially the

stakeholder is doing the project on

their own so what I mean by self-serve

is maybe a designer is leading the

research and they just need review maybe

this is a par project with like guidance

slash partnering you know a researcher

will advise and approve the research

plan the questionnaire making sure that

you know they're not asking biased

questions making sure that the proper

research techniques are taken into

consideration and then that's the sort

of the guidance that's partnering level

involvement

but when you're thinking about a full

service project especially if you're a

growing research team and you're

thinking about you know how I can grow

this team and how much impact you want

that full service project is the most

important project as to which one you're

going to get involved in so you really

have to think about the full service

project and think

um you know really strategically and

intentional about the projects that you

take on for full service and when we

talk about full service we're talking

about full on you know taking on this

project from recruitment from all the

logistics creating the discussion guide

creating the research plan and then

synthesizing and ultimately reporting

out the research

uh and then since especially at Square

we're not a fully embedded research team

it's definitely important that we be

intentional about the full service

projects that we take on

so how does this work in practice

the this particular project came up came

up in our road mapping process so this

wasn't an intake uh this didn't come in

through an intake form it came up in our

road mapping process but the question

was or at least the the what we wanted

to focus on was multiple teams wanted to

better understand the needs perceptions

and jobs to be done of upmarket Sellers

as it pertains to banking

so we met with stakeholders and when

we're when we with this process like I

mentioned it came in through Road

mapping and it came through multiple

stakeholders so we know that it's a high

priority project we know that many

people are thinking about it uh so when

we're thinking about kind of this uh

framework of helping scope out projects

uh we know that the purpose

is uh is help meant to build strategy

and melt meant to sort of help continue

to build out the roadmap for the future

so it's purposeful and intentional and

then with company priority we know it's

a high priority project so we know that

it is kind of higher level in in that

decision-making process the timeline

matched up because one important thing

that they brought this during the road

mapping process so we're able to

make sure that we have the bandwidth for

this project and it wasn't kind of

brought in through an intake process

and then level of involvement just based

on the needs of the project we know that

we would have to have a higher level of

involvement

and then for the priority Matrix we know

that this is high risk and then we know

also that there's low Clarity on what

our Market sellers need so this kind of

hit each bucket when we were scoping as

far as like the level of of

um priority prioritization it needs for

each of these aspects here in our inputs

so like I said we ultimately decided for

this project to be prioritized and a

full service project so this this

project would require full service

because of the complexity and the level

of logistics it would require to have a

researcher be involved in so it was

worth the researchers time ultimately

so just to quickly kind of go over the

project this less has less to do with

kind of how we prioritize but ultimately

what this project was

um we it came in kind of three phases we

started off first by going through past

research so creating a repository of

past surveys on up Market sellers any

interviews that we had ever done with an

upmarket seller and we created a whole

repository of that past research

we then did internal interviews with

account management and sales and folks

who already talked to upmarket sellers

before actually talking to Sellers and

we connected with data science and

internal data so we had this huge

repository of all the information that

we already have before conducting any

research

and then we presented this data in a

research deck and did a company share

out just as this first phase

and then we gathered stakeholders for

this next kind of phase here the

question prioritization Workshop so we

gathered stakeholders in the room

um and we asked them what was left out

from that first phase of research we had

them all create any open questions that

they might have that were answered from

this first phase of research

so we created those questions and then

we then prioritize those questions so if

folks felt that the questions that

others brought up were a high priority

we then prioritized those as the

questions we would then pursue in the

next phase which were these seller

interviews

and we ultimately interviewed our Market

Sellers and we had remote interviews uh

and so this is just a kind of give an

idea of the phases of a project that

would be a full service project that

would require Logistics that would

require a lot of legwork to kind of go

into

so lastly some other practices to kind

of build out I went through kind of like

the road mapping process and how to kind

of scope and research scope and

prioritize these projects

in addition

we should I I went through kind of like

a foundational

um project right before this but

evaluative research can be just as

impactful and important so especially in

a team that you want to grow and you

want to kind of catch those low-hanging

fruit to be able to still have impact

those tactical and iterable pro

iterative projects ultimately can in can

be a part of increasing head count

because we see the value and we see the

the way that the research has had impact

so you can build uh you can be a major

contributor to just justifying the

increase of uh head count but it's small

and meaningful to kind of have this

space as as a researcher so all this to

say

um you know we think about research

having impact and value and and we

sometimes sort of make that synonymous

with those full-fledged foundational

projects but those evaluative projects

can be just as important

this is a bit but um this isn't uh just

to kind of give a a quick understanding

of the of a research toolkit so some

like I mentioned some mid-sized teams

already have research Ops so they're

able to kind of help with uh creating

those best practices docs creating a

recruitment process but when you're a

mid-sized team or even a sole researcher

it's kind of all hands on deck so

um you know when you go through a

process you then kind of create those

best practices docs so the next person

doesn't have to reinvent the wheel

so that's kind of the way that we go

through it with square banking so again

research Ops is very important here but

if there isn't a research Ops person

there's always room to be able to kind

of create those document documents

another very important aspect especially

if you have folks who aren't researchers

in your company doing research is to

kind of create these templates so they

have so folks have a starting point to

be able to create those research plans

one important thing before is that

standardized survey question bank so we

don't want folks Reinventing the wheel

when it comes to survey questioning so

having that template for folks to

reference and then that research plan

research brief is really important the

way I distinguish a research plan and a

research brief so with a research brief

I'll usually have stakeholders actually

um create that first they may have

context that I don't have and so that

research brief is a way for us to get a

better understanding of like what the

objectives of a project and what they're

already existing assumptions or

hypotheses are and then I go ahead and

create a research plan from that so

that's kind of my distinction for for

the research plan research brief

and then a discussion guide template is

also very important to kind of have a

good template for folks to to use when

creating their discussion guide for

interviews so they're asking the

questions in a you know intuitive way

and in a way that it makes sense to be

able to approach a user with

and the other really important template

is our Note Taker template and our Note

Taker sign up sheet so Note Taker

template is meant for folks who want to

participate in sessions that um that are

may not be researchers just want to kind

of hear from our users so you don't

necessarily want many people in those

sessions so we have a note taker sign up

sheet and that also kind of helps folks

kind of be a part of the process a part

of the research process

and you know involved with kind of uh

the the research

the research plan from start to finish

so that's really integral and finally

onboarding research tools and vendors is

important as well especially if you're

not a full-fledged embedded team there

are times where there's important

projects that you can't take on so to

kind of have that vendor in the back of

your toolkit by onboarding them

beforehand is is integral so and when I

mean by vendors I'm thinking about

recruitment tools so you know at times

you might not be able to recruit

internally so being able to kind of pull

out a recruitment vendor to for

potential research diary study platforms

are fantastic

surveying tools and then qual and Quant

Partners to help with research that you

may or may not be able to take on

and then finally this is very very

important because research visibility is

integral to potentially have your team

continue to grow so creating sort of

that visibility can be done through

research decks research readouts

um and particularly at Square banking we

have

[Music]

um

we have live streams for our readout so

it's uh anybody can join anybody at the

company can join and um you know creates

that larger visibility and that

excitement around research and then we

also have a research newsletter which

sent is sent out quarterly that allows

folks to kind of see the research that

we've been completing throughout the

quarter

and finally the most important is the

research repository can't tell you how

many times they get messaged about a

particular question or you know a

particular area that folks want to

conduct research in that has already

been conducted so that research

repository is fantastic to have as a

reference for folks who may want to

complete research that's already been

done so it's a great this these these

aspects here are great for sort of

evangelizing research and making sure

that we're advocating for research at

the company

um and ultimately sort of the end goal

from doing all of this is to be a fully

fledged embedded researcher I I don't

know many teams that are I think most

researchers are prioritizing and

supporting many different teams but

ideally your team grows and instituting

these practices uh lands you here as a

fully embedded researcher and

just to kind of before we end things off

I think I wanted to kind of highlight

some of the the benefits of being a

fully embedded researcher you're able to

actually be a part of building the

product from start to finish and you're

able to kind of re-reference your

research and not jumping from Project to

project there's definitely less context

switching and as a researcher you're

able to stay motivated because in an

embedded model you're able to make sure

the research findings are translated

effectively so ideally in the end we we

have that fully fledged embedded

researcher

thank you

thank you so much to uh um just

everything you said totally resonates

especially research repositories can't

tell you how many times I've had

research teams or just anyone in the

company they start a new research

project that sorry some someone did the

same thing about a few months ago and

also there's been times that brought

research Ops on before just to kind of

like get people doing it and it's such a

such a relief for for the researchers so

um amazing talk um we have a few minutes

for questions so I think you all know

the drill

um so I'm just gonna

oh

hey um

about the

What would

like that what would that include like

what type of information would that

include and yeah yeah so what I meant by

that was just creating best practices as

far as you know this is the first time

I'm writing this kind of a survey this

is the first time I'm running a Kano

survey so let let's create a best

practices DOC for that for the next

researcher who may or may want to may

want to kind of run a survey similar to

that so they don't have to reinvent the

wheel like I mentioned it could be

anything it could be any new project

you're kind of embarking on to document

it as soon as you just went through it

because all that time that you spent

figuring things out does not need to

happen for the next person around yeah

that makes

question oh

um hi hi that was an amazing talk thank

you so much

um

for for research teams that are just

getting established or starting out do

you have a tool where

um that you would recommend for a

research repository we have research

coming from a ton of different tools and

different people have access or don't

have access and we're really looking for

a way to make that available to everyone

yeah so

there are definitely vendors you could

reach out to that that do that but the

simplest way is to just have a

spreadsheet of this is the research this

is the ultimately impact and deck that

we had for This research

um and then you know plopping it in you

know potential website for that that the

company internally has access to and so

that's kind of how we do it

um and

not only that but there are ways to sort

of even in Google Drive to kind of

organize it in a way that um you know

everyone can have access to so there's

ways to be creative if you don't want to

ultimately use a vendor but I mean

spreadsheets is just fine to kind of

have as a link for folks to kind of

reference whenever they need awesome

thank you

if one right behind you

oh wow I like that one

um I really liked how you distinguish

between uh the

um Consulting model versus self-service

like you had three tiers I was wondering

if you could impact that a little more

like what really distinguishes

um that Consulting versus uh how did I

get this right no guidance I'm sorry

guidance versus Consulting and

self-service like guidance and

partnership

they seem similar to me but they're

obviously distinct so can you talk about

that yeah so with self-service I would

say that the the researcher has very

limited and involvement it really kind

of reviewing docs adding a few comments

here and there making sure nothing crazy

is happening uh because we've all seen

you know some some research that isn't

ideal

um so just making sure you have that

visibility there the consult partnership

research is is still very much heavily

involved it's just the it's um you know

all of the logistics and all of

um you know the the leadership in that

project is not on Research you're

partnering uh almost 50 50 with another

stakeholder whether that's design or the

product manager uh that level is is is

still has heavy research involvement

it's just not all on the researcher

whereas that full service

is all on the researcher but you carry

other folks with you in the process

quick really quick follow-up yeah do you

have like an in does part of that intake

process do you define it as part of that

yeah so part of that intake process we

had the level of involvement uh so for

some of those really high level

strategic or high priority projects

you're more likely to kind of make sure

that research is either guidance or full

service and definitely not the

self-serve yeah

we've got time for one more I think I

saw right behind you

hi

um thanks for the lovely talk it was

very articulate uh I'm curious how do we

draw healthy boundaries between what

part of the research should a researcher

be doing versus what should uh ux

designer be doing because

um research is a big uh part of even the

ux process in terms of it's a it's a

skill in the designers toolkit and of

course it's a specialization for

researchers but I noticed you mentioned

in your model the self-serve and you

know the different formats as a designer

how do I decide when should I be going

to a researcher versus when should I be

doing it myself and I'm I'm more Curious

in the discovery phase

yes that's that's a fantastic question

and something uh that's very important I

think number one in the road mapping

process that process is when a

researcher kind of defines their level

of involvement so as a designer it's

important to kind of get researchers

involved in what you're thinking about

as far as Discovery as early on as

possible so then you're able to know do

I have this researcher's time can can

they fully fully take on this project

and

um when we're talking about that

self-service model

a lot of the times that is

distinctly a designer's um

most of the time as a designer who's

doing that because they don't have the

researchers bandwidth to kind of do more

iterative types of research and they

just want you know a look on a few

designs and maybe it's not worth the

researcher's time to kind of spend uh so

the short answer is a researcher will

give you that level of um you know how

much they're going to be spending time

on that through the road mapping process

or potentially the research research

intake process so the level of

involvement

isn't kind of the onus on the researcher

to explain to the designer and then even

if the researcher is fully taking on the

project there's still a partnership

there with the designer you know

creating the designs uh making sure that

the designs are adequate for whatever

research that's going to be conducted so

there's still kind of a level of

partnership there

we're right at time do it thank you so

much amazing presentations