[MUSIC PLAYING]
PETER FRIESE: Welcome to "Better Safe than Sorry," everyone.
I'm here today with Roman, who is a designer on the Firebase
Team.
And we're here to talk about the UX of authentication
and security.
Welcome, Roman.
ROMAN NURIK: Thanks for having me.
So excited to be here and talk about one
of my favorite subjects.
PETER FRIESE: Yeah, thanks for being on the show.
So the reason why I invited you was this video here, "Android
Design in Action" from 2013.
ROMAN NURIK: Blast from the past.
PETER FRIESE: Yeah, so you had a chat
with Adam Koch, Nick Butcher.
And it was about the onboarding experience.
And you gave a couple of tips and tricks
for how to do that in Android.
And I wanted to basically review a couple of things
that you talked about then and see
what has changed since then.
ROMAN NURIK: Awesome.
Yeah, I'm excited to talk about this again.
This is one of those evergreen topics
where it's hard not to talk about this in the field of UX.
PETER FRIESE: Yeah.
So the first thing that you covered
was zero state or empty state.
And maybe we can talk about that and why it's important
and how Firebase can help.
ROMAN NURIK: For sure.
So empty states or zero states are essentially
when there's no content there when usually you have,
for example, a list of notes or something.
Before the user has done anything,
you've got to show something.
Most products tend to show some piece of information,
like this is the worst, like, no results.
Nothing here.
The next step up is to show a little bit of, hey, get started
by doing this or for some sort of communication
to the user of what they can do.
One of my favorite techniques, though,
is to populate the app with sample content.
For a note taking app, a good example
is if you can take text notes and photo notes and things
like that, or drawing notes, actually,
why don't you just prepopulate it
to showcase what the app can do, all the different features,
and have the user actually interact with real content
to get a feel for what it is.
PETER FRIESE: Mm-hmm.
Do you have an example in mind of an app that
does a good job at this?
ROMAN NURIK: So forever ago, actually,
haven't onboarded into Google Keep
recently because I've been using it for a very long time.
PETER FRIESE: Sure.
ROMAN NURIK: But back then, we may have even
mentioned it in the episode.
But Google Keep did a really good job of this.
They basically showcased all the different options--
to do lists and large notes and small notes
and different colors.
And it really made you instantly understand
the value and the flexibility.
So that was a great example.
PETER FRIESE: Mm, yeah.
And then I think for getting the data into the application,
I mean, there are probably a couple of strategies
that you can use.
I think most people will probably hard
code the sample data right into the application.
That's one way.
But what you recommend from the Firebase perspective?
ROMAN NURIK: So hard coding is a simple way to do it.
The challenge there is have to do it for every platform.
So if you're making an Android version, iOS version,
you have to hard code it.
Firestore data bundles, which is something
that we released somewhat recently--
I think in the last like, two years or so, I'd say--
is a great way to basically allow you to first,
actually use your app as a developer
to make the content that you want,
and then snapshot it into a Firestore data bundle,
bundle that with your actual app across different platforms,
and then be able to essentially unpack it into a user's account
once they decide to get into the app and start using it.
PETER FRIESE: And that also gives you
that advantage of not having to pull this data
and query the database for every single of your many million
users that you hopefully have.
But you will just have to do it at once,
store the bundle somewhere on, for example, Firebase hosting
and then download it from there and not
have all those document reads.
Know the users in the app.
And one thing that I still see very many applications do
is ask the user to sign in straight away.
And I always--
I don't feel good about this.
I don't know how you feel.
But what's your recommendation for apps?
When should you ask your users to sign in?
ROMAN NURIK: So I think a lot of this
comes down to trust, right?
So if you're a big brand where users already
know who you are-- they use you on different platforms--
it may be OK, actually, to ask the user to sign a banking
app, for example.
PETER FRIESE: Right.
ROMAN NURIK: You're likely not starting,
unless you're a digital only bank or something.
You're likely not starting from the phone.
But if the user has never heard of you,
if they just read an article, and you were mentioned,
and they installed m or, they just
heard about you from a friend, if the very first thing you do
is ask the user to trust you with their Google sign in
or other information, that's expecting a lot.
And I think most folks will probably
just uninstall and say, this may not be right for me.
I'm not sure about this.
And so I think what's really important
is to establish trust.
Sometimes, that can come in the form of the user spending
some time in your app.
So if you see the user coming back to your app every--
let's say every day or so or if they've been using
the app for about 20 minutes--
these are just random numbers out there.
It's always going to vary--
if you get some signal that the users invested now,
and they, it may be a right moment,
then you can suggest to them, hey, maybe you
should sign in to store your information or sync
across devices or things like that.
But so much of it is going to come down
to when the right moment is and establishing trust
through some signals that you're getting from the user.
PETER FRIESE: Yeah, that makes sense.
But on the other hand, I mean, I guess
one reason why a lot of apps out there
say, OK, we need you to sign in the first thing
is that they need some key that they can then
use to identify the user and key the data to them.
That is the main driver or one of the main drivers
for people doing that, right?
ROMAN NURIK: Let's say you're building a Cloud Sync notes
app.
One of the things you may want to do-- you
probably don't want to ask the user to sign in right away.
PETER FRIESE: Right.
ROMAN NURIK: Right, you want them to make notes.
They downloaded you so that you can-- yeah,
so they can take notes.
But if you're pitching yourself as a Cloud Sync note app,
you probably want to think about, well,
once the user decides to sync, what am I going to do?
How do I actually get all their notes into the cloud?
One of the best ways to do this is with anonymous auth
with Firebase.
And so anonymous auth basically lets
you start forming that user identity
and start attaching real content to that without having
the user actually sign in.
But once they're ready to sign in-- once they're
ready to say you know what.
Now, I want to sync my information--
here's my Google account or my Facebook account,
whatever it is--
then it becomes as easy as just attaching that federated login
to that anonymous auth.
PETER FRIESE: Mm.
And so anonymous auth is a real Firebase account, right?
But it doesn't have any personally identifiable
information attached to it.
It's literally just the user's UVID.
ROMAN NURIK: That's right.
That's exactly right.
PETER FRIESE: Yeah, and that is why
you can use it for Firestore or for cloud storage and all
of that.
It's basically just this unique key
that's unique across your entire application.
ROMAN NURIK: Yeah, it's honestly when I first
heard about this feature like years ago,
it was just-- it blew my mind because the developer
experience for this, it just made it so easy
to solve this onboarding problem to not have
to force people to sign in.
It's just, it's a game changer.
PETER FRIESE: Yeah, I often think
not many people know about this, or not enough people
know about this.
So hopefully, after this episode,
a lot more people will start using it.
OK, so the user is on the application.
They started using the application.
They're using-- not-- well, you are using anonymous auth
to have this key.
For them, they don't really know that.
They're signed in because they're not really sign in.
But now, you want to upgrade them.
Let's talk about federated identity providers first.
So things, like Google sign in or sign
in with Apple, Facebook, and so on and so forth,
what are some recommendations for using
those federated identity providers?
And how should you make this upgrade process?
When's a good moment to tell a user, hey,
you might want to sign in?
ROMAN NURIK: You have to look at intent, right?
Once the user decides to say that, hey, you know what.
Now, I'm ready to sync--
now, I'm ready to--
I'm committed, that could be a good moment.
One of the things that I think also to think about
is how do you actually present the option, right?
I think you have to think about which providers even offer?
I think this is, it's such an interesting problem because how
people think about their identity
has evolved over the years.
Folks probably have many different federated providers
that they work with.
And I think, yeah, one of the things you always
want to be careful about is the NASCAR problem.
PETER FRIESE: What's a NASCAR problem?
ROMAN NURIK: So it's essentially when you have all the different
options available to you for sign in-- this is not
actually-- why is it called the NASCAR problem is if you ever
watching a NASCAR race, you'll see all the cars have a billion
sponsor logos all--
PETER FRIESE: Yeah, I see.
Yeah.
ROMAN NURIK: And it's just super overwhelming.
PETER FRIESE: Oh, yeah.
ROMAN NURIK: It's super overwhelming.
One of the things to think about is
what are the most popular providers for your users?
Really understanding users is really important
there to understand where for your specific user
base, which are the most common, most popular providers?
PETER FRIESE: Mm-hmm.
So would it be a good idea, for example, to say on Android,
I'm going to use Google sign in, and on iOS, I'm
using sign in with Apple?
ROMAN NURIK: Yeah, that's a good baseline.
That's actually likely a requirement.
Actually on the Apple side, I believe it's a requirement.
I could be wrong.
PETER FRIESE: On Apple, if you use any federated identity
provider, you also need to support sign in with Apple.
ROMAN NURIK: It goes further than that.
I think it's likely the iOS users are going to expect that.
Android users are going to expect Google sign in.
It's just part of the expectations.
I think that that's a really good baseline.
I would say start there.
But also consider for different demographics,
for different audiences, folks are
going to be also really comfortable with Facebook sign
in or Twitter sign in.
For developer products, GitHub sign in.
So it really is going to depend.
I think the most important thing is
understand the requirements on the platform
and understand your user.
PETER FRIESE: Oh, and one thing that's probably also
a pretty good idea is if you are available on multiple
platforms, support all the sign in mechanisms
on all of the platforms, right?
I mean, if I sign in using Google on an Android device,
and then maybe I've got an Android phone but an iPad,
I want to sign in there.
But if the app doesn't provide Google sign in on the iPad,
I'm lost.
ROMAN NURIK: That's such a good point.
That's a really good point because I could just only--
I can only imagine, like, hey, I've
signed in on my Android phone with Google.
And then it just doesn't even show up
as an option or vice versa.
That would be really jarring.
That's a really fast way to get a lot of customer support
questions.
PETER FRIESE: Yeah, yeah, definitely.
So federated identity providers.
Another sign in mechanism I often see being used--
and I often think it's being overused--
is phone authentication.
So I often think, oh, people use it because they can.
But I'm interested.
What's your perspective?
When would you recommend that people actually
use phone authentication?
ROMAN NURIK: I think it really comes down to two things.
The first is, again, going back to-- this
is maybe a broken record as a user experience professional.
But the first thing is understanding your users.
I think depending on your users, where they're located.
Their region.
What their cultural norms are.
What the norms are in the country.
Their demographics.
The Gen Z folks are almost going to expect phones.
Other folks are not going to expect it.
I think that so much of it depends
on what your users' expectations are and where
they are in the spectrum of it must exist.
I must be able to login versus I actually do not
want to login with my phone.
There's a wide array.
The second is about use case.
There are some product use cases or some types of products where
phone off will not make sense.
Can you imagine if in as part of logging into the Firebase
console, we force you to put in your phone number.
PETER FRIESE: Oh, it would be pretty stupid, I think.
ROMAN NURIK: It would be so weird.
But at the same time, if you're a ride ridesharing or food
delivery app, the whole experience
revolves around the phone.
And so I think thinking about what does the phone actually
mean as part of the broader experience of using
the product?
I think that is another key factor.
So understand your users, what their expectations are,
as well as understand or form an opinion
on where the phone actually fits into the products.
PETER FRIESE: Mm-hmm.
One challenge that I've seen with phone authentication--
and that's another reason why personally for me, I
think it doesn't make sense for many, many cases--
is that when you're moving from one country to another one
or even if you're staying in the same country,
and you're maybe you're changing your contract,
or you've got pay as you go, and then
you switch to a cheaper provider, for example,
you get a new phone number.
And I always wonder so what happens there?
And oftentimes, you would lose access to the servers.
And you would sign in using the new phone number.
And then you'd have two accounts, right?
ROMAN NURIK: The multiple accounts thing,
that is always a challenge.
I've think there's two things to keep in mind.
I think the first is never use something like a phone number
or even an email address as a primary key
because those things change.
They don't change often.
But when they do, they change catastrophically.
PETER FRIESE: And you don't want to have
all the records in the database being
keyed to your email address or through the phone number.
ROMAN NURIK: That's right.
And so that's why one of the main reasons why
Firebase authentication offers a unique or a custom
UID-- user ID.
The second thing is I think make sure that it's-- there are
flows to be able to change your phone number or change
your email address.
It all comes down to do not assume that this is permanent.
And it's hard.
I will say it is hard.
The very first time you get a customer support
request saying what is happening, like,
that's the moment you'll learn.
But I think it's important to just keep
those assumptions in check.
PETER FRIESE: The final point that I want to touch on
is email and password authentication.
Just in the previous episode, I sat down with Rachel.
And I showed her an application that I was working on.
And I implemented a beautiful sign in screen.
And it had email and password authentication.
I was super proud because it looked beautiful.
And then she told me off for using email and password
authentication.
And she said it's passwords are the worst.
And I was like, but it's so easy to implement.
And then she went down all of those things, hey,
have you thought about this, that, and verifying
the email address that actually exists and all of that.
But from a UX perspective, what do you
think about email and password?
And what's important to keep in mind?
ROMAN NURIK: It's funny.
If you look 25, 30 years ago, what were passwords?
They were one six-letter word that you can easily guess,
right, and because it was memorable, right?
And so there is a lot of value.
There's still cases today where, especially if it's not the most
important to fully secure thing, if you really need to be able
to remember something-- if user needs to remember something--
they want to have easy access to password manager,
there are limited cases--
very limited cases where that's still OK.
Believe we have come really far actually, as well, with things,
like suggested passwords for Chrome
and across Android and so on, we've
come really far to make passwords
just about as good as they can be.
But even so, even the most long and wild passwords,
they're still going to need that second factor of protection.
And so to Rachel's point, like, there
are lots of different things you need
to consider when you're rolling your own email password-based
system.
Things to keep in mind.
Are there ways to first, not necessarily require
federated login, but still use the user's email addresses
as the key?
And one of the things I love is the password list,
one-time email links that you can
do as an alternative to actually requiring
the user to store passwords.
There are a lot of great use cases for when
that makes a lot of sense.
When, especially if it's been a long time if it's not
really frequent usage, if it's been a long time since the user
logged in, they may not even have stored that password.
So just offering, hey, just click this link.
We'll email you and click it to login,
that is a really nice workflow for a lot of cases.
PETER FRIESE: It feels like magic, right?
You click on a link.
You get the email.
You tap on it, and boom, you're in the application.
ROMAN NURIK: Right.
PETER FRIESE: Yeah, yeah.
Yeah, I often think that flow might
have been invented because so many people click on I
forgot my password.
And instead of sending the reset your password,
we're now sending the link, hey, click on this link.
And you're signed in.
ROMAN NURIK: It almost feels like a forgot password
by default.
PETER FRIESE: Yep, yeah, exactly.
ROMAN NURIK: Yeah.
[LAUGHS] Yep.
PETER FRIESE: So nice to talk about all those things
and see what's changed, what stayed the same,
and those past couple of years.
And I look forward to having this conversation again
in a couple of years and see how far
we've gotten in the meantime.
ROMAN NURIK: Yeah, I'm hoping it's not a couple of years.
I'm hoping to be on camera a little bit more.
This is awesome.
I miss this.
This is cool.
But yeah, this is onboarding in authentication, in general,
is such a topic that is near and dear to my heart.
As somebody that worked on onboarding for Firebase,
I think it's so critical to get right.
And like I said in the beginning,
it's really an evergreen topic in UX.
So I look forward to come back.
PETER FRIESE: Thanks for being on the show.
ROMAN NURIK: Thanks for having me.
PETER FRIESE: And that was another episode
of "Better Safe than Sorry," the show where we teach you
how to build secure and safe applications
using Firebase authentication.
Thanks for watching, and we will see you in the next one.
[MUSIC PLAYING]