ANTHONY MAYS: Welcome to "Engineering Everyday Equity."
I'm Anthony B. Mays, software engineer
on the data visualization team here at Google.
In this series, we're going to talk
about practical ways in which we can build Equity, Diversity,
and Inclusion, or EDI, into the product development process.
And for this episode, the third of our three-part series,
we're going to specifically focus on the validation
and prototyping phase.
So now I'd like to welcome Rafael Vasquez
as we talk about the validation phase of the design sprint
process.
Welcome, Raf.
RAFAEL VASQUEZ: Yeah, thanks.
You know, it's good to be here.
I'm a program manager here at Google,
and I've seen firsthand what can happen
when you don't take into account getting a diverse set of users
to use your product early on.
What ends up happening is that you end up getting tech debt.
And what you and I might think about tech debt
is pieces of code, or things that
don't work as they should--
ANTHONY MAYS: Right.
RAFAEL VASQUEZ: --or bugs, and we're just going
to fix it later type stuff.
ANTHONY MAYS: Right.
RAFAEL VASQUEZ: Right?
But tech debt is more than just that.
Tech debt can mean things like having your app not be
really usable for certain communities
because of what they're in.
So as an example, I am a program manager
that's part of the people in sharing team,
and we worked on the photos direct sharing feature.
But I'm also-- I was also born in El Salvador,
and I came here, and a lot of my family is still there.
And when we launched this, I was really excited to show them.
Hey, this is something I worked on.
This is so cool.
And what ended up happening was that it
didn't work that well for them.
And what I noticed was that they don't have the newest phones.
They don't have the best data coverage, data plans.
And those things really hampered how the usage of that feature
work.
And if we had started to address those things
early on as part of our testing and as part of our--
we could have we could have fixed the app up.
ANTHONY MAYS: Yeah, I can really appreciate
that, because as an engineer, after putting
all of the hours and time into building this application
and building what I believe is a great product,
you end up in a situation where you
can't get it out to people as quickly as you may have wanted.
And so you've got a delayed timeline,
you've got things you've got to fix,
and those changes are probably more expensive on the tail end
than they would have been had we addressed them
sooner in the process, right?
RAFAEL VASQUEZ: Yeah.
So actually, I was on a team that had one of our releases
be put in jeopardy because we did not address
screen readers early enough.
And so we had to do a last-minute scramble
to try to get it out on time.
And if we had just taken the time
to do that during the prototype and validation phase
and we had made sure that we had had someone
who would use a screen reader as part of that group,
we wouldn't have been in that situation.
ANTHONY MAYS: Wow, yeah.
So I can imagine that's really frustrating.
And I also have to imagine that those things are much more
expensive to fix later in the process rather than sooner.
RAFAEL VASQUEZ: They are.
And that's why you want to take that time upfront to recruit
a diverse set of users when you're prototyping and making
sure that those users actually use all the different use
cases in your app and in the ways
that they would normally do it.
So what's this app that you're building?
ANTHONY MAYS: So this app is called Scholar.
And it's about connecting matriculating high school
students with colleges and scholarship opportunities.
And it's really designed to remove the frustration out
of the process of pursuing a college education.
RAFAEL VASQUEZ: So you can take that app, and you can--
when you prototype that app, you can take the easy route
and just see can students find the scholarships.
ANTHONY MAYS: OK, right.
RAFAEL VASQUEZ: But you want to start looking at other things,
too.
You want to start looking at making sure
that students of different ethnicities
or different abilities can find scholarships
that are geared towards them.
Because there are some scholarships out there
that are geared towards specific types of students.
And then if you're going to take this app internationally,
you are also looking at other things, too, like, let's say,
language and dialect.
There is countries out there where
there are multiple dialects.
Can people of multiple dialects use your app
and find information easily?
So all those things you can take into account
when you prototype by making sure
that you have a wide variety of users that go through your app.
ANTHONY MAYS: OK.
And I care about all of those different kinds of users.
All right, Raf, so how do I find these users
from diverse backgrounds?
And when should I start looking for them?
RAFAEL VASQUEZ: Well, you should really start looking for them
even before you start your design sprint because you don't
want to end up in a situation where you built a prototype,
and you need people to use it, and you're
scrambling to find people.
That's one of the key things.
ANTHONY MAYS: Because then it starts
to feel like more of an afterthought.
RAFAEL VASQUEZ: Exactly.
ANTHONY MAYS: OK.
All right, so do I use social media to find these users?
Or--
RAFAEL VASQUEZ: Yeah, I mean, social media is a good way.
You can figure out which social media platforms are
popular with the users that you want to target and post ads
there.
That's a good way of doing it.
Another way is you could reach out
to nonprofits that are working with the groups
that you are trying to get feedback from and ask
for help there.
ANTHONY MAYS: That makes sense.
All right, and maybe I can go tap some friends and family
on the shoulder, I don't know.
RAFAEL VASQUEZ: Well, you should really start looking for
even before you start your design sprint because you don't
want to end up in a situation where you've built a prototype
and you need people to use it and you're
scrambling to find people.
Figure out which social media platforms
are popular with the users that you want to target and post ads
there.
That's a good way of doing it.
Another way is you could reach out
to nonprofits that are working with the groups
that you're trying to get feedback from and ask for help
that.
You also have to remember that you
want to try to get your product out as close to the user
as possible.
So you want to think about remote testing,
like how do you get--
ANTHONY MAYS: Remote testing?
What's that all about?
RAFAEL VASQUEZ: You could bring your user in,
and you could have the user use the product in your office,
per se.
ANTHONY MAYS: Sure.
RAFAEL VASQUEZ: And you'll have a certain experience.
But that experience could be totally different
when the user goes and uses that product in their home,
in their daily life.
Their whole usage could be completely different.
So you want to get as close to the user as possible
and get their feedback when they're using it.
ANTHONY MAYS: That's interesting because that reminds me
of something that Bryan Stevenson, a social justice
attorney and advocate, once mentioned.
He talked about being proximate to communities
that have these folks from diverse backgrounds.
And I remember him talking about the need
to really get close to those communities
and meeting their needs where they are.
And I feel like remote testing can
be part of that process of being proximate
with those communities.
RAFAEL VASQUEZ: Exactly.
And being proximate with those communities
is going to just open it up to just seeing how your app works,
and it'll save you a lot of time in the future.
ANTHONY MAYS: All right, so remote testing.
Yeah, that sounds like a great idea.
I can't wait to get Scholar in front of my users
and really meeting them where they are.
Raf, I really appreciate having you here.
Thanks for coming by.
RAFAEL VASQUEZ: Thank you, thank you.
ANTHONY MAYS: And thank you for joining us
for this episode of "Engineering Everyday Equity."
If you'd like to learn more, or if you'd
like to further the work of equity, diversity,
and inclusion in your company or product,
please visit the link in the description below.
Also, if you have any questions, feel
free to drop those in the comments.
Thanks for watching.
And remember, if you do not intentionally include,
you will unintentionally exclude.
Thanks.
[MUSIC PLAYING]