Published on <a href="http://ift.tt/2rH2KEd">| Prototyping: From UX to Front End &mdash; Medium</a> Emiliano Cosenza 
<h4>Why user experience design begins by telling a story.</h4>
<img alt="" src="http://ift.tt/2sm4951.">¿Por dónde empezamos? (Where do we start?) A terrific cartoon by Alberto Montt — <a href="http://ift.tt/nqeCrl">Dosis diarias</a>
When we start designing the experience of a digital product, strange happenings occur.
We have the ideas, the right people, and maybe time is on our side. It seems as if nothing else was needed. However, there is always that same question popping into one’s head: where do we start?
Discussions go around themselves, faces turn long; no one agrees. The feeling that everything’s going to infinity and beyond invades the team members, that’s until someone says:
<blockquote>-Let’s start by doing some sketches. Then we’ll take a look at the remaining use cases, fill in with the texts and that’s it.</blockquote>
The result? The product works, but that’s it. The use experience doesn’t make us feel nothing in particular and goes by unnoticed.
<img alt="" src="http://ift.tt/2slJEph.">Sonny and the NS5 have the same functionalities. But, there’s more than meets the eye regarding Sonny, isn’t there?
A long time ago, when I was 12 and I was in my last grade at primary school, there was a time when the exams of three subjects coincided in one week. There was so much reading to do, so much to take in and just a couple of days to do so that the same damn question started looming, where do I start?
I desperately went to my mum.
<blockquote>Start by the beginning, Emiliano — she answered.</blockquote>
Good joke, I thought with a smile on my face.
It took me some years to understand that behind what seems to be obvious lain the idea of sequencing. Everything we go through, what happens to us, fits in a continuum with a beginning and an end.
Does that happen with digital products? No. In general, they have numerous use cases and branches. However, user experiences, as any other experience, are linear.
If today I asked my mom where I should begin the user experience design of a product, she would probably answer the same:
<blockquote>Start by the beginning, dude!</blockquote>
It is said that one has to heed mothers… So, why don’t we think of user experience design as if it was a story? At the end of the day, it’s about designing a sequence of tasks orders in time in such a way that it promotes an enjoyable experience for people.
<h4>Why should we think of a story</h4>
Some months ago I talked to the Spanish videogames scriptwriter, Alby Ojeda, and I asked him at what moment of the design process is the script worked on:
<blockquote>-Some developer companies invest all the time and the effort in building a solid ludic base and it isn’t until the final phase that they call a scriptwriter who will write the dialogs of the story.</blockquote>
-And how does that result?
<blockquote>-I always compare that to the mess a movie would be if a production company called a scriptwriter for the first time and told them: “You see, we’ve shot these chasing scenes, some explosions and we’re finishing up two shootings. But now we’re gonna shoot the café scenes and an office one. Write an Oscar bait story on that.”</blockquote>
Alby’s comparison is spot on. We should always have it present and never leave the story design until the last minute.
Then, why should we come up with a story?
Because the story is our information architecture on the experience we are designing and our ally during the design process.
And I think they allow for:
<h4>Stories make us impersonate anthropologists</h4>
Every time someone uses our product (or the competitor’s) they are telling us a story. Thus giving us the chance to open our ears and understand many things.
To a certain extent, those stories will let us see what they need, what motivates them, how they react in the face of things, what emotions are involved, how they relate with the brand and the context in which the product is used.
<h4>Stories simplify even the most complex</h4>
My mom wasn’t the only one I went for advice to study. There also was Lorena, the smartest in the class. One morning, before a History test, I went to her to check if I was missing something. I was impressed.
— How do you remember everything?
<blockquote>I read as if it was a story.</blockquote>
She never knew it, but her answer changed the way I studied.
<img alt="" src="http://ift.tt/2rC7kbG."><a href="http://ift.tt/100BmwY">Mind map</a> on the idea of designing from a story. From this chaos came up the story I designed and constructed for the <a href="http://ift.tt/2rCm2j1">talk</a>.
Stories make connections among things more evident. In a tale it’s easier to see causal relations and it’s much more probable that we’ll remember them.
For instance, when I sat to think on a <a href="http://ift.tt/2smi6QK">talk about this very topic</a> for World Information Architecture Day, in Mendoza, I jotted down on this mind map the concepts — more or less broad — related to what I wanted to tell.
<h4>Stories help experience to be lived</h4>
Literature and video games have nailed the art of making us live a good experience. They attain an immersion level that works as a maximum security cell for our attention; it’s almost impossible to escape the tale.
Mental images engage us in what’s going on and we go through the story not noticing we’re reading, watching or playing; everything flows naturally.
When designing the user experience of a product we aim to attain the same immersion: we seek mindfulness in every task, we seek naturalness, and we seek a smooth enterprise.
Because, at the end of the day, that absence or presence of obstacles in the user experience will be what remains in the user’s memory and, some time ahead, it will allow them to judge it as good or bad. Though live the user may have enjoyed the experience, even the smallest obstacle or hassle will make them look back to it as not so good.
<img alt="" src="http://ift.tt/2rBVdf1.">
<h3>3 techniques to design the experience as a story</h3>
Before the end of this tale, let’s go back to the beginning for one second. We were mentioning the fact that we can get stuck in that fundamental dilemma over which came first the hen or the egg: where do we start designing the experience?
At the beginning!, we said.
Let’s begin by designing the experience from the start, then we move on onto the core and the ending. That is to say, let’s set out to design a complete story that will connect all the actions of the user and not just a part.
With that in mind, we need a thread: the content, that is to say, to determine what we will tell in every case, from beginning to end. No content, no story and neither will there be any experience.
<h3>Technique 1 — Content first</h3>
Let’s imagine we’re on a ship. Suddenly, we are shaken by something and we feel our feet getting soaked.
In the midst of the flight, someone shouts repeatedly:
<blockquote>Women and children first!</blockquote>
Who came up with that premise? I did a little research, but I couldn’t arrive to a conclusion. The truth is that literature has taught us that that’s the final saying: women and children should be evacuated first from a sinking ship.
What happens if we use that same idea when designing? When we start sketching screens randomly and there’s no clarity on how the flux and the experience will be, cry out:
<blockquote>Women, children, and content first!</blockquote>
And we’ll compel ourselves to define firstly what we will tell, before designing the screens or choosing the interaction components we’ll use. This will allow us to:
<ul>
<li>Understand the user’s objectives and take whatever distraction out.</li>
<li>Quickly detect issues or interaction complications to be solved.</li>
<li>Go over an idea of experience of use, before sketching something even before writing a single line of code. So that, we can fail fast and cheap.</li>
</ul>
<h3>Technique 2 — Content briefing</h3>
After executing the premise of the shipwrecks, the moment has come to open a shining blank document. And what do we write?
<img alt="" src="http://ift.tt/2slSR0C.">
My first two words always are “Content briefing”.
And what follows is a search of the answers that will work as a framework to design the story and write the content of every piece of the product.
If there are answers, there should be questions. That’s what content briefing is about, asking the questions that will help us make decisions regarding design and content. Let’s take a look at each of them:
<blockquote>Which are the objectives of the business or the product?</blockquote>
This question has a variety of uses. The main one is to briefly list the objectives we want to meet and, above all, the possible problems the users will need to have solved. If we don’t know a thing about that, merely by listing the items mentioned above will help us inquire deeper and understand where our lodestar is. In the end, the list will also be a checklist to track our progress and the objectives left to meet.
<blockquote>What’s our target like?</blockquote>
Not only at a demographic level, but also at a level where one can see the person behind the user. Ideally, it’s always good to start from a solid user research process and to get to know in depth the profiles of the people we are trying to reach. There are different ways of representing them. The <a href="http://ift.tt/1GwIr2F">Persona</a> archetype works quite well. But, if we already know the profile well, it’s also practical to describe them on a line, as if they were a character about to go on stage. For instance: “Craftsperson that works from home and uses Facebook only to sell online”.
<blockquote>What are the users’ feelings? 😄 😖</blockquote>
We are flesh and bones, but also emotions. Through them is it that we see the world and make decisions.
It’d be foolish to leave them aside when designing the content, wouldn’t it? The way in which we tell the story and the words we use have an impact on the emotions. That’s why, the question about the feelings is trying to answer which are the emotions in play around the user as if they were an aura and, at the same time, it works as some kind of guide at the moment of choosing the tone and the words for each and every piece.
So that the feelings are clear in the content briefing, I’ve been using for a while now two opposite concepts: Pain points and Moods.
<blockquote>Pain points 😖</blockquote>
Where does the shoe pinch? It’s about listing the moments when the user suffers, when the experience ceases to be any good and problems develop. And if the product is new, it doesn’t mean that the pains we’re going to alleviate are new as well; we could detect them in the competitor’s products or even in life.
It’d seem as if the pain points were the bad guys from the movie. But, as every bad guy, they also have their charm: they helps us think which are the moods we’re going to evoke and the ideas we want to communicate.
Though it seems fictional — and up to a certain point it is — , what’s advisable is to make it an informed fiction: a balance between some things we take for granted from our common sense, but with a solid and knowledgeable basis grounded on a previous user research.
<blockquote>Moods 😄</blockquote>
Mood works as a pair of glasses to interpret the world. We all know how difficult it is to motivate someone to do any given task if they happen to be in a bad mood. Or even worse, if that bad mood is a consequence of our product.
<img alt="" src="http://ift.tt/2smnVgP.">In this MailChimp’s screen, the content has been aligned to match the user’s mood.And they have turned something merely utilitarian into something enjoyable and motivating. 🙂
Let’s imagine what would happen if — on a screen, an email or any other part of a product — we used a humorous tone when it’s probable that the user isn’t in the best of the moods. And, on the contrary, how powerful it’d be if we went with their mental state.
An easy way to tone the moods we intend to provoke about our product with the ideas we seek to communicate is through the classic double-entry table.
We jot down one or two keywords that reflect or describe the moods and we juxtapose them with the promises which will help us achieve that mental state or thought.
For example, this is how we devised the moods we wanted to convey for every piece on the experience for applying for the Mercado Pago + Banco Patagonia credit card:
<img alt="" src="http://ift.tt/2rBMycu.">
With the answers about the business objectives, users’ targets and feelings, we already have a terrific framework to work on how the experience and the content of the pieces of the product will be.
A good content briefing leads to understanding among the team members which in turn translates into better feedback and useful discussions, better chances for the experience to turn out quite good.
<h3>Technique 3 — Story prototype</h3>
We’ve already decided to start by the content and we assembled a content briefing with all the necessary information to start designing the experience.
To understand what that experience will be like from end to end, we need to have clear how the story will start and finish.
And if we develop the world’s cheapest prototype? Let’s develop a <a href="http://ift.tt/2sm0bJI">content prototype</a>.
A content prototype is an early schematic version of the conversation the user will be having with the product. Instead of showing the interaction on different screens, the prototype is shown in text format.
It’s been a while now since I started developing content prototypes on different projects and I’m certain it’s useful to include them in the content briefing.
These are some of the benefits I noticed:
<ul>
<li>It’s a cheap low-fidelity technique. It requires little time and effort to execute it.</li>
<li>It focuses on the structure. We can quickly share a complete picture of the main use cases. It clearly shows where a story begins and finishes, and what to solve in the meantime.</li>
<li>It reveals the key touch points of the experience. Frictions to be done away with finally show; what needs to be simplified in the interaction and the spots where there’s room to delight the user.</li>
</ul>
<blockquote>Four-step process to build the content prototype</blockquote>
Based on what <a href="http://ift.tt/1mL1JU8">Stephanie Hay</a> recommends — head of Content, Culture and AI Design at Capital One — and on what I’ve been putting into practice until now, this is the recipe to build the story prototype:
<ol>
<li>Be clear about the user’s objective and the starting point (trigger).</li>
<li>Free yourself up to the conversation writing process of the user with the product as if it were real life. How? Imagine a play script; that’s the best way to understand how the story will unfold.</li>
<li>Tie your hands and stop auto-editing. Let it flow and focus on completing the journey.</li>
<li>Be a team player. When it’s unclear what will be designed, it’s useful to elucidate the story working together as if it were a brainstorming session.</li>
</ol>
Some examples:
<img alt="" src="http://ift.tt/2smlTxv."><a href="http://wannaplay.club/">WannaPlay</a> content prototype extract. The objective was to understand what the experience would be like, the chances it had and where to limit the scope to obtain an MVP (Minimum Viable Product). The highlighted phrases are some of the team’s comments.<img alt="" src="http://ift.tt/2rC4Fia.">Part of the content prototype of Mercado Pago’s checkout redesign in Mexico.
<h3>All good things come to an end</h3>
Roland Barthes used to say that narratives are present all throughout history and in every society.
There’s a narrative in everything we do, because we consume and produce stories from our experiences: what happened last night, how the football match was, etc.
So, if we are storytelling biological machines, why not putting its mechanics — which we’ve know from centuries back — to serve the experience of our digital products?
As we’ve seen, stories bring us closer to people, simplify even the most complex, and help us design enjoyable experiences.
Without doubt, stories are the right start. Because if we design the story the right way, we’ll design the experience the right way as well.
<a href="http://ift.tt/2sm0JPS">Originally published in Spanish</a>. Thanks a lot to Facundo Morales for the translation.
The end.
The end? Nooo… let’s keep the story going, leave your opinion or your comment.
If you liked what you read, recommend me from the heart: yours 😄 and the one down here. 💚
<img src="http://ift.tt/2rBUg6g" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2slXY0Z">Women, children, and content first</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Women, children, and content first

Why user experience design begins by telling a story.

Top Stories