Getting to grips with mobile design methods and lingo: empathy maps and storyboards
Empathy maps help project teams get into the head… or shoes of their target customer to understand how they are feeling about matters crucial to your proposition. Storyboards visualize the scenario where a user might require your mobile site/app.
Mobile (and web) design and user experience (UX), in common with most disciplines, has its own special language with an array of very useful design methods and digital tools.
These can be confusing, misunderstood and, thus, underestimated by outsiders – including the business client and other members of the project team. This needs to be fixed if mobile projects are to dedicate the time and resource to design that is required.
This and subsequent columns will introduce some of key concepts and methods used in best-practice mobile design (and many other types of project). When you get behind the jargon, most of these methods are surprisingly: low tech (or no tech); easy to understand; collaborative; can be fun; help the team better understand the project; and gets the project on the right track before development gets underway.
This column will look at two examples of useful design methods: the empathy map and the storyboard. These are usually completed with tools no more sophisticated than whiteboard, paper, marker pens, pencils and (lots of) sticky notes.
While we’re on the subject of jargon, take a look at this clever joke by Swedish design and UX expert Per Axbom:
Please remember designers/UX experts, most people – including those in your kick-off meeting – will not have a clue what many of these words mean (certainly in a design context).
If you use industry terms indiscriminately, and without clear definition, your meetings might sound – to the uninitiated, e.g. a business client – a bit like Axbom’s joke… except it won’t be as funny.
Designers* should be able to explain in plain language the meaning of and different functions of easily confused terms such as storyboards, wireframes and prototypes. These three are often used interchangeably – on the web and in practice – which adds to the general confusion. Where there are no commonly accepted definitions, the project team needs to agree its own.
* Similarly, all members of the project team should be able to explain the lingo of their profession.
Unlike mobile development, there is no industry standard design methodology for mobile projects. The design process in different companies, agencies and under different head designers varies greatly.
This places the onus on the designer/UX lead to develop and sell to the business/rest of the team the benefits of their own process.
The empathy map is a whiteboard or big-piece-of-paper-based workshop to help the project team better understand the needs and motivations – or “get into the head” – of the target customer, and thus determine what mobile product/service they might use.
The invention of the empathy map is attributed to Dave Gray, founder of US design consultancy Xplane, but many experts have made it their own since.
Typically an image of the target customer, usually named, is placed at the center of the empathy map usually surrounded six sections (see example below) in to which the team enter what they know about their subject, based on user research, testing and supposition.
The empathy map below was as a concept for a nutrition education app, “Nutrigame”, a side-project developed by UK-based UX consultant Joe Pendlebury. The map explores target customer Gail’s readiness for the app.
Among many moderations to the empathy map, is one by UK-based UX consultant and trainer Paul Boag.
Finding that his workshop attendees didn’t always find some areas of the map intuitive, he developed a revised empathy map which focuses on five sections: tasks, influences, feelings, pain points and goals (shown below).
Whether or not, you use Boag’s or traditional empathy map, his recommendation to turn the resulting map into posters that hang on the wall, is a great way to remind the team to keep the customer at center of development effort.
The storyboard is a comic-book-style, sequential visual representation of when and why the user would use the mobile service.
This method, pinched from the film business, takes the customer persona (who she is) with her empathy map (how she feels) and gives a context when she would need and use this website/app. This is typically sketched on paper.
How important is storyboarding? It’s essential, according to Greg Nudelman, CEO of design agency DesignCaffeine:
Once your project gets the green light, building a quick storyboard for essential use cases is absolutely paramount. Without this, I saw more projects fail than I care to count. No other artefact in mobile design comes close to importance of a storyboard in my opinion.
Like many of his peers, Nudelman is a massive fan of the sticky note. In his book The $1 Prototype and in his UX training courses, he makes the following recommendations (very briefly summarized) on storyboards:
A storyboard, a wireframe and a prototype walked into a kick-off meeting…
There is some disagreement, confusion and misuse of these terms, but there is some consensus around the following:
Timing: storyboarding occurs very early in the design process, then wireframing starts soon after.
There will be several iterations of both storyboards and wireframes, as the concept is tested, debated and refined. Digital prototyping comes later in the process.
Joe Pendlebury explains his storyboarding process:
Whereas empathy maps and personas help us to organize qualitative data, storyboards aid by illustrating our user stories. The storyboarding stage takes the different types of users identified through our empathy maps and personas, to highlight how they are each experiencing the problem we hope to solve.
Most importantly, storyboards allow us to see the context in which users are facing these issues i.e. where, and when, they are experiencing it – not just what they are doing at that time. Storyboards should cover two key scenarios: the existing experience, and the proposed one. Ideally, producing these for each user type identified.
At this stage, getting the experiences down on paper is key. A Sharpie (fine-tipped marker pen), a pack of Post-It Notes (sticky notes), and an A3/A2 board to post them on, is pretty much all that’s required.
Rough sketches will do, as long as they are clear enough to depict the story being told. I usually start with low-fidelity sketches (I’m no artist!), whilst trying to “brain dump” the visualizations in my head, on to paper. No doubt you’ll be screwing up a Post-It Note or two, so there’s no point being a perfectionist, at this stage. I also try to avoid adding narrative to each frame of the storyboard, as, hopefully, the sketches will speak for themselves.
Once I’ve captured the experiences, and I’m happy with them, I’ll then run them past my intended user types by doing a storyboard walkthrough, to see if they can make sense of what I’ve illustrated, and more importantly, to ensure they can relate to the story being told. I’ll document their feedback and comments on additional Post-It Notes, which I position around the outside of the storyboard itself.
At this point, you can then refine your storyboards, based on the initial feedback received from your users, with a view to producing high-fidelity equivalents, or even, digital versions. One of my favorite tools for doing this, is StoryboardThat.com.
This is Part 17 of the ClickZ ‘DNA of mobile-friendly web’ series.
Here are the recent ones: