NAZMUL IDRIS: Hi everyone, and welcome to "UX Design for
Developers." My name is Nazmul, and I'm a developer.
IZABEL IDRIS: And I'm Izabel, and I'm a designer.
NAZMUL IDRIS: In the first episode of the show, we
provided you with a brief overview of the user centric
design process, and why it's important for developers to
understand.
But we really didn't spend too much time going over any
specific details.
So in this episode, we're going to actually use the
process, and go through it in a pretty good amount of
detail, to actually show you how we can
better design products.
We're going to continue using the example of building a
mobile pizza ordering application to illustrate how
this process works.
The mobile pizza ordering application is a good example,
since everybody's familiar with ordering pizza, and
everybody loves it.
And it also allows us to highlight the process, rather
than the product.
So you can use this process to build any type of product,
whether it's something physical, or an API, or an
application.
So to get started, let's imagine that we have a startup
that creates local, artisanal pizza and sells it online.
And we also have a retail presence.
Now let's say that our goal is to use technology to deliver a
better pizza experience for our discerning users.
And that includes ordering pizza and, also, the actual
ingredients of the pizza, and so on.
So I'm going to, now, switch to the slides and show you the
four steps that we're going to follow to enable our startup
to create an application with a really amazing user
experience.
So the very first thing we need to ask ourselves is, what
is the goal.
Why are we doing this?
Why are we building this application?
Why is our startup doing what it does?
So setting business goals early on, and defining success
metrics for whatever product it is that we're building, is
really, really important.
So once we have an idea of why we're doing what we're doing,
the second step is everybody talks about satisfying users.
So who is our user?
We have to understand who our users
are by creating personas.
So once we have an understanding of our users,
the next thing we have to do is ask how these users are
going to use our application in different scenarios.
And those are called use casees.
So we're going to go through and actually
create a bunch of those.
And finally, we're going to take features, which we're all
used to as developers.
And then, we're going to frame the features in the context of
use cases and personas and then make sure they tie back
into the original goals that we have already defined.
And then, when we finally integrate all these pieces, we
will have a much, much better designed, solid, holistic type
of a product.
Now what we're not going to talk about is UI specifics, or
which mobile platform, like Android or iOS,
we're going to use.
Because we're in a really early stage in design.
And those types of discussions should really be tabled for a
later time, when we have the personas and the use cases
better scoped out.
So now, how do we define the goals of this project?
At the start of the project, we should just think about why
we're building an application for our startup, instead of
really focusing on the what.
As developers, we tend to really fixate on features and
how features are going to be implemented.
So we have to have some discipline and actually back
away from that and just focus on the why.
Now, let's ask questions.
The following questions, actually,
will help you identify--
will help us identify--
why we're doing this.
So why are we building this application?
What problems will it solve for our users?
And how will it improve on any pre-existing solutions?
And finally, what is our special sauce?
What do we do better than our competitors, and what makes us
really unique?
So now if we go back to the slides, this slide actually
talks about the goal.
So we're going to go through and answer some of those
questions I just asked and basically come up with a
specific set of goals that our business and our product has
to deliver.
So first of all, why are we building this application?
We're building this application to satisfy users
who are hungry for pizza.
So it's important not to get derailed by strong opinions
from individuals in sales, PM, or leadership and lose
perspective of this.
Sometimes, applications seem like they're built in the
service of certain buzzwords that your
investors might be into.
But that's not a very good idea.
So every design decision that we make should be in the
service of the user.
Another thing to keep in mind is that we have to understand
what is important to users when they're ordering pizza.
So dietary restrictions come into play.
People care about convenient delivery windows.
People care about quality versus price.
People care about the ease of ordering versus
customizability.
And of course, people care that it should be easy to pay.
So those are all parts of the goals that we're assembling,
that we're going to actually use to evaluate our design in
this episode.
And one last thing is an abstract kind of a goal.
And that is, what is our special sauce.
So our special sauce for this made up startup is the
following-- we support local farmers.
We use sustainable ingredients.
And we use sustainable business
practices to create pizza.
And we enable our users to feel connected to their
community, and make them feel good when they do business
with us, because they're giving back
to their local community.
Again these are very, very nontechnical,
pretty abstract goals.
But by the end of this episode, you'll see how we can
actually tie that to features.
Now design has to be in the service of our business, as
well as our end users.
So aside from great-tasting pizza and easy ordering via
our mobile application, this personal connection to our
business will keep customers coming back.
The user centric design process serves to remind us
that we're designing for people who make decisions
based on emotion.
So abstract goals like this can be our special sauce that
delivers delight to our intended audience.
However, it has to be weaved into our
product using good design.
So Izabel, now that I'm done talking about goals, do you
want to talk a little bit about personas?
IZABEL IDRIS: Yeah, sure.
So now that we have our goals outlined, let's talk about who
the user is.
We often hear people say, we need to make design decisions
and development decisions that are in
service of our end user.
So who is this user?
There is no real, one user.
Instead of users, we're going to think about personas.
So personas are conceptual models that represent the
demographics, the attributes, and the pain points of a
certain segment of a population--
of the pizza-eating population, in our example.
So we really need to choose personas that represent our
business goals.
And then, we're going to optimize our user experience
based on these personas, moving forward.
So what are some examples of real people in this
pizza-eating population that I'm just talking about?
Some people will eat anything.
And then, other people have dietary restrictions.
Some people think pizza should be healthy, and other people
think pizza is just junk food that you order when you don't
have time to cook.
Some people spend a lot of money on pizza, and some
people are completely value-conscious, and they just
want it as cheap as possible.
Some people expect to order pizza over the phone and then
have it delivered and pay cash.
And then, other people want a really seamless ordering flow,
an automated approach.
So let's say that's some information about our pizza
eating population.
So as a startup, which one of these-- what part of this
population--
are we going to support?
How do we turn that population into an actual persona?
So we would want to support people who think that pizza
should be healthy.
Why?
Because our startup focuses on quality, local ingredients.
So we want to focus on people who spend a good bit of money
on pizza, because one of our goals is for our startup to
support local farmers and local
community, and not to outsource.
We would also want to support people who want a seamless,
automated approach, because the whole point is we're
building a mobile app.
And we want to use technology to really facilitate a better
ordering experience.
So based on that population, or that demographics
information, those are some people that
would make up our personas.
So personas really serve to help us during the entire
product development life cycle.
It helps us with things like this-- we can prioritize user
stories in our backlog and answer the question, would it
be more important to implement feature A, or feature B. So we
look back at our personas.
And then, that can help us decide, OK, we should
implement this user story first.
It can also help us identify corner cases that can waste a
lot of time.
So we can answer the question, would 95% of our users
actually use the feature in this way, or is this going to
be something that just 1% of the users would use.
And also, one of the more intangible things is it can
really help remind us, as developers, why we're here,
why we're coding, during really long sprints.
So when we reference the personas' attributes, and
their pain points, it really puts a human context around
what we're all doing here.
So let's take a moment and look at the slides.
We're going to go through a few personas.
We're going to use the user centric design process.
This is one persona for our startup.
So let's take a minute, and look at Casey Smith.
Her tagline is "Give me control, healthy options, and
quality."
So if you notice, Casey Smith--
she shops on Amazon.
So she's already an online shopper.
She's pretty educated and tech savvy.
And she likes to use Google Wallet.
So we can tell that a seamless checkout experience would be
really important for her.
And of course, she values high quality pizza.
So now we're going to go to our second persona, which is
Sally, Sally Jones.
And her tagline is "Save me time, surprise me with
something new." So let's take a minute and look over Sally.
We can tell she's also educated and tech savvy.
And she shops at the farmers market weekly.
So she likes local, artisanal ingredients.
She likes social networking.
And she also likes high quality, healthy pizza.
We're going to go to the third persona, which is Bob Brown.
His tagline is "Save me money, and keep it old skool." So
let's take a moment to look over his persona.
So we can see that Bob prefers to pay with cash on delivery.
And he rarely shops online.
And he's a value shopper that wishes
pizza wasn't so expensive.
So I think it would make sense to support Casey and Sally,
but to drop Bob as a persona that our
startup should support.
Because his persona really doesn't fit
our business goals.
And if we tried to optimize a user experience that supported
Casey and Sally, it probably wouldn't be a good
experience for Bob.
And if we tried to create a user experience that would
really work for all three of them, it would be good for
none of them.
So it's really important that we select the right personas
from the very beginning, before we start any design or
any development.
So we can remove any the wrong personas.
And we can't satisfy everybody.
All right, so now, I'm going to talk a little
bit about use cases.
Use cases are the scenarios that describe the when, the
where, and the how that Casey and Sally are going to use our
app to order pizza.
So from use cases, we can actually start and build our
feature list.
So when we think of use cases, think about the different
physical, social, and emotional contexts that our
personas are going to be in when they order pizza, to go
from being hungry to being satisfied.
So now we're going to go back to the slides, and we're going
to look at our first use case.
So the use case for Sally--
we're going to look at the when, where, and the how.
So let's just take a moment to look at the slide.
So basically, Casey prefers to pay with credit card.
And she's kind of a picky eater.
And she places her order from home.
So we're just going to go to the second use case for Sally
and just take a moment to look over that.
So this is the use case for her placing a group order for
friends while she's at home.
So she likes to use carrier billing to place this order.
And she doesn't really have any dietary restrictions,
because she likes all kinds of different ingredients.
So we're going to go to a third use case.
And this is also for Sally.
So this is when Sally would be at work.
And she wants to order about 30 pizzas or so.
And it's going to be for all of her coworkers.
And all of them want to pay differently, and they want to
check out differently, and they want to really customize
this huge order.
So I would recommend that we remove use case number three,
because it doesn't support our business goals.
So one of our business goals was to balance the ease of
ordering and the customizability.
So if you think, how would I build a flow, how would the
screens actually look in order to build this application.
So if we were to support use case number three, it would be
really difficult to support the first two use cases and
balance ease of ordering and customizability because it
would be very difficult to support all of these multiple
checkout and payment forms.
And also, use case number three really doesn't support
one of our goals, which is to feel connected
to our local community.
So now I'm going to move over to give it over to Nazmul.
NAZMUL IDRIS: Thank you.
So now that we have our personas and use cases sorted
out, it's time to tie features to them.
Now one of those abstract, non-technical goals that we
had was that we wanted to support local farmers, use
sustainable ingredients and business
practices to create pizza.
And also we wanted to allow this application to connect
users with their community.
So how on earth do we take these abstract goals and tie
them to technology and features that fit the use
cases and personas that we've actually outlined so far?
One example of doing this would be to gamify the menu.
That means that when a user is assembling their pizza, and
they're selecting different ingredients, we could have a
little score, from one to five, that grades each
ingredient based on the localness or the
sustainability.
So for example, if you have a lot of ingredients that score
really highly on sustainability, then, when you
assemble your order, you will have an order that ranks
really high-- it gets a really high sustainability score.
So this really encourages a user that's into this sort of
thing to pick seasonal ingredients over less
sustainable choices that they might actually
desire at the moment.
So it's important to surface this information in the user
experience so that it can help the
user better make decisions.
So once they've assembled their order, and they have a
score, and it's a pretty good score, then they might want to
brag about it.
So then, we can enable this order to be shared on the
Google+ platform.
So we can do this by simply taking the order, with the
score, and just sharing it.
We can share that as a link, and it'll show up in the
user's friends stream.
So let's say I create order, I have a sustainability score of
four or something.
I can just share it to my stream.
And then, everybody in my circle will actually see that.
Now let's say I wanted to take it to the next level.
I wanted to provide some engagement and interaction
beyond just an image or a link that's shared.
What I could actually do is create a web application that
behaves as an interactive infographic that I can
actually, basically create, let's say, an order ID for
this order.
And then I can pass that, as a deep link, to something called
the Google+ interactive post.
So from my mobile application, I've created the order, I've
placed it, I have a score, I want to share the order.
I actually create an interactive post.
And what that does is, I take that order ID.
I pass it to Google+, which generates an interactive post,
which shows up on--
all the friends I have in my circles--
it shows up in their stream.
And then, when it's rendered in their stream, it says
something like, Nazmul shared this order.
Here's his sustainability score.
And then, click on this button if you want to learn more
about sustainability, and how his order ranks amongst other
people who have placed orders in the local area.
So it almost turns into an interactive kind of a game,
but you're getting more information out of it.
So we are engaging other users and making it so that I'm not
just bragging about my score.
But they're also getting an opportunity to learn more
about who else cares about sustainability in their local
region and also, how they're making an impact, how they're
actually being more sustainable, and connecting
with their community, by encouraging other people to
learn more about businesses, for example, that were all
about sustainability, that they wouldn't have even known
about, if I hadn't shared that infographic.
IZABEL IDRIS: So your business basically allows the users to
connect with their local community.
NAZMUL IDRIS: Exactly
IZABEL IDRIS: And they're going to appreciate that.
NAZMUL IDRIS: Yeah, exactly.
And also, it puts sort of a new spin on ordering food,
because it encourages participation from my friends.
So it's like, I create an order.
You see it.
You're inspired by that.
You're like, oh, I can beat that score.
So then, you create another order.
And then, we all kind of get into it.
And then, as a community, we can all get fat eating pizza,
but really healthy pizza, and also giving back to the
community, while we're gorging ourselves on pizza.
IZABEL IDRIS: And of course, it'd be great way to spread
the word about your business.
NAZMUL IDRIS: Exactly.
IZABEL IDRIS: It's kind of viral marketing, through G+.
NAZMUL IDRIS: It is, exactly.
And also, even if I wasn't interested about pizza, let's
say some random person is looking at my public posts.
And then, let's say I shared this as a public post.
Then, they'll run across this infographic thing.
They might start engaging with that.
And then, just through this random infographic about
sustainability on how sustainable my pizza is, in
Mountain View, they start learning about this business.
They start learning about sustainable farming and all
this good stuff.
So anyway, all this, put together, creates an
experience that connects our user with their community and
also creates opportunities to get new users engaged in
product and business, which was our stated goal at the
beginning of the show.
And so this illustrates how, again, we take the design
process, and how these seemingly nontechnical,
abstract goals can end up becoming one of the most
important, compelling differentiators--
the most important things that resonate with the user when
they actually interact with our application.
And in this example, because we have a startup that also
has a retail outlet, we would hope that this thinking, and
this design thinking around sustainability, would also
reflect in we actually operated the retail stores--
which, obviously, we're not going to get into for this
particular episode.
So before we wrap up, I actually had one final
question for you.
As a designer, where do you see companies skipping one of
these steps, or more than one of these steps, in the user
centric design process?
Where do they go wrong in following the process?
IZABEL IDRIS: I think the most important step that companies
are skipping is the first one, the goal setting.
This needs to really come from the leadership of the company.
They need to set the goals for what their company and what
their product stands for.
They need to define their special sauce.
And from there, each of the product teams can actually
define their personas and use cases.
And I think that product managers, developers, and
designers are all looking for that from leadership.
And if they don't have that, it's really hard for them to
know where to start from.
I personally believe that most companies can build much
better products than they do.
They just really need to take the time to ponder on and
define and really express their uniqueness.
And this might sound a little bit touchy-feely or designery,
but we really need to remember that, in the end of the day,
we're building products for people.
And people make emotional based decisions.
NAZMUL IDRIS: So essentially, to summarize--
if you don't care about what you're building, then that
shows through.
And users can tell.
IZABEL IDRIS: Yep.
If you don't care about what you're building, your users
are going to be able to feel that.
There's really no way to fake that.
So I'm going to leave you guys with a quick little exercise,
once you're done watching the video.
Maybe take the time to think about the product, or the
feature, that you're implementing right now.
And do you think that it maps back to your personas and the
use cases that have been defined?
And if you're not sure what those personas and use cases
are, check with your designers, or your product
managers, and see if you can get a hold of those.
So we're actually going to create a post on our G+
community for this episode.
And feel free to leave comments on that post.
And let us know how you did, and maybe, what you learned.
And I think that's it.
And we're going to wrap up.
And thanks for watching this episode of "UX Design for
Developers."
NAZMUL IDRIS: And remember, design is everyone's
responsibility.