[MUSIC PLAYING]
CHRIS SINCO: Hi, I'm Chris.
I'm a UX design lead.
PREETHI SRINIVAS: And I'm Preethi.
I'm a UX researcher.
CHRIS SINCO: And we're here today
to talk to you about a team you may not know existed.
So we're from the Android Developer UX
team, or ADUX for short with our lovely mascot.
We're here today to talk about what we do.
And I think this is best told through a story
about a feature.
So every major feature area in Android Studio
goes through what we call the life of a feature process.
And today, we're going to briefly share
a story about the Navigation Editor
and how that process worked with that.
So there are five phases to this process--
discover, explore, refine, finalize, and ship.
Of course, things are not always linear
as you know with software development,
but they do help organize the key moments in the journey.
So for the Navigation Editor, these
were kind of the key moments in the production of the feature.
And we'll walk through each of these in a little more detail.
So for the discover phase, we have
to first figure out who is the user and what do they need.
And the key here is to really focus more on the user's goals
and the high-level tasks needed for them to achieve them.
So one of the great thinking tools we use is to generate
user stories with this fill-in-the-blank statement,
which is "as a developer, I want to blank, so that I may blank."
In the context of Nav Editor, we said, as a developer,
I want to write less boilerplate code,
so I may focus on the flows of my app.
PREETHI SRINIVAS: And coincidentally, this
was actually one of the quotes we heard
in one of the user studies.
CHRIS SINCO: Yep, exactly.
At the same time, we also assess the current workflows
that people go through to better understand
the gaps and opportunities.
And in this case, it was for building app navigation.
So now that we've defined user needs and gathered
some requirements, we need to explore certain solutions.
And so the key here is to try as many ideas as possible
from safe to risky, and maybe even in between.
And we'll walk through a few of these.
So for the Navigation Editor, we really
wanted to go big on the visual canvas,
but you know, the questions we had
to ask ourselves was how would this work against the library?
Would people find the canvas UI intuitive?
Would the user create screens and how?
Would they prefer a form?
Would they prefer to do it just through code?
Would they want a gallery picker?
And once you had all these screens, how would you actually
organize them as complexity grew?
Would you like to group things or nest them?
Would you want to use visuals cues to actually see, like,
differentiate the screens?
And so once you actually had all those screens, how would
you actually link them together?
So as you know, many screens, they
have multiple destinations, so it's like,
do we draw one arrow?
Do we draw multiple arrows?
Does that make it harder to parse the graph?
And so after exploring all these ideas,
we moved to the refined phase, where here, we actually
have to converge and assess on our ideas.
So here, we worked closely with the engineers
to start building things out and if possible, build prototypes
to test with real users to see how we'd need to further refine
our ideas.
So refinement comes in many forms, like defining red lines,
or in this case, really working with the microinteractions
of these arrows, or actually building
a full prototype of the Nav Editor,
which we did here to actually test if it would actually
work with real complexity with a navigation
graph for people's apps.
It also goes as far as building debug UI for the engineers
to help visualize the exact design details that we want.
So in this case, we actually drew boundaries
around this moving graph to help us figure out,
like, how the canvas was actually
zooming in and out to help the user actually
navigate the canvas.
PREETHI SRINIVAS: That looks really cool.
CHRIS SINCO: Yeah, it was very effective.
PREETHI SRINIVAS: Yeah.
So following the refine phase, we test with users, right?
And this is usually like a one-on-one session,
but there have been studies where
we have run for like two to three weeks where
our users have been super engaged
and they've been providing remote feedback as they
are using the feature.
How does this thing work?
CHRIS SINCO: Touch the green one.
PREETHI SRINIVAS: Right.
And a typical user study involves
gathering feedback from our developers on our design,
in addition to getting their opinion
so that we could sort of try to understand
how we can make product improvements to support
their everyday work.
And in the case of Navigation Editor,
we had several such user studies.
But what happened was when we combined some of these insights
with our very own UX verification process,
we hit this roadblock.
And we identified several issues.
And we decided not to ship this feature.
And so that basically is what is happening with our droid sort
of flying out.
So I'm just going to skip over this slide,
but basically what we had to do after that was we
had to work with engineers and product
managers, sort of [INAUDIBLE] outstanding issues.
There was a lot of polish work.
And we had to take into consideration other aspects
like accessibility and edge use cases.
And there was more of following user research.
And then finally, we hit the ship phase
with all of this extra effort.
And in this phase, what usually happens is the Android Studio
leads, they have like a strict go/no-go process where they are
sort of deciding which of or approving the features that are
stabilized through beta and stable versions.
So if you saw one of these articles earlier this year
or maybe several other articles on Navigation Editor,
there was actually a behind-the-scenes story that
actually led to this launch.
Right, so that's a great story.
Now, let's talk about our team real quick.
Every feature on Studio has a core team
that comprises of engineers, UXers,
product managers, and developer relations advocates.
We call them the core model.
Typically, the UXers are often partnering closely
with the other members of this model
as a feature is being envisioned and created.
We believe that every person has this responsibility
irrespective of our job titles to ensure that we are building
great user experiences.
And oftentimes when we think about user experience,
we are talking about consumer products,
but we think developers are users too
and developer UX matters because great tools lead
to great products.
The more usable developer tools are, the more easy
it is going to be for developers to create amazing experiences
for their users.
CHRIS SINCO: Thank you.
PREETHI SRINIVAS: Thank you.
[APPLAUSE]
[MUSIC PLAYING]