JENNIFER GOVE: Hello everyone. How are you all? AUDIENCE: Good. JENNIFER GOVE: Great. Such a wonderful crowd. Thank you so much for all
coming to my talk today. So my name is Jenny Gove and
I'm a User Experience Researcher here at Google. I've been at Google, now,
this month, for 10 years, and I heard that
that coincides-- [CLAPPING] Thank you. I heard that that coincides
with the number of years we've been having I/O conferences. So, double anniversary,
that's really fun. So, this afternoon,
we're going to be talking about developing great apps
and creating principles of mobile app design that
I want to share with you, so that you can create great
experiences for your users. And why is this important? Well, it's important
because there are-- sorry-- there are over 1.5
million apps in each of the app stores, as we know. So there's a lot of
competition out there, and you don't want your app to
suffer from usability flaws. I think usability flaws
and user experience issues can contribute to the lack of
engagement that some apps have. So, for example, we've learned
that things like 25% of apps sometimes don't get used more
than once, and 34% of apps aren't opened more
than 11 times. So there's these
statistics that are around, with regard to app
engagement and re-engagement. We're doing a lot of work
on that issue, itself, at Google, with certain products
that we're bringing out. But I think it's also
on us to really work on our user experience and our
usability issues in our apps. So I'm going to
tell you about three things in the rest of my talk. I'm going to tell you a
story about an experience I had with an app recently. I'm going to tell
you about a study that we ran to understand
what makes a really great app experience. And I'm going to go through
some of the principles that we have published online,
so that you can understand some key things that you
can do to make your app experience better. And within those
principles, I've got a number of
resources for you as well that can help
you along the way. So my story. While I was on vacation
with my family-- here we are, we're having a
wonderful time in Florida. That's me and my
partner and my kids. And, before we
went on vacation, I set up a series of
hotels for us to stay at. It was a self-driving tour and
I pre-booked these-- I did that on my laptop. When I got to Florida, I
found that a lot of hotels had started making great use
of new technologies-- apps specifically-- in
order to give me some really seamless
experiences on my trip. They do things now like
enabling me to check in, before I get there-- so just
like I can for an airplane-- and enabling me to go straight
up to my room in order to open the door, just with the app. That's pretty cool, I was pretty
blown away by these new things that they were able to do. But, what happened when
I was on vacation was, the notification
to check in came while I was standing
in line at something like this, the roller
coaster at the theme park. It asked me, did I
want to check in? And it also asked me, did I
want to choose my own room, or did I want to let
them choose for me? Well, back when I
booked, I remember there was a text field,
and it had asked me if I'd got any
requests, and I put in that I wanted to have
a sea view, because I knew at the next hotel there was
this beautiful, pristine beach. I'd ordered a room
with a balcony and I really wanted this
wonderful experience, looking out over the sea. But I didn't know whether
that experience on the laptop would translate into
this app experience that I was now faced with. I was a bit
concerned about that. And I thought that I might
have a better opportunity of choosing my own room,
rather than letting them choose for me. Kind of always better to take
it into your own hands, right? So, I decided to choose my
own room, and the experience that they gave me was pretty
good on a mobile device. It actually worked. I know this looks like it would
be quite challenging in terms of real estate, but
it worked quite well. They clearly laid out
the different rooms and they clearly labeled whether
the rooms were taken or open. There was only one
problem, though, and that was I had no idea
which way the hotel was facing, in front of the sea. So, I was in line, and
trying to figure out how I could solve this. Now there were some workarounds
that I didn't actually think of at the time. Things like going to
look on Google Maps, maybe I could figure out,
or looking on Google Images. In this case, the hotel
is rather symmetrical, so, it would be quite tricky. I decided to use a kind of
rule of thumb-- or heuristic-- and I decided to think that, the
side with the most taken rooms was probably the side
that was facing the sea. So, I decided to choose
room 730, over here. So we got to the hotel,
took up all our bags, you know what's going
to happen, don't you? I got a view that looked
a little bit like this. [LAUGHTER] Big disappointment. So what did I have to do then? Well I had to then go
all the way down, again, to reception--
which I thought I'd bypassed, by using the app--
and talked to the receptionist. They were extremely helpful,
lovely hotel, fixed it for me, and in the end, we went
back up, a different floor, went in the hotel,
and I got a view that was much more like this. Beautiful, huh? This is actually Florida. It looks like the
Bahamas or something. It was really, really nice. So the in-person
guest service was required-- human
intervention was required-- because the app hadn't
really delivered the service I'd hoped it would. It had done so
well, I was really taken with this new
technology I could use, but it fell short, because
it hadn't delivered this critical piece of
information for me, which was, I just needed some
information on the map. In this case, I just needed
a view of the ocean, perhaps a few waves. I just needed some orientation. So for me, it was
pretty critical that my view was of
this beautiful beach, rather than this carpark. And it could have been
even more critical than my very dear
to me vacation. It could have been an event
manager booking for a client, perhaps it could have been
people booking for guests for a wedding or something. One lesson is clear,
and that's how we, as developers
and designers, really need to understand
the whole flow that our users
are going through, and where that breaks down. This had been really
cool, new technology, but I'd had to sort of backtrack
through the whole thing and do those things that
the app was supposedly saving me from doing. So really understanding
that experience from beginning to end. And, I think on mobile, it's
really those little things that we don't realize
we need to cover, and so that's why we
really need to understand the user's perspective and the
user's experience with that. So, my talk is going to
be about things like that and how we can fix them. Let me give you
a little history. A couple of years ago, we
found that a lot of experiences on the mobile web were
particularly problematic for people. And so, we conducted
a large study and tried to understand
where things weren't being implemented right
for the mobile web, and where we could
do better, and we released a set of 25
principles for the mobile web. Those have done really well. People have used them as
a kind of initial step in making a good foray into
providing a better user experience on the mobile web. But as well as those
have done, we've had people come
back to us and said, this is great for the
mobile web, but my app. What about my app? Can you tell me about my app? So I've had lots of calls
to do another study, and a study on apps, so
that's what we've done. More recently, we've looked
at native apps in a study. And so the principles I'm
going to present to you today are the result of that work. So in this study, we've been
able to understand patents that lead to poor user
experiences, and then, luckily and happily, we were able to
see where some companies have implemented things
in a better way, and understand why those
patents work better, and bring those to you as well. And it's important to us for us
to really understand this well, so that we can be
confident in the principles that we're telling
you about, and you can be confident in implementing
them in your own products. So in order to do this study,
we partnered with a company called AnswerLab. They're a user experience
consultancy based in San Francisco. And we partnered with
them because they could help us scale,
because we wanted the study to be pretty large scale. We studied interaction on
100 different apps on mobile. So these ranged from
large retailers, through to smaller
service providers. We looked at news apps, we
looked at many different sorts of services, like
grocery services, travel services, retail,
small and big companies. We didn't look at
games as part of this, and that was on purpose, because
we felt that would weaken, or dilute, the principles. We think games probably
have a whole different set of principles, so
aside from that, we looked across a wide
range of verticals. And we conducted these studies
in San Francisco, in Chicago, and New York City. Now, there were 103 participants
that took part in this study. So, for a usability
study, that's really big. They came into the
lab, individually, each for 90 minutes. So that makes 155 hours
of usability studies. So, if you stayed up
all night and all day, that would be almost a week,
with no breaks, or, in reality, it's more like almost four
weeks of working weeks. So, a large study,
indeed, and that's so that we could cover
these different verticals. And what did we
do in this study? Well, people came
into the study, and during the 90
minutes, they were able to use around
six apps for really getting into some good
tasks for each of those. They brought in their
own phones with them, and that was because
we wanted them to be really familiar with the phone. And we didn't want any
problems because it was a different
device, or they weren't used to the back button,
or anything like that. So we had about 50% on
Android, and 50% on iOS. And then, what did we do
when they were in the study? So, we had different tasks
and different scenarios set up for them. We did our best to make that
task kind of mean something to them, as well, so that they
couldn't do, what we call, satisficing, which
is just kind of doing the task as soon as they
can, and in as quick a way as they can. We wanted them to
care about the task. So we often talked to them about
things that they cared about. In this example, we
might talk to them about their favorite
food and understand what it is from them,
first, before then going to ask them to see if
they could order it for dinner that evening. And we had them
speak out loud using, what's called in
usability terminology, think-aloud protocol,
and we did that so that we could understand
the pain points that they hit as they were going
through the different tasks that they were
doing, and we could understand where things flowed
really smoothly for them. So having done that, we took the
data-- there was a lot of data, as you can imagine, from that
much usability material-- and we've collated it
down to 25 principles, so that this is something that
you can take, and understand, and apply it to your own apps. We've categorized the
principles into six chapters, but before I go
into them, I want to explain how we
actually got to these 25. So, in order to make it
into the 25 principles, we had to see that this was
a problem across a wide range of verticals, and we
had to see that it was a fairly common problem. We did encounter more
things than 25 things that were problematic in
apps, but we wanted to make sure that we were
hitting the biggest problems, and that we also saw
better ways that these could be implemented. OK. So, the different
chapters that we have are around app navigation
and exploration, in app search, commerce and
conversions, registration, form entry, and usability
and comprehension. Now, we've got 25 of these
different principles, but here, in this talk, I'm just
going to go into two principles from each of the chapters,
and the rest of the principles are available to you online. I've also pulled together
some resources for you that can help with
implementation of some of the things you see here. That might be a good time to
take a picture of the screen, as it's a resource that you
can look into in your own time, in more detail. OK, so let's starts off with
app navigation and exploration. So this chapter is really about
guiding users to the content that they're looking
for, quickly. So we brought together
a set of key principles to help you create effective
and delightful app navigation. So let's take a look
at two of these now. So, a feature that can be
really of great help to users is auto detection of
location, but don't assume that the location-based
task is necessarily based in their current
location, without exception. I think we saw this too often. So it's a really
great thing to be able to implement
and help create a seamless experience for users
when they want something that's located where they
are, but basically, we saw it over-applied without
a way of enabling people to change that location. So in this example, somebody
is looking for a hotel tonight, and they're looking for a
hotel near where they are. And, unfortunately, while
they can change location, the only way to do it is
probably go through settings. We saw this problem in,
not only travel apps, but we saw it also
in retail apps. We saw use cases of people
wanting to find something in a store, but that
perhaps was located near where their
parents live, and they wanted to figure out if it
was in the store near them, so that they could tell
their parents about that. So just only providing
this, basically we we're seeing too
many use cases that were outside of the scenario. In travel, we saw it
where people would turn up for their transportation, and
the hotel that they wanted to book was at the other end--
the other end of the train line, and they had time
now to book the hotel, but they're not in the
place where they're needing the hotel at the time. A much better
scenario is to still enable people to use
their current location, but to provide the resource
for them to change that well. So basically, great, great
technology here, that I definitely encourage you to use,
but it's kind of over-applied, without using some of
the screen real estate to enable them to
change location. If you do want to use that
auto detecting location, then Google Places
API enables you to discover that currently
supported location, and we've got a
short link for you there to get to that material. So, another aspect of app
navigation and exploration that we saw a fair bit
with apps is, moving people from the app to the mobile web. And you can see in
the way I've written this principle that there
are issues with doing this. It says, where app-to-web
transitions are needed, so where they are needed,
make them frictionless. So I think the idea here is, are
they really needed in each case for doing it? We're trying, here at
Google, to make technologies to make this a lot smoother,
this transition where you need to do it, but at
the moment, we still see at least some sort
of performance hit. So, really consider
whether you have to push people out
to the mobile web when they're in their
app experience right now, and then make them frictionless. So, in this example,
we've got somebody who's checking in for a flight. This can be a quite
usual situation where people are moved
out to the mobile web. But what we often saw, are
not just in travel apps, in other scenarios, as
well, we saw the experience change fundamentally. So we saw something like this. OK? And it can sometimes
happen, I think, because of the organizational
structure of teams. You know, this is the app team,
and this is the mobile web team, and they haven't
been talking enough, right? So I think some companies are
doing a better job of bringing these teams together to
enable them to plan the user experience, the look and feel,
and how content is laid out. And then, separating out for
the actual implementation on different platforms. So, a much better
experience is when companies have been really
thoughtful about this and you can make that look
and feel very seamless, even though you're just moving
right out to the mobile web. On Android, we're doing
some work on this, and we've got some technology
called Chrome Custom Tabs that you should look into. It's really helpful
for enabling you to do things like changing
the toolbar color, and exit and enter
animations, to make that whole process of
moving from that app to the mobile web more seamless. Moving on to the
second chapter, here. So, the importance of
great in app search really can't be underestimated. So, let's talk about a couple of
crucial search implementations. So, prominently displaying
the search field. We found this back when we
did the mobile web study, about the importance of search. So, on the poorer
example, we have search in a place where
people expect to look for it, but it's not how they expect
to find it, as a piece of text, here. What we saw in the
study was people kind of did have some frustration
looking around for search. Sometimes it was
hidden under a menu, and it sounds like one of
the most obvious things, but I think what my summary
of what I saw in the study, was that developers and
designers aren't implementing a persistent search
field enough. We advise that a persistent
search field should be included when searches are really
quite a significant part of your experience
in your app, but I think what's happening
is plenty of people are thinking that search
is important, but not that important to devote
the screen real estate to. So, check that out in your app. Should you be giving it more
prominence than you currently are? So we have advice on
this, in Material Design. And we have persistent search,
putting in a search field, and we also have
expandable search, where we have the looking
glass icon that can be expanded for search, of course. Think about the prominence
of search in your app, and how much it really
matters to people when you're making that decision
about which type of search you should implement. And then, for
implementation details, we have the search dialog
and the search widget, and this link will take you to
more information about that. And what about filter
and sort options? Hugely important. Again, we often saw that they
were hidden, or sort of buried, or further down, and
people couldn't get to them as much as they needed. That's what our study, that
we just did recently, showed. We did see great
implementations of it, but still, there's
more work to be done. Things like getting down
to 242 results for a shirt, with no way to filter
or sort them further. So, a better
implementation is to have a really nice, clear button. Filter. People can see that
quite clearly and easily. And then, this
example, for apparel, you have this panel sliding
out with all the right sorts of search options for them. So you could sort by best
match, latest collection, that kind of thing. One thing I saw with
filters like this was, some companies were taking,
for example, the sizing away, when the inventory
wasn't available, and that caused a
problem for the people, because they didn't
know if they would ever have their size in stock. So imagine extra small
being taken away, just because it wasn't
in stock, people didn't know if it'd come back. Better experience for that is
something like enabling them to, perhaps sign up to find out
when it is back in stock stock, but certainly showing it, and
showing it in a stable state is good. So here you have colors, and
price, and one other thing I like about this design is
it's very clear when you're clearing the filters, or
applying the filters, and then a separate check at the top
in order to close the panel, so that there's not confusion
about what closing the panel does. So, keeping on this
topic of search, we have other methods that will
help people with their search. One of those is Adding
Custom Suggestions. That can be created from
data in your application, so that can really help
people with their search. And another one is
Recent Query Suggestions. So all these technologies
and facilities can go to make that
search experience better. So thinking through that
search experience in more depth is a good topic. Commerce and conversions. So users expect a
really smooth in app experience for finding, learning
about, and purchasing products. So let's look at
a couple of things that the study revealed about
commerce and conversions, and helping to drive that
conversion experience. So, enabling comparison
shopping features. So in this example, on
the left here, we're in a real estate
app, here, and people are just-- they're only
able to scroll down and look at the different homes. Anything they like, they have
to commit to memory, and people, us, you and me, we're
all cognitive misers, we don't like to use our
brains that much, really. And we're making the user
use their brain a lot here, remembering where they
saw things and so forth. But we can do better,
and some of those things that we saw that were
implemented to help people in this way we're letting
people kind of bookmark items that they saw, so that
they can compare them. It's still pretty difficult
on mobile to do this, but still, anything
we can do helps. So the example I'm
going to show you here had enabled people to compare. And then, you can see
it's quite constrained, with the size of the
phone, but still, you're bringing that
information together. It means they could ignore
all the other homes that they didn't care about, and they
can compare the bedrooms, they can compare the bathrooms,
the cost of the home, and so forth. We know this is needed,
because, in the study, we saw people do
workarounds for this. So, in retail, we saw people
add items to their cart, just so that they could look
at them all in the same place. And that was the users
that thought about doing that, other people struggled. So we know this is needed. So think about the comparisons
and the browsing experience that people are needing
within your app. And then, making it easy to
add and manage payment methods. I actually came across a poor
example of this the other day, and it was when I
went to purchase-- I was going on vacation, again. I like to go on vacation--
and I was making a reservation for a rental home. And I got to the point where
I needed to update my card, so my model in my head was,
well, a new card had arrived, and it's simply the
same card as before, it just had a new date on it. In my mind, my mental model of
my cards, that's the same card, just needs replacing, it's
not a new payment method. So I expected to be able
to edit my existing card, but there was no
facility to do that. So I kind of had to understand
the developer's model that I needed to add
a new payment method. In this example,
the person has got to the point where they're
supposed to be checking out, but there's no way to edit
a card, or add a new card. That's somewhere else,
in some other settings. But most of us don't
think, well, I'm going to wake up in
the morning and think, I need to manage my payment
methods in that app. Kind of is a separate
activity, right? We tend to think about
it when we need to do it, when we come to pay. So, this is a problem here. So, in this example,
it's much better. There's an option to
edit existing cards, to add a new payment method. And provide multiple payment
methods here, and lead people to a very clean
form design, here, when the user has chosen
to add a new credit card, and they can even scan
their card if they wish to. So making that experience
nice and clean. Now, one facility that
we offer at Google is Android Pay, so making that
a choice of one of the ways to pay. The idea, here, is it's
really simple for the user and seamless for the user
to pay through Android Pay, and I think there's a
talk about it here at I/O, and there's more information
that you can get at this link. So registration. Registration is really popular
with companies and developers, because it's seen
to be that that is where we can get
engagement from the user, and that's kind of where
the user commits to us. We've known for a long time that
providing these registration barriers up front can be a big
hurdle for people to get to, and it's better to offer
them something first, so that they can start to feel
engagement from their side, to the company. There's a couple
of other things I want to talk about today
with regard to registration. So we saw users struggle with
signing in and signing up. It's a tricky thing, right? We often saw users starting
to fill out a form, if they were provided
one, and realizing they were signing in when they were
supposed to be signing up, and vice versa. It's probably
happened to all of us. So we found better
experience when people were just given the
option to sign in, or register. The words were very different,
they could differentiate them, and then we could channel them
down the right kind of route, so that they didn't
get into that muddle. We have lots of solutions
for registration and identity at Google. We have a whole
identity platform that I'd encourage
you to look at. It's basically an
auth system, and it has several components and
different choices for you to make. So one of these is
Sign-in for Android. It enables the user to sign
in with the same credentials that they use on Google. The whole intent is to
make that process more seamless and simple for them. And talking of that,
there's other ways to make password authentication
a frictionless experience. We've all been in this
situation, where it just doesn't work for us, and
it's quite painful on mobile to keep putting your password
in and it's not working. It can be even worse in
apps, because we often found that this was a place
where people were sent back out to the mobile web, right? So then, you're in
that loop again, and that's even
more aggravating. So we've talked
about one solution for easing enabling
people to sign in. Another one that we saw that's
becoming much more popular is fingerprint sign
in, and, in our study, people were pretty
happy about this. They liked the idea
very much of doing this, so I think this is a
good thing to look into. And we have some more
implementation details for you, here, by using fingerprint
scans on supported devices. And Smartlock is another
part of our identity system. It enables you to automatically
sign users in to the app, using credentials
that they've saved. So that's another
really good one, part of this federated
identity provision. And, if you haven't got
that far with users, there's also a Sign-in
Hints, and this allows us to use the credentials API. It enables you to give hints
to the user for signing in, for their username
and email address. Everything is done to kind
of ease that sign-in hurdle. So form entry. We've been talking in
design about form entry for years and years. We did lots of work on
form entry for desktops, and when we went
to the mobile web, we kind of had to relearn
all about again and again. You'll remember when those forms
used to be really, really tiny, and you have to expand
them to fill out the form. It's always been a little
bit better with apps, because we've been
designing forms from the get-go for
the mobile devices. But, I'm pleased to say, I
think we've come a long way, but there are still things
we saw in our study that could be improved. So I've categorized this under
building user friendly forms, and some of the
things I saw was still some apps requiring users to
do a lot of work on their part. Putting that cursor in
several different fields for their phone numbers,
and things like this, takes a lot of effort
on the part of the user. And also, not paying out to see
what form fields were coming up was a problem for users. It was hard for them
to sort of build their mental model of what they
would have to fill in next. It caused them frustration
and was definitely a friction point. So, better engagement,
here, is doing more work on the back end. So, whether the user wants
to write in their phone number with dashes in
between the numbers, with spaces in
between the numbers, or it's just one long field,
we need to cater for that and make it-- it's a
little bit more work for us on the development
side, but it makes it a whole lot
easier for the user to understand what
they're doing, and not get an error returned. So also, where there are
errors, providing those inline is really helpful. And here we have
an app that does a really good job of moving
the form up the field as the user fills
it in, and we found that was very
advantageous to users. So, we have a lot of information
on creating great text fields through Material Design. Talks a lot about
the different aspects of creating a good form. And, specifically for places,
we can use Places Autocomplete as part of the
Places API, again, and this can really help
for filling in those form fields that require location. Another aspect of form design
is matching the keyboard with the required text inputs. This is a fairly
well-known thing to do, but we still saw significant
apps not doing this well. So when the users put their
cursor in the credit card field, and if you've
got this in your app, you should check it out, is it
doing the right thing, right? In this example, here, it's
not doing the right thing. The user is left
with this keyboard, and they don't have any way of
getting the right keyboard up. Not usually, they hit the
number key over here and then they'll get the keyboard with
the numbers along the top, as opposed to designing
that appropriately, and once the cursor is
in there, bringing up the numeric keyboard for them. So little things like this, all
these little things on forms really add up, and just
checking out your form design in this way is really
helpful for people. So we've got information
on Specifying Input Method Type, and the correct keyboard,
that you can find at this link. Then lastly, let's look at
usability and comprehension. These are those small
things that you can do, that we saw in our studies,
throughout the app, to make a more seamless
experience for users. It can be critical for
ensuring a good user experience and not having users get stuck,
or abandon their experience, at any point. This one's about providing
text labels and visual keys to clarify visual information. So, we saw this earlier. In my story, I was specifically
missing a visual key. I just needed those
waves in the picture to help me understand the
orientation of the hotel. Take a look at
this example, here. Just take a couple of moments
and decide for yourself what you think those
icons represent. Some of them, perhaps
more obvious than others. Should we have a
look at the answers? Here we go, so, it's my trips,
book, club, and account. Did anyone get them right? I think probably
account wasn't too bad, but, the lesson here,
that we saw, is again, I think it's over-generalizing. The rule that we would give
is when icons are vague, then they definitely
need text labels. The trouble is in
saying when icons are vague is, we all
have different levels of understanding,
with regard that. You have to, I think, assume
that a lot of your icons are going to be vague. I can give you an example. So, you know the
icon for filter, that looks kind of like this? You'd think that would
be fairly universal. It's drawn in quite
different ways, across many different
apps, and we certainly didn't find it universally
understood among people. So, I think we have to
change our kind of level set with regard to the
number of icons in our apps that need to have
labels, if people are going to understand it. And this is a very
great place where you can do simple
AB testing, and see the difference between
providing labels and not providing labels. Here, we've got some
implementation details for when you want to use
text and icons for buttons. So if you have that, there. And then, talking
of labeling things, that always makes
me aware of making my application accessible. We have lots of
guidelines here for you to make sure your
application is accessible. And the last principle
I'm going to go into today is asking for
permissions in context. So, this is something that
we enabled with Android M, but we still see that
significant number of apps aren't making advantage of it. It's been able to be
possible and iOS for a while now, as well. So in this example,
the user has just downloaded and open the app,
and they're immediately asked, can their location be used? So, perhaps this app
was suggested to them by somebody else. They said, oh, this
is a really good app if you want to learn
about home decor, and it's got some really
cool things in you can buy. But it's kind of
similar to how we would think of problematic
registration, right? When you ask for that up front
and it's a hurdle to get over. This is the same
thing for users. It's like the developers saying,
provide me with your location before I give you
anything else, right? And users are often
going to say no, because they don't
really understand why and they just wanted to
look around your app. So, a better way to
do that-- and you can do that now,
because of Android M-- is being able to do that
in context at run time. In this example, we have
people searching for stores. So much better because the
user has their own motivation, right? They want to be able
to find that store, and then what happens next
is even more clear for them. There's a map that comes
up behind and it asks, can we use you location? Well, of course you can. Right? You're much more likely
to get acceptance if you ask in context. We have lots of resources
for you for this. We have great little videos
and implementation details about being able to request
permissions in runtime. And it's simply in
these principles, because, although I know
many of you know about it, we saw it a lot in the apps
that we studied recently, so, that's why it's here. So that brings me to the
end of the principles I'm going to go through with you. We've gone through
each of those chapters, and you can find more of
these principles online. They're all online
at think with Google. And I made a short link
for you here, specifically to the principles. Better Mobile User Experience. There's actually multiple
sets of principles. Let me tell you what there is. There's mobile app
principles, new set of 25 mobile principles,
there's a new set of 25 principles for retail--
that is both web and app, again, we did a study,
and so we collated the information
provided that, there-- and then there's the
mobile web principles that we've published
previously, that you might have already seen. All at this link, same link. And if you want more
implementation details on the mobile website,
the principles are also part of
our web fundamentals site, and that particular link
I provided with you there, provides additional developer
implementation details. Before I go, I want to
tell you about one more story from the study. So, in the study,
a number of apps that implemented the ability
to scan your credit card, in order to pay. Now, we had a few
people in the study that had used that before, and
come across it, and liked it, but because this is
relatively new technology, we had some people
that encountered it for the first time. Now if you think about the
word scan, my most familiar experience, I think,
with the word scan, is when I go to the grocery
store and scan my credit card, right? And I'm putting my credit
card right next-- well, putting it through another
machine, really, that's scanning. Another place I know
of the word scan is putting paper
on a photocopier. That's kind of a longer
ago, but still, that's scanning, putting something
on top of each other. So the users come
to this request to scan their credit card. That's their use
of the word scan, and if you imagine them
trying to translate that, often the first thing
that's asked is, can we use your camera? Well, is the camera
anything to do with scanning my credit card? Well, maybe, I don't
really understand it, but, yeah, OK, you
can use my camera. And then, it asks you to
hold the credit card here, it with scan automatically. OK, following the
instructions, no surprise then, we saw three people
in the study do this. And they waited,
and they waited, and they were
terribly disappointed, because they thought it had
sounded so simple way to pay. And, this is just
about as understanding what we're asking people to do,
and the language you're using. It's plain and simple usability. We'd all love this to
work, unfortunately it doesn't work yet. But it makes sense, right,
what they were doing, because of what they
were being told to do. So again, I return
to that point I made earlier, which is
understanding the user experience, end to end. Understanding the flow
and the pain points. Really important. Because I want you to
have an experience where you make a really good app
experience for your users. Not one where the
user is frustrated, and not the kind
of frustration I felt like after I'd used my app,
and gone up to my hotel room, and seen that carpark
out of my window. I want you to be able to
make app experiences that make people feel like life
is really frictionless, much more like a view of the beach. And so, I want to end with
giving you three takeaways. And these are three
steps that you can think about doing after this talk. Taking a look at your
app and auditing your app against the 25 principles. Simply like, what are we doing
in each of these experiences, and is it measuring up? That's going to get
you a long, long way, but your app is
unique, too, right? So you have to really understand
your key user journeys, and understand those
breakdown points. What I'd been provided
for my hotel app was really exciting
to me, but I had points that broke
down from me such that it didn't end up
working that well in the end. And then finally, thinking about
doing your own user testing, and this guide from
Google Ventures provides lots of resources for
getting going for user research and user testing, in a
really small scale way, so that you can see the
good things that you provide in the app, and celebrate those,
and also identify the pain points in your app, so you can
think about how to fix them. Thank you for your time. [MUSIC PLAYING]
