Tip:
Highlight text to annotate it
X
NAZMUL IDRIS: Hi everyone.
I'm Nazmul.
I'm a developer.
IZABEL IDRIS: And hi, everyone.
I'm Izabel.
I'm a designer.
NAZMUL IDRIS: Welcome to UX Design For Developers.
You may recognize us from I/O '13 where we did the design
lab which got a lot of great feedback.
That confirmed that there's a great demand for design
content from the developer community.
This is why we're starting this GDL series on design.
And over the coming months we're planning on bringing you
some great content on the design process, on mobile
design, platform design.
And we're planning on having some great guests
on the show as well.
This show is really for design minded developers who want to
learn how to use user centric design to build products that
deliver a great user experience and that are not
just a random collection of features.
Before we get started I just wanted to mention that we will
not be focusing on UI elements, design
guidelines, and APIs.
Instead we will focus purely on user experience.
So I wanted to set the stage and talk briefly about why
it's important for developers like us to engage in the
design process.
We really need to think about building products rather than
just focusing on delivering features
on a release schedule.
As developers, we understand what it means to have velocity
in implementing feature requests.
However, we rarely get to see how our final products are
used by real people in the real world.
And all too often we don't see our contribution to the final
product at all.
You might think that if you don't write front end or UI
code that you don't impact the user experience for
product in any way.
But UI and UX are not the same.
For example, when you compose an email in Gmail for Android
and you don't have network access, Gmail allows you to do
this anyway.
What Gmail does not do when you press the send button is
notify you that you don't have network access and that you
should try a different radio.
This is a great example of how good user experience is
delivered by Gmail without any UI whatsoever.
So, again, UI and UX are not the same.
UI has to do with visual layouts, colors, themes,
animations, and widgets.
While UI is important for user interaction, it is not the
only thing that's interacting with the user.
The visual and non visual code comes together to deliver the
overall user experience.
So good user experience is about removing annoyances,
needless distraction, and friction so that end users can
accomplish their tasks with ease and grace.
Google Now is a great example of this in action.
It's unobtrusive.
It does everything it needs to in the background.
And the UI is very minimal.
Google Now delivers unexpected delight by pleasantly
surprising you with relevant information just
when you need it.
We should own the unexpected delight that users feel.
We should also take responsibility
for delivering it.
The products that we build can make people happy.
So since the smartphone revolution happened a few
years ago, everything has changed.
Users have expectations of a certain level of fit and
finish, innovation and quality that comes from something
Google, Apple, or Microsoft would put in their products.
So as a third party developer, meaning that you're not in the
core Android or iOS or Windows platform teams, your job is
now harder because the quality of first party apps keeps
getting better and better.
So how do you stay relevant?
How do you get people to use your apps and not just install
and forget them or just ignore them altogether?
If you want a chance at success it's crucial for you
to keep the end user in mind and to create a compelling
user experience for them.
Now I'm going to show you some examples of
good UI and bad UX.
This will help you further disambiguate
one from the other.
We can all agree that user account creation and login or
the bane of our existence.
When was the last time you looked forward to creating yet
another account on a website you may or
may not visit again?
So let's take a second to admire this nice account
creation form.
Now, as a developer you're probably thinking, I made it
validate all the fields, it's mobile friendly, the form has
a great UI.
It's legible.
It's got lots of padding.
And it's nicely laid out.
But this is probably what your user's thinking.
I just tried a demo of your product and it's exactly what
I've been looking for.
I wanted to get the full version right now.
So why am I being punished by having to fill out this
massive form?
So how do you resolve this?
The right way to do this, of course, is to use something
like G+ sign in so your users can create an account in a
matter of seconds.
By removing friction from the login process, you can make
sure that you're not getting in the way of gaining another
user for your product.
So here's another example.
Online shopping is another thing that we all do.
And here's a check out flow that everyone should be
familiar with.
Just take a second to admire the length of these forms.
There's a lot of information for a user to fill out.
Now, as a developer you might be thinking, I've collected
all the data I need in order to make the API calls to the
fulfillment and payment back ends.
And from a UI perspective it's a great form.
Lots of detailed information has to be collected and it's
pretty clearly layed out.
Now, this is probably what your user's thinking.
I spent a lot of time and effort
adding stuff to my cart.
And I'm trying to spend a lot of money on your website.
But had I known I'd have to do all this paperwork, I would
have probably not used this website.
But since I'm already vested, why do I feel like checking
out is as painful as doing my taxes?
So how do we result this?
One way to do it is to use Google Wallet so that your
users can pay for their stuff in a matter of seconds.
By removing friction from the all important checkout flow,
which is essentially where you're getting paid, your
user's more likely to come back and buy
more stuff from you.
So here are a few more best practices that you should
consider in order to deliver the best possible UX in the
products that you're working on.
On mobile devices the quality of network
connectivity varies greatly.
So it makes sense to think about what your application
can do in offline mode.
For example, Gmail on Android allows you work offline and
you can view your downloaded emails and compose new ones.
Once network connectivity is restored, Gmail silently syncs
everything without notifying or bugging the user.
Now, the user's attention span is also a precious resource.
So we should use it wisely.
Design applications so that if the user is distracted in any
moment, they can return to your application
without much friction.
A great example, again, is Gmail.
It continuously saves emails in the background when you're
composing them so if you leave the app for any reason you'll
never lose any work.
If your app is loading a lot of data, you might consider
pre fetching chunks of it that might be needed soon.
This way the data will be ready when the user needs it
and there's no lag or delay in the user experience as they
move forward.
Similarly, for any data you might have already fetched,
it's a good idea to cache it for some period of time in
case that the user wants go back to it, that way there
won't be any lag or delay when the user goes back.
I'm going to hand it off to Izabel now.
IZABEL IDRIS: All right.
Now we're going to talk a little bit
about the design process.
So Nazmul's covered some best practices.
So let's talk about how we can actually create amazing user
experiences that delight our users.
So how do you go about doing this?
Well, by using the user centric design process.
So what is this user centric design process?
Well, I'm going to give you a brief overview of the process,
which has been adapted for developers.
First off, the design process begins with user research.
So user researchers go out in the world and they get a sense
for what users expect from technology and a sense of
their frustrations when these current expectations aren't
met by current products they're using.
They also give you insights into what your users want, and
they gather data from real people and define things
called personas and use cases.
So a persona is a made up user whose attributes represent
those of a larger group of real people.
So they're used as a conceptual model to drive the
design and the functionality of a product.
They're also used as a way to communicate and prioritize
feature requests amongst PMs, designers, and developers.
So it's really important to understand who your user is
and what makes them tick.
So your product can't satisfy everyone all the time.
So you need to design for specific personas and keep
those in mind.
So use cases, they describe an interaction between a persona
and your product.
And they describe when, where, and how a persona actually
uses the features of your product.
So as developers, we usually think of
features as bits of code.
However, real users, they don't really see it that way.
So they use a set of features to accomplish a task within a
specific physical environment.
So thinking of features in terms of use cases and
personas is a really good habit for us to get into.
So as developers, we're all familiar with features.
But how do they fit in the context of a
persona and a use case?
So to answer this, let's consider a feature in the
Gmail Android app, which allows users to send emails in
offline mode when there's no network.
So lets picture a user named George, who's constantly up in
the air traveling and spends a lot of time at airports.
So while he's at the airport, Georges is using Gmail for
Android on his smartphone.
And he's doing lots of other important things.
And, of course, being at the airport, he doesn't have good
network coverage.
So if the implementation of offline mode requires Georgia,
a busy traveler, to make IT decisions while he's at the
airport then it would be an epic fail.
So George doesn't have any patience or bandwidth to deal
with IT issues about how an app should behave in online
versus offline mode.
So what Gmail for Android does is, it implements these
features without any UI whatsoever.
So in fact it actually hides from George whether it's in
online or offline mode.
So the Gmail for Android is actually a great example of
how a feature, which is composed without network, que
for delivery, and send when network is available has been
implemented really well for our persona George, the busy
traveler, and his use case, which is sending an email
while at an airport with a crappy network.
So now we know that for personas are important.
Let's look at how they're created.
So user researchers will gather a lot of data from real
people by asking them targeted questions and also by
observing them using certain technologies or products.
Then user researchers will categorize these users into
groups based on their similar attributes driven by data.
So then they give this group a name and a persona is born,
such as Casey Googler or Darth Storm.
So a persona is a target user for whom your UX is going to
be optimized moving forwards.
So here are some things to keep in mind.
You don't have to denature your persona by compositing
incompatible attributes into one persona.
So for example, you can't have a persona who is a coupon
clipping bargain shopper and who's also a foodie that
doesn't care about price.
Another example is you can't have a persona who has joined
the dark side but also uses the force.
So be careful that your design doesn't attempt to support too
many personas that are unrelated because it's going
to be impossible to build a product
that satisfies everybody.
So for example, you wouldn't want to design a car that
targets the following personas, race car drivers and
soccer moms and grandmothers.
This would be a confused car.
NAZMUL IDRIS: [INAUDIBLE] that car.
IZABEL IDRIS: So once you've decided which personas your
product is going to support, it's really important to think
about use cases or, basically, how your personas are going to
use your product in the real world.
So let's say for example your product is an app that allows
you to order pizza using your smartphone.
So let's say our persona, Casey Googler, she might use
your app in the following ways.
So her kids are hungry and screaming and
they need food ASAP.
Or maybe she's working late and she doesn't have time to
make dinner and so she needs food really fast.
Or maybe it's on the weekend and she's watching the game
with her friends and they all want to order some food.
So these are some cases Casey might have.
So a good app that supports the use case of the kids are
hungry, she'd have a quick way to order family combo meals.
And this would include a combination of best selling
pizzas, kids menu items, drinks, and
deserts all in one.
So this feature will make Casey's life really easy at
this stressful time.
So Casey's going to really appreciate the fact that
you've considered this scenario in her life when her
kids are screaming at dinner time and she's using your apps
to order food.
So you will have delivered a moment of delight for Casey.
So this is a really good example of an app whose
feature set is driven by personas and their use cases.
So personas and use cases, they go hand in hand.
And they provide a human context for features.
So as developers, we're used to seeing feature lists.
But we never really put a face to Casey Googler and we can't
really understand her pain and what she's going through when
she's using your application.
So when her kids are hungry and screaming, as a developer
we don't really understand that.
So the design process really brings us closer to our users.
And this is really the only way that we can build apps
that people love to use.
So you're probably asking where do we as developers fit
in the process?
So we tend to think of design as the domain of the designer.
And we just write code to their design specs.
So, unfortunately, this is most often the case today.
But it really shouldn't be.
So as developers, you can make sure that designs are grounded
in reality.
So through our deep knowledge and understanding of
technology, we can make sure that technological constraints
aren't violated.
So even designers create something amazing that
challenges the status-quo and breaks new ground, it's not
going to build itself.
So as developers, we bring great designs to life.
And it's our job as developers to be inspired by the new
designs and come up with innovative ways to build
software to delight our users.
So effective collaboration between teams is really
crucial to the design process.
So personas help foster effective communication
between different teams throughout the product
development life cycle by removing confusion about who
our user actually is.
And so under tight deadlines-- and we're all used to this--
teams can use personas to validate decisions about which
features to cut or keep and how to
prioritize those features.
So ideally initial design should be turned into
prototypes that are tested by real
users as soon as possible.
So I'm going to hand it off to Nazmul right now to talk about
a design activity that you guys can do.
NAZMUL IDRIS: Thanks, Izabel.
So we've heard a lot about the design process.
And so we just wanted to talk about how you can actually
follow this process to design an application.
Let's say that you wanted to build an application that you
could use to order pizza online.
So we're not actually going to build this application or
design it right now.
But we will talk through the steps that you would take if
you were to design this app.
So now, again, the purpose of this application that we're
designing is to allow users to order pizza from a single
pizza parlor.
So it's not, like, seamless.
Now as developers, when we see this slide our instinct is to
start thinking about coding and APIs.
Instead of thinking about how we're going to code this up,
let's do something different today.
Let's think about why we're building this application.
We want to be a service to people who
are hungry for pizza.
We want them to get exactly what they want by using the
application.
And we want them to feel delighted to
have used the app.
We also want them to tell their friends about it.
So this sounds like marketing, but this is actually the
result of a good user experience.
It's important for us as developers to stay connected
to what we're trying to accomplish here, which is to
use technology to create compelling experiences in the
service of user.
This is a message that often gets lost in the rush to get
features implemented and released out the door ASAP.
So let's think about the persona and use case that we
will design for.
So now imagine the perfect pizza application.
What would it look like?
How would people use it?
When, where, and how would people use it?
So think about the people and use cases that you're going to
optimize the user experience for?
Then let's think about building a flow that your
users will follow so they can go from being
hungry to being satisfied.
The flow of screens should support the list of features
that neatly fit in the context provided by your personas and
your use cases.
So let's think about how we would even define an
application's persona.
So it's very important to keep these personas handy, by the
way, so even after you've created them you can always
reference them later on as you design and even implement your
application.
So in order to create personas let's
think about a few questions.
So here's just a few questions that you might think about to
help identify attributes that help define this person.
So, for example, in the context of pizza do they value
convenience over price or do they bargain shop and are only
concerned with price?
Do they have a credit card?
Do they use Paypal or Google Wallet?
The answers to these questions will determine what
technologies you use in the application.
Do they have dietary restrictions?
And, again, this will affect the types of menus that you
display, not user interface menus but actual food menus.
Do they shop online often?
Do they primarily do this using a smartphone or a laptop
or a tablet?
So, for example, this can help you differentiate the design
for your smartphone application from your tablet
application.
So on the smartphone it's more actionable.
The user experience should be more actionable where they can
place an order and go pick it up.
On a tablet it might be more research oriented where
they're considering what to eat and then they can just
place the order.
And, finally, are they comfortable or willing to
share sensitive information with your application, things
like credit card information and personal information?
So now let's talk about the flow that your persona will go
through in order to go from being
hungry to being satisfied.
It's important to think about the flow or path that your
users will take through your application and the steps that
they will need to complete even before you think about
sketching out the designs.
And the sketching has to happen before implementation.
So the first step is they're hungry.
This is the main thing motivating the user.
The want some food.
In this case it's pizza.
So the second step in this flow should be where they can
create an order.
They might have dietary restrictions.
If we take this into account in our design, it would be an
opportunity to deliver delight to that persona.
And they should also decide when and where the food will
be delivered.
So the third step is very important.
They've figured out what they want to eat, and now they want
to complete the order by paying.
And this is a great opportunity, again, to deliver
delight to the user by making sure that this payment step is
super easy.
Finally, once the user is paid,
they're now owed a pizza.
They have an expectation of when the food will arrive.
And the application should ideally provide them with
accurate status information so they're aware of
what's going on.
For example, is the pizza being cooked?
Is it out for delivery?
Or perhaps the driver can't enter the property.
Now, this is a great opportunity, again, to deliver
delight by giving them the information they need without
inundating them with minute status updates.
So once you have your personas figured out and then you have
an idea of the flow, now you can think
sketching out your design.
So it doesn't have to be high tech.
You can just use index cards, post it notes, or
just sheets of paper.
Make sure, though, that you focus on the flow of the
application and not just the user interface of every
individual screen.
So we want to think about this thing as a collection of
screens, not just one screen or just a pile of screens that
aren't really connected.
Now, once you've done the initial design, you've
sketched it out on paper, go ahead and put these papers up
on a wall to depict the flow that a user would take through
your application.
It's important to get feedback on this flow from other people
early in the process.
It's essential to test out designs
before you begin coding.
Now, if possible, try to create a simple interactive
prototype using something like PowerPoint or Keynote.
You can also use something like Fluid UI to actually
create designs that you can put on your smartphone and
have a more realistic rendering of your designs
Now this is an iterative process, so don't be afraid to
make mistakes and make big changes or even start over.
This is the time when you want to make changes and test
assumptions.
It's way cheaper to do this at this stage than have to modify
code later on when you're, let's say, your application
has been released.
Now, we all make assumptions about what experience is best
for our users.
We all have gut instincts, or we have a feeling that this
would work great for us or someone like us
or someone we know.
But unless we test these assumptions by allowing actual
users to interact with prototypes, we can make some
really costly errors that will only show themselves after the
app has been built and people actually start to use it.
So to wrap up, designing great products that delight users is
what it's all about.
Great design is not just the job of designers.
It's got to be a joint effort by developers,
designers, and PM.
In the future we see developers becoming more
design savvy and designers becoming more
implementation savvy.
It's essential that we understand how the design
process works and how we fit in that story.
With our understanding of technology, we as developers
can ground designs in reality and we can also bring great
designs to life.
Now, think product, not screens or just features.
Your product is being used by real people, and you should
never lose sight of this.
Don't get bogged down in feature lists and also being
in the service only of release schedules.
IZABEL IDRIS: So it's really important that we design for
personas and use cases.
So we need to throw out personas that don't fit.
And we can't design for every one.
So we need to throw out needless features, personas,
and use cases that might hinder our user experience.
Saying no to the wrong thing is equally as important as
saying yes to the right thing.
So personas help us understand who is using our products.
And use cases help us understand when, where, and
how they're using our products.
do not try and satisfy everyone or you'll end up
satisfying no one.
We need to become a part of the design story because
design should be everyone's responsibility.
We should own the unexpected delight that our users feel
when they use the amazing products that
we build for them.
We need to take ownership of delivering this delight.
So we hope that this episode will be the start of your
journey into the world of design driven development.
We didn't cover everything in this episode.
This is just the beginning.
We're planning to do a show every month.
And so please join us on our G+ community so that we can
travel on this journey together and keep this
conversation going.
There's going to be links in the bottom in the description
of this YouTube video where you can find out where this G+
community is.
And, again, we hope to see you next month.
And until then remember, design is everyone's
responsibility.