[Beeps]
[Pause]
>> Sophie Dennis: This is going to be
a super practical talk.
In my role, I do a mixture of things.
I sort of often say to normal people
that what I do is user-centered digital strategy
because they actually manage to grasp what that means.
If I start wittering on
about service design and things like this,
I see them kind of glaze over.
I sort of lead user-centered design teams
and, in particular,
do quite a bit of sort of coaching in the past
about how to integrate sort of UX
and user-centered design into Agile.
I'm currently working on quite a big,
strategic information architecture piece
with NHS Digital.
Yep.
Is that better?
[Laughter]
Okay.
I'm going to juggle.
>> Audience member: Yay!
>> Sophie: Oh, is that better?
You can hear me now.
>> Audience member: Yes.
>> Sophie: I won't --
I was just blathering on about myself.
But anyway, I was saying
I'm currently doing some work with the NHS.
Before that I've done service design roles
at the Department of Work and Pensions.
And before that I was
one of the senior principle consultants
with an agency called CX Partners in Bristol
where I worked with people
like Office of National Statistics,
Public Health England, and other people.
Today I'm going to talk about
the art of things not done.
In government work we work from
these government digital service design principles
that you might be familiar with.
The most famous one is the one,
the "Start with user needs, not government needs."
But we don't talk so much about
the second one, which is this.
It says, "Do less."
I think that's partly because
"do less" doesn't sound that great.
Why would we want to do less?
Let's do a little bit
of interactive show of hands
just for after lunch.
Who here has managed to work
on a project where they got to deliver
and seek it out into the world
everything they imagined
and hoped for and intended
in terms of the user experience?
Little rye laughs.
Who has had to compromise
on the user experience they hoped to deliver
due to time or cost constraints?
Yeah, we all have this problem.
We all have this problem.
It happens on every single project.
I've done this talk quite a few times.
I once had someone put their hand up to the first question,
and that was just like,
ahh, you're a UX god, you know.
So we need to learn to have
grown up conversations
about what compromises get made
because compromises are going to get made.
And if we don't have the language and the frameworks
to talk to people about how to cut things
that don't massively degrade the overall experience
for our users and customers,
we're not really, thoroughly doing our jobs
as user experience and user-centered designers.
And just to get it out there,
part of our job is absolutely
about the horizon scanning,
to dream the impossible dream
in terms of the user experience.
And this is the fun part, right?
It's, you know, we're ideating.
We're prototyping.
We're coming up with all the cool, new, innovative stuff.
And that is really, really important
because those sorts of visions
and concepts and concrete prototypes
that show people how the world could be
can be really, really important
for getting stakeholders
invested in making that a reality
because often that means,
you know, proper money, lots of time.
But I think we get into this danger zone
when we start to believe
that the value of all of that
and the value of user experience
is self-evident because we run in our kind of digital bubble
where doing better for users
just seems like obviously
the right thing to do.
So we need some good, solid rationale
to talk in more businessy terms to people
for when, sooner or later,
our kind of vision
of these sunlit uplands
of unending customer delight
hit up against this simple truth.
There is always more you could build
than you have the people,
time, and money for - always.
This is a quote from Jeff Patton,
and we'll come back to Jeff Patton a little later on.
I'll share with you the book where this quote comes from.
Today I'm really going to share
with you a couple of concepts,
one really super simple, but powerful tool
that I use to help teams and stakeholders
deliver great customer experiences
despite these kind of constraints
because I think that amazing design work
that sits in a drawer
is no use to anybody.
Cats sit in drawers - cute.
Design sit in drawers - waste of the time,
and the money, and energy that
you have spent working on them.
I don't think we have designed a user experience
if no user ever gets to experience it.
Let's get down to some brass tacks.
This is project management 101.
Is anybody familiar with this triangle already?
Yes, quite a few people.
Great.
If you're not, this is a great, basic thing to grasp
because project managers and everybody
will understand this already.
This says, basically,
that you can't change one of these things
without at least one of the other's giving.
It's often referred to as the iron triangle.
If you want to reduce cost,
you're going to have to cut either scope or quality.
If you want to increase scope,
so to get more features, well,
you need to increase the time and cost
or reduce the quality.
If you want to increase quality, well,
then either your cost
or your scope has got to flex.
One thing I often try and do,
and I emphasize the try,
is to establish a principle
that quality in this
is the thing that should be nonnegotiable.
This is, in a way, the thing we're all trying to deal with
is that often exactly the thing
that gets negotiated down
is always the quality because people basically
don't want to spend more money,
but they always want all the features they first thought of.
It's just human nature.
Agile has done an interesting job
of trying to address this with this idea of this definition
of done that the sort of code quality
should be nonnegotiable.
And because it's sort of code,
there are quite sort of tangible things
they can put down to day,
you know, it has to hit these quality standards,
and we have to be able to tick these boxes,
or it's not good enough.
They've done quite a good job of that.
But, in Agile, what can then sort of happen, I think,
is that often you find
it is the design and the user experience
that starts to suffer.
It's all about completing more stories,
building more features,
not about saying how do we lift this thing up.
What we need to try and do, as designers,
is to rebalance this triangle
in favor of the quality of experience.
To do that, fundamentally
we need to fight the fallacy that more is better.
This is my kind of out there fun example of this.
On the right we have a thing called the Wenger Giant.
This is officially,
as in in the Guinness Book of World Records,
the world's most functional penknife.
It contains every tool that Wenger make, 87 tools,
which provide you with 141 different functions.
It is nine inches long, and it weighs 32 ounces.
On the left--on your right as you look at it, sorry--
we have the Leatherman Micra.
The Leatherman Micra just has seven tools.
It performs ten functions.
It's just 2.5 inches long,
and it weighs only 2 ounces.
And as a result of that -- sorry.
Here's one I prepared earlier.
Hopefully, if I can find it.
I can attach the Leatherman Micra to my purse.
And in my opinion,
this makes the Leatherman Micra the better penknife
because this is the penknife that I have on me today.
And if you want a pair of scissors
or a knife blade or a little ruler,
I am your gal here.
Albeit the scissors are a little bit blunt.
There's no way I'm lugging
that thing around in my bag.
For most people, a tiny,
little Leatherman with its limited features
is fundamentally more useful
and usable than the Wenger Giant.
Obviously this is this classic tradeoff
between usability and complexity.
But often in our world it's also about
what we have the time and the money to make.
I'll give you another example
that's service based rather than product based.
I moved up to the north last year.
Before that, I spent six years
down in the southwest in Devon.
With my partner, my husband,
we ran a grassroots Web conference called Digpen,
which was a multidisciplinary conference
basically for digital makers in the southwest.
We ran seven events over four years.
By the end we were getting comments like these.
"Only being out of the country
will keep me away from the next one."
But it wasn't always like that.
Previous events had been free and,
to be totally honest with you,
they weren't always that good.
The first one that my husband and I ran
with a couple of colleagues,
we decided that, frankly,
the most we could charge people
for going to this conference
was about ten pounds
because they just weren't going to, you know,
believe that it had much more value than that.
We found ourselves asking this question.
How do you deliver a kick ass Web conference
for less than ten pounds a head?
Because what we needed to do was to build the brand,
restore trust in the event,
and then we thought,
if we did a really great job
that first year for just ten pounds,
then we could start
to increase the ticket price for the next one.
In this classic quality, scope,
cost triangle, and this iron triangle
told us that if we were trying to limit the cost,
the thing that would have to go--
and we're trying to maintain quality
because that's really important for, you know,
getting people, getting the momentum
going behind the event--
the thing we were going to have to cut was features.
And that means you end up asking questions like this.
Is a bad lunch better than no lunch?
This brings us to the first conceptual tool
that I want to share with you.
A really nice model that I find helps think through
these kind of scope, quality, cost tradeoffs,
which is a thing called the Kano model.
The Kano model basically plots features against two axes.
On the bottom--sorry you can't see it too clearly--
we have feature sophistication.
This runs from not present at all, through poor,
to kind of basic,
and right up to best of breed along here.
On the other axis we have user satisfaction
going from extremely dissatisfied,
to just sort of disappointed,
to kind of neutral user response, through satisfied,
and right up to delighted customers.
What the Kano model describes
is that we essentially have
a few different sort of ways
in which features tend to plot onto this graph.
The majority of features are linear.
These are things -- sorry.
The better the feature, the happier people are.
Customers are disappointed
if the feature is absent or poor quality.
They're only really delighted by best of breed examples.
These are referred to as one dimensional features
where performance pays off.
The labels, by the way, in the Kano model
get translated differently
because it's all being translated from the Japanese,
so you may hear them referred to slightly differently.
These are things like price,
build quality, ease of use.
If you think about a car,
you've got things like fuel efficiency,
engine power, boot space.
If I can have a cheap, incredibly well built car
that's incredibly fuel efficient,
has massive boot space,
and is immensely fun to drive
and goes like the clappers,
you know, I'm totally there.
I'm buying that car.
Obviously, as my example says,
there are tradeoffs
that consumers make about these things.
But basically the better the better.
That's all -- or in some cases, like say price;
the lower the better.
You do, however, get a few features,
which are fundamentally like this,
but give this sort of little tail here,
which is essentially customers feel neutral
if it's not present
and only really become dissatisfied
if the feature is there, but it's poor quality.
This is often sort of a feature
or an element of the product or service
that they could get elsewhere
without having it baked in.
A good example of this would be
something probably like built in SatNav.
Particularly when SatNav first
started being included in cars,
they really, really weren't very good at all.
If you were being essentially charged for that
as an extra on your car, you were probably --
or the price of your car was going up
because it had that built in,
you were probably dissatisfied with it.
Whereas actually you could go out
and perhaps just buy a SatNav and put it in.
You might actually have been better
not to have that feature there at all
than to have a bad one.
The next type of feature we need to think about
are what I often refer to as
the must haves or the basic expectation.
These are things that sometimes in UX
we refer to as hygiene factors.
The absence of these features
creates a sort of deep dissatisfaction,
as does sort of anything really
on that kind of poor quality thing.
You need to hit a basic standard
just to get people feeling essentially kind of neutral
about your product or service.
What's more, above that basic standard,
the emotional response from investing more
in more sophisticated implementations
is quite limited.
People get a bit happier,
but they won't ever be really delighted,
even by a best of breed feature.
Just to keep with our car analogy, examples,
this might be things like brakes and tires.
They're obviously really important
from a safety perspective,
but people don't get delight
from how great their brakes are
and how great their tires are.
There's a reason we sell cars
on how fast they go from zero to 60
and not how fast they go from 60 to zero,
even if you're a safety nut
and you think that's not right.
So those are your sort of basic expectations.
Then finally, we have probably the thing
that people get most excited about in the Kano model,
which is the attractive excitement generators.
The thing with these is
nobody really notices if they're not there.
Even a moderately good implementation
hitting that kind of basic line
can start to satisfy users.
And you don't have to go too far up the scale
to actually delight people
with its presence at all.
So you can sort of get --
you know, you're also getting away with a ropy version
and you don't have to go
too far to make it good.
I think, you know, an example of these
might be something like automated parking systems.
Right now I'm not bitching about the fact that --
about all the ways in which my car can't park itself.
If all it can do is reverse park into a parking space,
it can't parallel park,
I'm not cross about that.
I'm just amazed the damn thing can do it at all.
And if I don't have a car that parks itself, which I don't,
I'm not currently feeling really hard done by,
like I'm massively missing out on something.
It's very much a bonus feature.
That's a quick whiz through the Kano model.
It does just bring us back
to that sort of cash strapped, local conference.
So if you think about that sort of environment,
obviously we're all quite aware
of what a conference feels like today,
albeit we've paid a bit more than ten pounds.
Lunch is probably something like a performance feature.
The better the lunch, by and large
the happier you are as a punter.
But the absence may not necessarily disappoint,
especially if we can
effectively sort of hand off lunch to someone else.
If you're running a low budget conference
in a city center like this, you might --
so, you know, rather than slap
an extra ten quid a head on a ticket
because, you know, conference catering is,
like, madly expensive per head.
People can just maybe go off
to a coffee shop or, you know,
go down to Sainsbury's or Tesco
and buy themselves a sandwich.
That's quite a nice way,
with a budget conference, also,
of letting people sort of control their own budget
for the conference because, you know,
if people are struggling freelancers or students,
they could always bring
their own lunch or something like that.
An important thing there
is just that we've managed the expectation.
If there's not going to be a lunch,
you've made it clear there's no lunch.
Our basic expectation,
as I discovered to my peril,
is something like having drinking water available.
I hadn't known quite how annoyed people could get
by the absence of drinking water
until I didn't have it
available at a conference.
People want water available.
They want to be able to drink.
But you know what?
They don't get that much more
of an extra kick out of the very best,
you know, Perrier mineral water.
There's a limit to how delighted
someone is going to get
by the drinking water you offer.
Finally, we've got something
like excitement generators.
That might be something
like perhaps offering cake in the breaks.
We haven't got to the tea break yet,
so I don't know if there's going to be cake,
but I'm eyeing our organizers here.
Here the thing is that,
in the context of a conference,
this does not have to be the best cake ever.
You don't have to go full on Mary Berry,
some sort of three tier, iced, you know
--I don't know--
fruit tumbling down from the top of it.
You know, frankly, basic muffins,
we're all going to be p retty tuft about
if we get them in our tea break at 3 o'clock.
So, you know, even a sort of moderately good implementation
that can delight people.
But here's the funny thing about the cake.
Year one, everyone was like,
my God, there's cake.
Wow.
In year two they're kind of like, you know,
these cakes aren't as good as last year.
[Laughter]
>> Sophie: And of course
your big danger point is year three
when there's no cake at all
and you've sort of gone from,
"Wow, there's cake,"
to people expecting there to be cake
and now actually they're no longer
just neutral about it being there.
They're disappointed.
This is what we call expectation escalation.
This is described in the Kano model.
As you may have started to think
when I talked about things
like cars parking themselves,
it's that features basically go from "today, I love it"
to "tomorrow, I expect it."
They travel along that path
at some period of time.
The last time I did this talk
someone shared an example.
There's a video on YouTube
that you can look at of a guy.
He gets on the airplane.
He's like, wow, there's wi-fi.
There is wi-fi on this airplane.
He's just like completely delighted.
Half-hour in, you can imagine what happens.
The wi-fi goes a bit dodgy,
and now he's just kind of like,
"There's no wi-fi!
My wi-fi doesn't work!"
He's gone from, you know, delighted,
excitement generated,
to must have basic expectation,
in the space of 40 minutes.
Most features don't move that fast,
so we're thinking more like
something like air conditioning.
I think back in --
I'm old enough to remember this.
You know back in like 1995
when I was buying my first or second car,
air conditioning was a bonus.
We didn't absolutely expect it.
These days, the idea that you would buy a car
that doesn't have at least some form of air con, you know,
it's really hit that sort of basic expectation point,
which is why, by the way,
cars don't have sunroofs any more,
because you used to have a sunroof
so you could let the air in
instead of the air con.
Sorry, mad aside.
[Laughter]
You know it's basically the same with self-parking cars.
A year or so ago it was just amazing,
the idea that a car could park itself.
But already it's sort of becoming mainstream,
and a lot of cars now have that
sort of assistive technology.
Certainly, I think, by 2025,
we will all be just like,
"What do you mean I have to park myself
like some sort of barbarian?
This is just not acceptable."
This has an implication for brands.
I think one quite interesting thing about the Kano model
is to think about where you're
sort of brand and where your product or service
kind of generally needs to sit within this
because you get a premium brand like Apple.
Sorry, you can't quite see it on this screen.
Apple are all about occupying
that kind of top right segment of the Kano model.
It's all about best of breed features.
But the expectation escalation
means that they have to constantly innovate
to stay ahead of the curve.
You know, and you look at that, I think,
and the reaction to some of Apple's product announcements,
you know, when they come out the next year
with an incremental improvement.
The sort of big Apple fans are all kind of like,
"Apple is ruined.
Apple is lost.
It hasn't produced anything new."
There's this expectation constantly
of things getting better.
They're really good at
some of these little, delightful features, I think.
I think they've dropped it
now because of the USB,
but when the MagSafe Connector on the MacBook
first came out it was really simple.
It's not essential.
But the first time you tripped
over your power cable
and you didn't trash your expensive new Mac,
it was genuinely a delightful experience.
The other interesting thing with Apple here,
though, I think,
is how they challenge on that sort of must have curve.
So of course fairly recently
there was this infamous thing
where they dropped the headphone jack from the iPhone.
Essentially, what they're saying
is we no longer believe
that a headphone jack is an essential, must have feature.
And what's quite interesting,
there was a good article on BuzzFeed
talking about how they'd dropped the headphone jack.
And part of the reason they did that was,
they discovered if they took that component out,
which in electronic terms is quite large,
they could fit in the components they needed
for a better camera.
So what they've done is
they've traded off a must have feature
to deliver a more best of breed camera
and to enable them to do that kind of innovate,
stay ahead of the curve thing.
I think the jury is still out
on whether they're as right about the headphone jack
as they were about saying
you don't need a CD or a DVD drive in your laptop,
which was another way,
a few years ago,
they challenged those sort of expectations.
That's premium brands.
The thing I think is really interesting, though,
and we don't talk about enough
when we talk about customer experience
is actually budget brands.
I think budget brands are really fascinating
because they have to find
this really finely balanced
sweet spot on the must have curve.
Travelodge is all about saying,
"What is the least we have to do
to keep our customers happy, but not tip,"
and you can tip pretty fast,
"not tip into that bit where people are dissatisfied."
This is how they succeed because, in the end,
if I want a budget hotel,
I know what I'm going to get with Travelodge.
I'm reasonably confident
it'll be reasonably clean.
The bed certainly will be clean.
I won't have anybody else's sheets on there.
The bed will be reasonably comfortable.
The water will be hot.
I know I'm getting a kettle in my room.
Honestly, a stayed in a Tune Hotel in London.
There was no kettle.
I mean you know, there's going back to basics
and there's going a bit far,
in my opinion, as a British person who needs a cup of tea.
That's why I end up staying in Travelodges
and not cute, little B&Bs
because I'm worried that on some level
the cute, little B&B is going to have tipped over
into that not meeting my basic expectations as a guest.
This becomes really important to us
when we think about digital services
because expectation escalation
doesn't just affect this kind of new,
shiny, cool, innovative stuff.
It really massively impacts
on people's expectations on digital.
I really like Tom Loosemore
--ex of GDS and now of Coop--
his definition of digital.
He talks about applying the culture, practices, processes,
and technologies of the Internet era
to respond to people's raised expectations.
It's this way that people's expectations
of technology and digital
are constantly moving
towards that bottom left.
I think this can be really difficult
for organizations to take onboard,
particularly people who are currently lagging behind.
It seems like you're just getting
more and more behind all the time
and you have to keep up.
This is talking about kind of expectation escalation is,
I think, one way to start getting people
to sort of grasp the scale of the challenge
to really meet citizens and customers' expectations
of digital in this day and age.
That's my whistle through
the Kano model and, I think,
how you can use it to start thinking about features
and thinking about that impact on users.
But I think there's still
a danger remaining here
with the Kano model that it can
still encourage feature-itis.
You can end up with people thinking, okay, I get it.
What I need is lots of extra delighter features,
and I need to layer them on top.
I need the hundreds and thousands.
And then I need the whipped cream.
And then I need the cherry.
Otherwise no one is going to be
happy with my cupcakes.
On this level, I think, you know,
delight can be a very tricky thing
to start talking to people about
because they tend to think of it
in terms of that sort of wow factor stuff.
It's all about, you know,
sprinkling the thing on top.
The thing I direct you to,
and I'm not going to go
massively deeply into this,
is Giles Colborne,
who I used to work with at CX Partners.
I will put the slides up
so you can get these links.
He does a really great talk
about designing for delight,
which I encourage you to go and look at.
It's up on YouTube.
If you Google, this is UX Lausanne,
which is somewhere in Switzerland.
But in this he explains
that designing for delight
really isn't about trivial gimmicks and clever tricks.
It's about a deeper, more meaningful delight
where users have a strong, positive, emotional response
to your product or service,
and that you achieve that
not through adding little, delightful cherries
on the top of your product,
but through understanding the customer journey
because features don't live in isolation.
They all exist as moments
in this sort of broader user journey
that our customers are going through.
And so we need to think about the experience as a whole
and not just moments or features.
And again, because I'm all about
the little models and concepts,
something that I have found
helpful in thinking about this
is a slightly bastardization of what Daniel Kahneman,
in this book Thinking Fast and Slow,
talks about is the peak-end rule.
The peak-end rule basically says that,
in any experience,
people tend to remember the best bit,
the worst bit, and the end.
That's why it's called the peak-end rule
because it's about the peaks and the end.
This is important when we talk about delighting customers
because we're talking
not just about how they feel in the moment,
but, most importantly,
how they remember the experience afterwards.
If I'm thinking about
how do I create a great experience at my conference,
I'm not just thinking,
how do I make sure they're having a great time then,
but also how do they remember
and talk about it afterwards,
because that's where we're looking for the word of mouth,
through the buzz, the repeat use.
I want people to go home and say, you know,
I had a really super time there
and you should totally come next year
because that is an awesome event.
It's the same with any product or service.
Generally, you wouldn't want
people to spread that word.
Even if we're doing government services,
you look how many people
have been talking on Twitter
about how easy the register to vote app is.
That's an example where it's important
that people spread that message
to other people saying, you know what?
It's super quick.
It's super easy.
Go and do it.
But the reality is that
no experience is unremittingly
amazing all the way through.
What this sort of tells us
is it doesn't need to be.
You don't need to make everything amazing.
Sorry.
I've messed up this.
I knew I was going to do this.
I knew there was going to be a point
where I got surprised by my own slide animations.
Any, peak-end rule: in the context of a thing,
of a conference, it might be
an amazing speaker you haven't seen before.
Hopefully that's me.
We're not getting it at this conference,
but I think we've all been at
the one where you end up
with a half-hour sales pitch
from the sponsor masquerading as a talk.
And the end might be a solid closing keynote
or maybe a decent after party.
What we want to do, really,
is we want to amplify those peak moments.
We want to eliminate,
get rid of, the sponsor pitch
and make sure we end well.
The end doesn't have to be the highest high.
I think that's another thing.
It just has to be basically positive.
That doesn't have to be the absolute peak
of the whole event or the whole product experience.
I think the peak-end rule
is quite interesting
in thinking in terms of customer satisfaction surveys.
I don't know if you've ever looked at
sort of customer satisfaction results,
but the really weird thing
is you often get quite good
customer satisfaction results
off of transactions
and processes that you actually know,
from having sat in user research
or really just don't it yourself,
are really very painful.
And a lot of this is sort of
explained by this model because,
by the time they get to the end,
actually they've had a great experience because,
if you manage to get to the end of the transaction,
you've achieved your goal.
And to you that's good, so you may well report and say,
actually, yeah, this was fine,
even though a lot of
the rest of the process was a bit painful,
and especially if it was just a bit painful,
so it wasn't so awful
that you massively remember it.
But these are really important,
these sort of low points,
because these are your pain points in your user experience.
Often your biggest opportunity
for delighting and really satisfying your customers
is finding these pain points,
those sort of moments of anxiety,
and flipping them around.
Giles Colborne calls this anxiety effortlessly resolved.
So thinking of something like the evil Uber,
where Uber succeeds is
because it's taken away that anxiety moment
of standing on the street in a strange city
and wondering where you're going to find a cab.
If you've ever done that thing
of walking down the street in London thinking,
"I'm missing my train.
I'm missing my train.
Am I in the right point to hail a cab?"
The fact that now I can just get my app out,
press a button, a cap appears,
they've removed that anxiety about that experience,
which is why those sort of apps
are so massively popular.
[Pause]
So if we go back to our conference --
cake: we should definitely do it.
Bad lunch, get rid of it.
Eliminate it.
After party: make sure it doesn't suck
is basically your main mission there.
That's a really quick whistle through the Kano model
and customer journey mapping.
I'm just going to have a quick drink of water.
[Pause]
And I hasten to add
that I'll be the first to hold my hand up
and say this is like bastardization
of the psychological concept of the peak-end rule,
so don't mob on me afterwards.
Lastly, I'm going to share with you
a little bit about how to pull this all together
and turn it into a plan
for delivering a product and service and, most importantly,
to get the rest of the team
and your stakeholders on the side
because it's all very well you knowing this stuff.
But if you can't get other people to buy into it,
you've got a problem.
The technique I really like to use here
is one that Jeff Patton has popularized
under the name user story mapping.
Thankfully to me, he's written an entire book
about how to do it,
but it's really super simple
if you just want the basics.
If you Google The New User Story Backlog is a Map,
one of his really early Google posts,
blog post rather, is up there.
He talks about that.
This is a really great way
to visualize and communicate
your product backlog
or your idea for a product.
I really love it because it basically brings together
the idea of mapping your customer journey,
so understanding those sorts of pain points,
looking at, within that journey,
where users base the expectations
and where perhaps can you add
some of those more attractive excitement generators.
Finally, it plots that all against the idea
of an Agile backlog
or an Agile user story backlog,
which is really helpful.
I think if you're worked --
how many people here work or have worked
in sort of Agile product or service teams?
Okay.
Quite a few.
Particularly if you're working on a bigger scale product,
it gets quite hard with the backlog
to really see how is this backlog turning into a product.
A guy I saw speak at UX Cambridge,
he described it as a bit like
swimming without goggles on.
You know in Agile, you still go along
and you're all kind of like,
swim, swim, swim,
sprint, sprint, sprint,
and sooner or later you've, like, smacked into the wall,
and everybody looks up and goes,
"What have we even built here?
How does this hang together into a coherent product?"
Building a story map is a really great way
to make sure of that,
get the whole team looking
at does this thing actually make a coherent product
and a coherent experience?
Even better, it's super simple, honestly.
I'm going to explain to you
how to do it in five minutes.
We start with, ideally,
our user journey, going from start to finish.
And along the top, with Post-It notes,
you plot the high level user needs or goals.
And ideally the important thing is,
when we talk about goals and user needs,
what you're ideally looking for
is the kind of needs that remain universal
regardless of the solution that you offer.
So a good example would be something like
if you're looking at an experience map
for people buying a car.
The fundamental steps that people need to go through--
realize a need a new car,
short listing cars,
deciding which one to buy,
actually buying it--
are broadly the same
in terms of their goals today as they were 40 years ago.
It's just 40 years ago
you'd have gone and bought a magazine from Smiths
to do the sort of short listing stuff,
and today you would research it on the Internet.
That's quite a good sort of idea to keep in mind is,
do these feel universal
and a bit technology agnostic?
Then underneath each of those goals
you split out the kind of tasks and steps
that people are doing to achieve them.
This is where you might get
a little bit more technology
or product or service specific.
And finally, each of those tasks
is broken down into individual user stories
arranged in columns underneath them in order of priority.
At this point we're departing
from the classic kind of experience map model,
so these stories are features
or sort of levels of your product
that you might actually build.
As you can see, what this gives you really quite quickly
is a really visible, big picture of your product
or service describing how it fits into the customer journey,
how what the product is doing supports each task,
and how you could get
progressively more sophisticated
at basically helping somebody complete that task.
And so once you sort of roughly got this mapped out,
and you can actually get to this point.
If you have a reasonable understanding
of the journey already,
and you've done some user research
where you've got decent domain knowledge,
you can map out the top fairly quickly.
Then as a team, brainstorm this level of,
what are all the options we could have
for building these in increasing complexity.
But you really do need to do it
as a team because you need,
you know, your developers and your technical people in there,
and people who understand the progressive complexity
to sort of help you sort of map that out.
But once you've got that,
you can then talk about, okay,
how would we slice this
into some sort of current release plan?
How would we decide what to build first?
This is quite important
because you have two basic strategies for slicing.
There's the really obvious one,
which I call shallow and wide.
Shallow and wide basically takes a small,
shallow slice through everything,
focusing on the basics like that.
So essentially everything above the line
becomes your first release,
and everything below the line
is some future release.
You want to rearrange it into sort of rows
like this when you've got it
because you're going to want to move things around.
This is a little pro tip.
You're going to want to move things around,
and having to redraw that wiggly line
gets to be a right pain really quickly.
But, you know, it's helpful
just at the initial sort of thing.
You can get an initial wiggly line
and then shift them down.
That's shallow and wide.
The other one that becomes a bit less easily
to people a lot of the time,
but can also be really powerful,
is narrow and deep.
With narrow and deep,
we basically ditch entire chunks of the product
and focus on creating a better experience
of a very smaller part of the user journey.
This is similar to that idea
of sort of handing off entire chunks to something else.
It's like cutting out the lunch or not doing the SatNav.
We say right here, this is our product.
Maybe over here, that's our future product.
That's what we'll build
when we think we've got the central core going quite well.
But you know what?
Over here, that's some other product.
People can use something else
to complete this part of the task.
Yeah, maybe it's on our very, very distant future roadmap,
but it's not something we're intending
to really focus on and build right now.
Where this becomes powerful
is when you start combining
the idea of these tasks
and these features with thinking about the Kano model
and thinking about which of them deliver
the most user satisfaction.
So let's just get really basic.
Imagine we had, say, four features,
and we decided one was like a must have,
two are performance features,
and one is our attractive.
If we take our shallow and wide
and build everything to a basic level,
we basically have that's going to be kind of neutral.
Eh, there we go.
Neutral on the performance feature and neutral again.
And we might hit satisfied
with our attractive feature.
We've got a satisfied user.
They're not delighted, but it's all right.
That's kind of doing what they want.
If instead we managed to drop an entire feature set,
so let's say we decided
that this performance feature here
was one of these things
that we could hand off to something else.
Supposing we spent the time
we would have spent developing that feature
on improving our attractive feature
and did fewer things better.
[Pause]
Yay!
It's working.
We're still neutral over there.
We're still neutral over here.
But we've diverted our resources
from building a basic version of that
into building a good version
of our attractive feature.
We're still neutral over there
because it's one of these things
people aren't too bothered about.
We have to pick it quite carefully,
but we're getting delighted over there
on the right-hand side.
We've gone from having
a satisfied user with,
in theory, a similar --
I mean this is simplified,
but, in theory,
a similar level of investment and effort,
and now we're moving over to a delighted user.
To be a bit cheesy, you can think about this
as going from a sort of slightly unsophisticated idea
of a minimum viable product
to delivering a minimum viable experience
to your users
because what we have now is a minimum product
with the potential to really delight users,
to get them really excited about using it,
to get us that kind of both reengagement with them,
with them wanting to come back,
but also with them spreading the word for us,
telling their friends about it,
and turning simple users into those sort of fans
and advocates that can make such a difference,
whatever kind of product or service we're making.
As we continue to build,
we can continue potentially
to divert effort away from that neutral feature,
creating more sort of opportunities
to really satisfy and delight our customers.
This, essentially, by combining these elements together,
is how you can start to think
about delivering a positive and strong user experience
while delivering less.
Some final advice.
I've touched on some of this already.
I really recommend giving story mapping a go.
You don't need anything fancy for it.
You need brown paper, Post-It notes,
and to get your team in a room.
But I think you do need
to understand the customer journey beforehand.
A lot of people's question
with story mapping is, like,
how does this relate to customer journey mapping?
I think the answer is it sort of comes after it.
You do need to understand needs, behaviors, pain points,
all that good, user-centered practice stuff.
Use the Kano model to talk about how to deliver
the best experience while doing less.
You use that to try to get people engaged.
Okay.
What in this space are our basic expectations?
Where will we do better
just by making most things better?
Do remember that most things
are those kind of linear features.
Finally, where are those opportunities
to perhaps just do something out of the ordinary,
which doesn't always have to be innovation, you know?
Part of the reason I use that,
you know, the muffins and the tea break
is there's nothing wildly innovative
about giving people a slice of cake,
but it just lifts people's experience a little bit more.
Remember to look for those peaks and troughs
to eliminate and amplify.
Thirdly, make it a whole team activity.
Because you can honestly get through this
if you sort of know those first couple of things,
you can get through this in an afternoon.
It's not a massive ask
to ask people to just sit down for an afternoon
and plot out what your team
is going to focus on for the next six months.
You get a massive bang for buck for that investment.
As part of that, and I have worded this advisedly,
include anyone who thinks
they should make the final decision on priority and scope.
The times I've had this go wrong
is when we've left
some important stakeholder out of the room
or where we've had a slightly absent product manager,
and so we've done it as a team and then gone,
"Hey, Mrs. Product Manager.
We've worked out what we think
the backlog should be
and how to prioritize it."
And they're just like,
"No.
I'm not having that."
Someone put this to me really well.
They said it's people support things they helped to create,
and I think that's a really good, little motto
to kind of drill into your brain a little bit.
Get them involved in making it
because then they understand
the discussion and the decisions that have been made
about what's easy, about what's difficult,
and they feel invested in the process
and they'll advocate it.
Don't, for goodness sake, leave them out.
If they're super busy,
maybe get them in sort of halfway through or at the end,
but do involve them.
Finally, I mean I've basically set out the basics of it.
If you just want --
you know it's putting Post-It notes in columns and rows.
Jeff himself says he didn't think he had a book here.
He thought had, like, a three-page article.
But if you want to use this,
and particularly if you want to look more
at how to integrate Agile
and Lean UX projects together,
I do thoroughly recommend Jeff's book
because it goes into a whole lot more.
I think I just have time for my one last thing.
I hope that's been useful.
If you want to know more about it, or you want to chat,
come and grab me later,
or I guess we might have
a little bit of time
for questions after Simon's talk.
But I did want to leave you with one last thing,
which is reflecting partly on,
you know, the events of the last couple of days,
but also a little bit on some of the things
that we've heard today
because I think, you know,
I'm really fortunate to be doing
some quite big work for NHS Digital,
which feels like, you know,
making a bit of a dent in the universe.
But I haven't always been doing
those sorts of pieces of work in my career.
I've done the working on little e-commerce sites
and helping some small business set up a blog.
I think it can be easy to sit there
and see fantastic people on the stage
like Lauren and Emer
and thinking, you know,
I'm not making enough of a difference.
And so I wanted to introduce you to this:
problem definition escalation.
You don't have to escalate
the idea of what you should be doing
or the problem you should be solving all the time.
There's a really fantastic article
from when I first heard about this.
Again, you can't see the reference.
This is from, like, ten years ago,
a guy called Michael Bierut,
in an article he calls You're so Intelligent.
He says--you'll recognize this--
the client asks you to design a business card.
You respond, "The problem, you know, it's really your logo."
They say, "Okay.
That's great.
Could you redesign the logo?"
You say, "Well, I could do the logo.
But you know what?
The problem is really your entire identity system."
They say, "Okay.
Well, that's great.
Can you do the identity system?"
You say, "Well, I could do the identity system,
but I'm not sure you really understand your market,
and should we really have
a look at your business plan?"
Two steps later you're at this.
You know, it's not the problem
is making something look pretty, you fool.
It's world hunger.
[Laughter]
>> Sophie: And I think we slip into
this really, really easily
when we start talking about things like service design.
So it's really easy to go
through that pattern with something like this.
What are you doing?
Well, maybe--
I'm not working on this, by the way.
I've chosen this deliberately
as an example of something I'm not doing.
Maybe you're making it easier
to book an appointment
to get a flu jab.
You say, "Well, why are we doing that?"
You say, "Well, so that more people
will get their flu jabs."
"Why do you want to do that?"
"So fewer people end up in hospital
with severe, life-threatening flu."
And before you know it,
here we are the only people
in the world who can save the NHS.
And you go on up and up the scale,
and eventually you land
in one of my favorite quotes
when Christian Bason,
who talks a lot about
service design in government,
talking about super wicked problems.
"The nature of these challenges
are emblematic of deeply entrenched flaws
in our institutional structures,
our underlying theories,
definitions of success,
and ultimately how we have constructed our civilization."
And you know the thing is it's not that this is wrong.
It's not that Christian is wrong that this is the problem.
It's not that the entire
structure of politics government
and how we've constructed our civilization
may not be fundamentally flawed
and hopelessly preventing us
from transforming and delivering bold,
transformative change in our public services
and our civil discourse.
But somehow we've gone from designing a service to get
people their flu jabs to saving the NHS,
and now we're overthrowing the entire structure of politics,
economics, and late stage, liberal western capitalism.
And people still don't have their flu jabs.
It's fine to pick the problem
you can actually solve right now.
You don't have to keep going up the scale.
If nothing else, then eventually you will hit
overthrowing late stage,
western liberal capitalism,
and that's probably not something you can do
on your own tomorrow morning.
Sometimes you can make
more of a difference
to more people more quickly
by tackling smaller problems.
As a wise man said,
it is the small, everyday deeds of ordinary folk
that keep the darkness at bay,
small acts of kindness and love.
If you do that, you will be making a difference
and I will applaud you.
Thank you very much.
[Applause]
[Pause]
[Beeps]
For more infomation >> AMD RX Vega - The One You've Been Waiting For! - Duration: 5:43. 
For more infomation >> Words on TV for Friday, July 7 - Duration: 6:54. 
For more infomation >> Chef Mark Kingshott shares healthy options for summer - Duration: 6:30. 
For more infomation >> How to draw a cartoon cute dog art for kids so easy 😛😜💋 - Duration: 0:45. 
For more infomation >> How to draw a cartoon dog so cute art for kids easy step by step - Duration: 0:33. 
Không có nhận xét nào:
Đăng nhận xét