ANTHONY MAYS: Welcome to Engineering Everyday Equity.
I'm Anthony D. Mays, software engineer
on the data visualization team here at Google.
In this series, we discuss practical ways
in which we can build equity, diversity, and inclusion
into the product design process.
And in this episode specifically, we're
going to talk about the understanding phase.
And so I would love to introduce to you Livvie,
who's going to help us talk through what
the "understand phase" is, and how
we can use some practical tips to really understand
what the problem is.
Thanks, Livvie, for being here with us today.
LIVVIE LIN: Thank you.
Happy to be here.
ANTHONY MAYS: In our last episode,
I had the great pleasure of hosting Lea Coligado
and we talked about the nuances between equity, diversity,
and inclusion.
We also talked about practical ways in which we can involve
stakeholders into the process, such as by encouraging
executive buy-in, and allyship And we also talked about things
like inviting folks from diverse backgrounds
into the product discussion, so perhaps hold lightning talks.
One of the things that I find sort of difficult to understand
is how I can better get stakeholders
involved in the design process.
Do you know what I mean?
LIVVIE LIN: Yeah, I know what you mean.
That can definitely be a challenge.
Because we're really trying to balance let's push out
new features, but let's also take the resources
to have diversity, and inclusion,
and make things accessible.
I'm an accessibility champion on my team.
And I'm lucky to have other people who
also value diversity, inclusion, and accessibility on the team
as well.
And together, I think we mostly serve
to remind the executive stakeholders
and people about the importance of having this as a value.
And beyond that, I was born and raised
in the Pacific Northwest.
I'm Asian.
I'm the child of immigrant parents.
And I also identify as queer and non-binary.
I think it's amazing how diverse my team is.
We have people who are different ages, who have different work
experiences, different backgrounds, race, gender,
and even different working styles.
And I think everyone brings something
different to the table.
And it's really great that it's a safe place for people
who have different perspectives to be
able to share their ideas.
I also feel like I've learned a lot
from being an accessibility champion,
in terms of just being more cognizant of people
with different abilities.
But it's really about being able to see my work through someone
else's eyes.
ANTHONY MAYS: Well, yeah, I really
appreciate you saying that, seeing your work
through other people's eyes.
Because as someone who is a black man, who's
come from Compton, and who's also Christian,
I really think it's important that people in tech
understand the unique background from which I come,
and for other people that I know, and have met
in this industry who are different
and don't fit the traditional background.
So I can really appreciate that it's
difficult to think about empathy,
and to really practice that.
It can be challenging at times.
LIVVIE LIN: I'm glad that I'm at a place where people
are able to share their ideas, and I'm just
able to learn, and just learn more about other people.
Because everyone has a story, and something to teach,
and something to learn.
ANTHONY MAYS: So in terms of talking about these ideas,
I want to bring this home to a hypothetical app
that I have called Scholar.
And it's a hypothetical app right now,
but the more I talk about it, the more I
think I should spend some 20% time, and try to get it done.
But before we do that, let's talk about the ABCs
of inclusive product design.
The ABCS of inclusive product design
are, A, address diverse needs of current and future users.
Though you may have a target user,
who else could possibly be using your app?
From what country do they hail from?
What kind of educational background
do they have or access to technology?
B, build for everyone, with everyone.
In addressing those diverse user needs,
does your team reflect some of that diversity?
If your team is not diverse, you are bound to have blind spots.
C, continuously test and improve.
Through iteration and debugging, you
may find your product is not as inclusive
as you had originally thought.
Did it somehow not consider men and women, and the spectrum
of gender identities?
Does it exclude people from different locations, beliefs,
or backgrounds?
In various ways, we'll be returning to these concepts.
It's good to revisit them to ask yourself
those high-level questions that drive design functionality
along with important questions of what problem
you are solving for, and what is your underlying mission.
Establishing the ABCs can become second nature to your process.
So now that we know about the ABCs,
I want to talk a little bit about this app
that I want to build.
So again, the app is called Scholar.
And it's designed to connect high school
students who are graduating with schools and scholarships.
And so it's sort of designed like a dating app for students,
that can help them connect with the institutions
of their choice, and understand more about what scholarship
opportunities are available.
In the previous discussion that I had with Lea,
we talked about some practical tips
for baking in diversity and inclusion
into the design sprint process.
And so now we want to talk about,
or I'd like to talk about, understanding the problem.
Are there some practical tips that you
can give me in that area?
LIVVIE LIN: So the first part of the sprint,
this "understand phase," where we really
get to get into the heads of the users,
and together try to gain an understanding of who
our users are, and how we can make this product for them.
We listen to lightning talks.
And lightning talks are essentially
where we are hearing different perspectives of how
this app might be used, and getting a better
understanding of the product.
So the note-taking process of this
is we're going to be taking sticky notes.
And we have blank sticky notes where we write HMW on the top.
And HMW stands for How Might We.
And this is how we can start reframing pain
points of our users, and turn them into opportunities.
ANTHONY MAYS: Well, that's excellent.
That's a great idea.
Matter of fact, as it turns out, got some HMWs already ready
to go.
LIVVIE LIN: Oh, awesome.
Let's take a look.
ANTHONY MAYS: So all right, here are a few that I have.
How might we demystify the college application process?
Also, how can we make it easier for high school counselors
to connect with their students?
And then also wanted to know about how
we might help colleges reach students
beyond just looking at their SAT scores or their GPA.
LIVVIE LIN: Awesome.
This looks like a really good start to some How Might Wes.
Is it OK if I make some suggestions?
ANTHONY MAYS: Absolutely.
LIVVIE LIN: Awesome.
So here you have, how might we make it easier on high school
counselors?
Well, I was recently reading an article about how it can really
help students to start the conversation about college
earlier, maybe even middle school.
It can really turn, "Well, are you going to college?"
into, "Where are you going to college?"
Make it more of a sure thing.
So what if we expand the audience to younger ages,
as well?
ANTHONY MAYS: No, I really like that.
Matter of fact, I've got sticky notes and marker right here.
LIVVIE LIN: And maybe another suggestion
could be, for another How Might We,
how might we start the conversation on financial aid
and merit-based scholarship?
As a general piece of advice, I would
say that you want to think of a diverse group when we're
thinking about How Might Wes, and call out if someone thinks
that a How Might We might be relevant to too narrow a group
or might be too homogeneous.
ANTHONY MAYS: So you're saying that I
should think about how to stretch it out
to a larger group.
LIVVIE LIN: Yeah.
So next, shifting gears a little bit,
we're going to talk about criteria for success.
I would say when making your criteria for success,
go ahead and set some inclusive criteria.
So have you thought about any of that?
ANTHONY MAYS: Yeah, no, of course.
I want to change the world, so there's that.
But here's what I'm thinking--
I'm thinking that 30% of my new users
should be first-generation college students.
In the challenge statement that I talked about
with Lea earlier, we talked about how
it would be great to build an app in 2018 that connects
high school students with the colleges and scholarships
that they need, and to specifically
focus on first-generation college students.
So I'd love to see 30% of my new user base
be first-generation college students.
I think it'd also be great-- piling on top of that--
having an additional 10% of new users,
say, who are outside of the normal college age of 16 to 18.
LIVVIE LIN: Yeah, I'm liking how we're
expanding and diversifying the user base right here.
I also see that you have a How Might We help people
with disabilities, and just in general,
making sure that college admissions process is
more inclusive.
So I would say, maybe we could think about some criteria
in terms of making sure we give specific call-outs to colleges
that have good diversity ratings or strong student
life for underrepresented minorities.
ANTHONY MAYS: OK, yeah, so I see what you're saying.
You're saying that I can also use this app
to incentivize institutions that focus on diversity
and inclusiveness, and sort of give them
a pat on the back to help encourage them to do it more.
LIVVIE LIN: Yeah, sure.
ANTHONY MAYS: Thank you, Livvie, for joining us today.
I really appreciate your wisdom and insights
and helping us with the understand phase of the product
design process.
So great having you.
LIVVIE LIN: Yeah, thank you for having me.
I had a really great time.
And I'd love to hear more about Scholar.
Keep me posted.
ANTHONY MAYS: Of course, you know I will.
So let's just review real quickly.
We talked about the ABCs of the inclusion process--
A, addressing the needs of not just
our current users, but also future users.
And we talked about B, building for everyone, and lastly, C,
continuously testing and improving
on what we're building.
So those are great ABCs.
We also talked about HMWs, How Might Wes, and thinking
about how to keep from making them too specific
so that we're focusing just on a homogeneous group of users,
but really expanding to think about all
the potential users that might be interested and able to use
this app.
We also talked about making the criteria for success
as inclusive as possible.
Thank you for joining us on this episode of Engineering Everyday
Equity.
If you'd like to learn more about how to build more equity,
diversity, and inclusion in your company or products practices,
feel free to visit the link in the description below.
If you have a question, drop that in the Comments.
And make sure to tune in for our next episode,
where we're going to talk about the validation
phase of design sprint process.
Thanks a lot.
[MUSIC PLAYING]