(lively music) (applause) - Thanks, thanks very much, Josh.
Geez, these headset microphones, you put it on Katya or Sonya and they look like pop stars. You put one on Josh and he looks like he's hosting some glamorous awards night.
You put it on a bald man and it looks like I'm addressing a prison riot.
(laughter) I don't know. Thanks, it's good to be back at Web Directions it's been quite a while since I was last here. I'm gonna talk about stories so yeah, yeah, you've sat through God knows how many conference talks about the power of storytelling.
And you've deliberately skipped over a bunch of medium articles about storytelling. I want to talk specifically about how we use stories in the design process and about a specific use of stories and that's about kick-starting design or getting our design over speed bumps.
We used to call it scenario-based design that's not so trendy anymore but I will probably interchange those two terms as we go.
Let's talk, look at something that's familiar to us, the Double Diamond design.
I say familiar to you guys, but if you guys looked really closely at this thing before, I mean I zoomed in the other day on just the middle part, and have a look at this.
The diamonds don't meet up.
(laughter) And it turns out there's a reason for that because there is a gap that we need to leap over between diamond number one and diamond number two. I'm gonna oversimplify today and just call them the research diamond and the design diamond. Don't hate me, it's a good simplification for our purposes. The problem here is not a problem of poor communication from a search design, that's a different talk.
Really what I want to talk about it the shift in mindset. That we need to move from, that sort of consolidation phase of bringing together all of our insights or our learnings, generating insights, working out what is the right thing to make. And then moving into the phase of working out the right way to make it, from consolidation to elaboration.
And I've been to plenty of design kick-off workshops that have been really, really awkward because no one quite knows how to start.
Or worse, we do know what to do because we're doing the wrong thing.
And I'll come back to that in a second in terms of the wrong way to start design.
So we can refer to this as the Blank Page Syndrome. This problem of we sit down to design on the first day of design and we bring out, sometimes literally or metaphorically, the big sheet of empty flip chart paper.
And we pull out our metaphoric Sharpies and it's time to start designing.
This is a talk in itself about why there are problems here but I've just got sort of four summary points.
And the first is, the design space is too big. The thing that we have to design is big and amorphous and if we're working our job we don't even know all of the attributes of the thing we have to design yet. And yet we're supposed to sit down and start designing the thing.
And that in itself inhibits our willingness to get started. Add to that, design thinking has taught us that our first designs will be wrong.
And that's fine, but that's what design thinking says. You know, your first five, six, 12 designs, maybe not wrong but certainly won't be good enough, and that you need to keep iterating.
So, now imagine yourself in a room full of folks all with your butcher's paper in front of you and your supposed to produce your first design and hand it to the people next to you.
Well, by definition it's going to be wrong. Who wants to commit to that? Particularly in a team environment which brings me to point number three.
And this is a talk unto itself.
It's hard for a design to move forward as a team. Particularly here in Australia where, where consensus is very important to us socially. And so we've all been in those situations where designs seem to not be progressing because we're being pulled in different directions but consensus is important.
That's, and as I said that's another, that's another whole talk.
Basically this is my pitch for being invited back. Lastly, and this is the big point for today, drawing screens is the wrong place to start design. And look I'll say a little bit more about that within the slides to come but basically you know, the placement of buttons, the description of labels and you know whatever. And even sort of flow charts and things is not the right place to start doing design. And yet, a lot of techniques that we see to kickstart design, Crazy 8's being the obvious example, asked us to start by drawing stuff.
I'll probably reiterate this point.
So, the problem we have then back at the Double Diamond is, and maybe as you go you guys have seen this, we get a little bit of a traffic jam at the end of research. And there's sort of, there's sort of a reluctance to move on and in some organisations you see this, in obsessive polishing of research artefacts. It's obsessive polishing of personas or journey maps, making beautiful stuff.
Because what's going on in the research phase is everything is process driven.
There are processes to follow, there is clearly defined artefacts that we're going to create. Everyone's a lot more comfortable whereas over on the other side of the gap, we're into the undiscovered country.
We don't quite know what we're going to do, we don't quite know how we're going to do it. And so in some teams, not all teams, we get this sort of churning at the end of research. Amongst other things we've got our personas there and they're all cued up at the end and they're waiting to jump over the gap and help us out in the research phase.
Here's the thing about personas.
They're just not helping at this point.
They're just not doing anything.
They're up there with their perfect lighting and their novelty dentistry but they're not doing anything.
Now this is not a, this is not one of those rants about what's wrong with personas, that's another talk. This, you know personas are serving their purpose to date, they're consolidating everything we've learned, they're starting to ask, they're capturing attitudes and aptitudes, they're capturing snippets about how people behave today.
Our problem is, the next thing we need to do is design how people will behave tomorrow.
Our personas don't have that information embedded, how could they, we don't even know what the product is yet. But the opportunity they do present is for us to start thinking about those behaviours.
So, this is a phrase that appears in a lot of my talks. When we design new products and services, we are designing new behaviours.
We're designing new ways for people to do things or new things for people to do.
And at the end of the day that's what the design of any artefact, any product, or any service is about. And yet, when we talked, think about design even those of us who've been designing for a long time we naturally think about the placement of buttons, or the navigation through a product, or a sitemap, or a flow chart, or a drop-down menu, or the utterances in a chat bot. You know, those design artefacts, which are the expression of the product, the surface of the product.
But all of those things are only a means to an end because the thing we're actually designing is some new behaviour and the product is there to facilitate that new behaviour.
So, we can look at it this way, you can think of the design of products as a series of layers and they all each support each other. The first at the top level is the proposition. What is it we're going to make? What's the right thing to make? And then the next thing is the behaviour.
How is this thing going to fit into people's lives? How is it going to, where's it going to find its place? What's people's relationship with that product, both physically and emotionally? And then after that, comes the structure.
How the product works, how it's organised.
The interaction, how people actually manipulate the product.
And the presentation which has to do the heavy lifting of everything that's come before. The presentation design has to communicate all of the good work we've done.
But necessarily therefore, it comes last.
So this is where our personas can actually help us because the way I was trained as a designer back before many of you were born, was literally all based around scenario-based design. In a longer talk we could talk about the history of scenario-based design but it originated sort of back, well it probably came to visibility in the '80's with some work by Carroll and Rosson. Called literally scenario-based design probably too formal for us now.
Alan Cooper probably popularised it through the about Facebooks.
There's plenty of reading you can do about scenario-based design but to be honest it's not that complicated.
So, we better talk about design stories.
And I've completely lost track of the time 'cause we started a bit late, anyone? (laughter) - So what are they? Design stories, day in the life stories, there's a monitor over here.
Day in the life stories about how our customers and users will incorporate our new product into their lives, and that's it.
They're prose stories, and they're stories. They've got a beginning, some sort of context. They've got a hero, they've got some sort of call to action. Some sort of conflict or challenge that they need to overcome.
They've got a resolution so our hero overcomes the conflict or challenge.
And they've got what they call a denouement, basically a new normal where we describe at the end once the problem is being solved.
How life, what life is like now that the product helps me do a new thing or behave in a new way. What's great about writing these stories and I emphasise these are stories, we write them in prose, in sort of clicker stopped working, in once upon a time sort of format, is they help us focus on those high level things. They help us focus on fit.
How is this product going to fit into people's lives? How are people going to move through the product? Which actually that's the next point, flow. And how are people going to move in and out of the product? Because we describe a real-life situation, imagined but a real-life situation inspired by our research about where we take the persona as we know it and we project them into the future and we describe what their life is like now that they're using our product or service.
So, fit, flow and feel. The other thing that
we describe in these stories, because they're stories is how people feel about the product.
And that's something we should be designing upfront as well. What's their emotional response to the product? How do they react, how do they react to the product? And how are they motivated to use the product, what rewards them, what discourages them? So, fit, flow and feel come before function and form. The great thing about stories that I find really useful in an agile environment is that they also suggest features but they suggest them in a context sensitive way. So, if you embark on a story and you're writing a story about your persona doing a thing and you get to a point in the story and you write, and at that point Grace needs to print a copy of her ticket. Well, you've just discovered a feature along the way in the most natural possible way.
The feature's basically made an argument for it's appearance in the MVP by virtue of the fact that the story goes nowhere without this feature. And I think this is one of the great ways to sort of triage your feature set.
Is to see how stories demand those features and how they basically suggest those features of their own bat.
But what we don't do in these stories is describe the form. So we don't describe the actual interaction. We don't describe the features of the UI.
We don't necessarily say what the actual utterance of the chat bot is.
Because the presentation, the form of the product is not important yet, until we get the behaviour right. And that's why I love working with stories first rather than for example, sketching.
In fact, sketching's a great thing to do after you've got some stories.
Because the story becomes a script for a sketching exercise.
Coming back to our layers you can see how fit, flow and feel focus our attention up there at proposition and behaviour, and nudge us away from the lower level things which we'll becoming to later.
So, I'm halfway through the talk and you haven't seen one yet.
So, this is a simplified one that I'll read out for you. I should say that I wrote this story when paying for things with your phone wasn't so common. So, cut me some slack.
Lee's walking, see it, Lee's walking to his favourite ramen restaurant in the rain to collect his takeaway order when he's shocked to realise he's forgotten his wallet! Thinking he'll have to walk back home to get it, he suddenly remembers an ad from his bank that said they had recently introduced cardless cash. Lee would normally be reluctant to try something like this, there's so much that could go wrong! However, this is an emergency, so he takes out his mobile phone and logs into his bank's app.
He immediately spots a promotion for cardless cash. A quick video explains the process and the security mechanisms in place to protect his money.
Reassured, Lee proceeds to request $20, just enough to cover his meal, he doesn't want to risk any more.
Only a few seconds pass before Lee receives a text message with his unique withdrawal code. Okay, it seems to work, he thinks.
He walks to the ATM near the restaurant.
At first he wonders how he will access it without a card, but he spots a new cardless cash option on the screen. He selects it and the ATM asks for his code. He enters the code, which is confirmed by the ATM. Immediately $20 is dispensed from the ATM and that's it! The transaction's over.
Time passes.
Carrying his still-warm ramen home, Lee quickly double-checks the transaction record on his phone.
He is pleased to be banking with such an innovative, customer-centered organisation.
Now, he's a little bit cheesy but that's deliberate. You know we're not writing War and Peace here. We're writing stories not epics.
And the point of the cheesy ending is to drive home why is the product a thing and I will come to that in a sec.
So, in a longer talk we'd tease out all the elements of this but there's a few things to emphasise here. Probably two-thirds of this story is about Lee and his situation and not about the product at all. But what we try to do is interplay the product into his situation and we try to show what I call the dialogue, the exchange of information and action between the product and the user, in this case or the customer.
'Cause that's what's most important and what's most, most important is getting the flow right.
Understanding what's the natural sequence of things that would make sense for a customer in this situation. Because at the end of they day that flow is the most expensive thing to get right and it's damn sure the most expensive thing to fix if you get it wrong.
So, that's, that's where we want to start.
We can always change the label of a button later. We want to make sure we've got the right flow. Particularly in our job where we only get to do a certain, a limited amount of upfront design.
We want to spend that time in the most productive way. So, guess what, you've written a few of these stories and you've done your first design.
Your design stories are your first designs. Now, design stories can be more complicated. I just wanted to put up a more complicated example and then immediately move on.
Just to point out that, you know they're not always as simple and as potted as Lee's story. We need an obligatory story about why stories are great. I'll try and keep it quick but I am sort of, pretty passionate about this stuff.
The first one, the obvious one is that anyone can contribute to a story.
We understand how stories work, we were taught how to, how to process and then generate stories in school.
And so in a design workshop that's full of heterogeneous group of product managers and project managers and designers and coders and security experts, all of those folks can confidently and comfortably contribute to a story. So, that's a great way to get designs started without people feeling too intimidated.
But stories demand a few key features.
We have to have a hero, that hero has to have a challenge, they have to overcome that challenge.
So, that immediately puts us in the, for the story to work, puts us in the hero's shoes.
So, empathy is required in order to make a decent, or an acceptable story.
And similarly, a story has to have a beginning, middle and an end.
It has to, it has to identify a call to action, resolve that call to action and describe a new normal. That's just how you would write a story even if I hadn't of told you any of this.
Therefore, it requires us to tell a credible story of how the product works.
Because the whole end to end story has to be coherent. It's not just a random series of features.
It's a series of features strung together in a way to generate a specific outcome.
Which is the resolution.
And because our story requires a resolution it requires us to think and constantly think about why is this product any good.
Why are we making this thing and how is it going to impact the user or the customer. Couple more points, we talked about design space being to big.
Stories deliberately constrain the design space 'cause they give you permission to tell one story. So, it's not like I have to tell a story about every possible thing that could happen and what happens if the internet's down, and what happens if I forget my password.
We give ourselves permission to write one end to end coherent story.
Which is a much better way to start design than sort of starting at the top for example, and not going deep.
It's better to have a series of stories that create sort of a scaffold or a spider web through the design space that we can then build up from during subsequent iterations.
Lastly, if anyone can contribute to a story then anyone can review a story, that's for sure. So, having written a few stories we can then take them to folks for review.
Internal folks yes, but even users, users can contribute to stories as well.
But we can certainly take our stories to customers, users and get their feedback.
Does this make sense for you? Stop the story halfway through, what would you do next? Or what do you expect to happen next? So, by writing a few stories and then evaluating in stories look at that, you've done your first design iteration, you haven't drawn a single screen.
There's a larger set of rules but here's sort of four or five to get you started.
The first one is we follow a single path.
I've already said that we give ourselves permission not to worry about, but what happens in this situation? We write in prose. When I run these scenario workshops there's often a tendency to, well I'll just bullet point it or I'll just do a flow chart.
But we force ourselves to write in prose because that injects the empathy.
When we write in bullet points we sort of say feature, feature, feature, feature.
But when we write a story we have to know why did Grace do that? How did Grace feel when that thing happened? Was she nervous, or delighted, or something else? And therefore, we capture the inner monologue and this is something that is very hard to do in sketches of screens and products.
What's going on inside the user's head? How are they planning to solve this problem? How is their plan changing with new evidence as the story evolves? And how are they feeling about it emotionally? We focus as I see it on the exchange between the user and the product.
We'll work out what form the user interface takes later but for now we need to know what the user needs to know and what the product needs to provide back. In terms of information or options.
And lastly just to emphasise this, we do not describe the user interface.
And it's super tempting to do it but we never say and then Grace presses the print button. I don't know how Grace is going to print something and this is obviously a trivial example, and I don't care. If you think about our story, our Lee story, we tried very hard not to mention the UI at all. We acknowledged the ATM had a screen and that's probably the only specific element of UI we described.
We describe the interplay of information.
Lee received a code, Lee entered the code, Lee was authenticated but we didn't say what the actual operation of the UI was. So, I've got no idea how long I've taken so I might skip the first wrap-up slide which is really, the point of which being I've talked specifically about how we use scenarios to kick-start design or to overcome a design road block. But they actually have a role throughout the whole design life cycle.
Right from describing current experience through to being a script for usability testing or even a primer to the folks who have to market or support the product going forward. So, meanwhile back at our beautifully lit persona, the good news is you already know how to write stories. You've already got a set of characters sitting there for want of something to do, are possibly going to be neglected for the rest of the, rest of the project.
Let's get our personas up off their bums.
Let's make them the heroes of our design stories and use those design stories to bridge the chasm of research and design.
And that's me, thank you.
(applause) (lively music)
