My name is Justin Parry and I work in Product Development and UX. This is the place where I explore things I find interesting and try to articulate things I'm thinking.
My LinkedIn page
|
 Understanding customer needs - the varying states and how they develop Frequently finding ourselves considering exactly why we’re bothering to create new things, my good friend Seb and I have made an attempt to understand and classify customer needs a little more clearly. The aim is to use this as a guide for identifying the needs states of users/customers we’re targeting.
It includes analysis of:
- The development of basic needs, via education and experience into sophisticated needs
- The types of needs which drive our decision-making, e.g. value, psychological, performance.
- The need states we often find ourselves in, e.g. immediate, latent, nascent, induced, etc.
We haven’t based this on anything scientific – and there may well be plenty of holes to pick – but it’s a tool we think is going to useful in our ongoing product development and customer experience work.
 Example of a customer experience map A practical example of experience mapping for UX strategy, including digital and real world interactions across multiple dimensions.
NOTE: Due to IP issues with my current client, I can’t publish the real version of this document right now. So let’s imagine an energy company wants to doorstep prospective customers. The concept is to persuade people to switch providers by engaging them in an analysis of daily habits, offering practical methods for reducing usage and in turn and saving energy and money. It’s all made-up, so apologies if it’s nonsense.
Download PDF version
The customer experience map displays:
- Each phase of the experience
- The timing for each phase and the project as a whole
- Specific activities and interactions detailed using a combinations of storyboard cells, simple process flows and bulleted lists
- Potential customer responses, both positive and negative, i.e. what to get right and what can easily go wrong
- High-level UI / functionality details for the corresponding digital tool
- Extra notes, including:
- How map elements plug into existing strategies and research
- An indication of the profile for those delivering the service
- Further detail on supporting documentation required for delivery
What’s the function of this document?
Experience mapping must be tied to business requirements and should ideally be founded on available research findings and business learnings. It’s not just dreamed up (“Here’s how I’d like it to be”) but is instead based on existing business methodologies and defined customer behaviour.
You do need a bit of dreaming, but that comes from imagining how all this understanding can be moulded and used to shape something as nebulous as an experience, e.g. to surprise, to inspire, to provoke thought.
You might find you have multiple versions of this document which look a little like this:
Version 1
A vision which draws on available research and business knowledge, but is aspirational and ignores constraints wherever possible. The closest-to-ideal user experience journey.
Version 2
You’ve shown it to people, gathered feedback and started to discuss implementation. The barriers and constraints reveal themselves and you draw in the scale and scope, hopefully creating a more realistic, staged path to achieving the vision. This is why Version 1 is important – vision vs. reality will reveal itself naturally through the process, but you’ve got to have a dream to being with, aintcha.
Be pragmatic about your grand vision
An experience map is a great way to:
- focus on customer or user interactions with a brand
- create a common understanding among stakeholders and project team members
- tease out experiential issues
- Establish a Northstar vision for the project
But will it really be used ongoing for the next 6,12 ,24 months of product development? Will people be pulling it out at every development meeting to ensure the vision is on track? Will it form the backbone of the roadmap for this project? Hopefully. But also maybe not. And that’s alright because everything is subject to change; propositions shift, opportunities present themselves in other places, documents and visions become dated. That’s just the way it goes.
However, even in these instances there have been times when, months down the line, I’ve dug out a document like this, swept away the dust and found that everything dreamt up has come true. This might be luck, or it might just be that the very process of mapping an experience and getting key stakeholders and players onboard ensures your vision will be threaded into the very fabric of the project.
 A snippet from my hand drawn/Omnigraffle storyboard I recently created a storyboard for Yell which aimed to visualise the entire customer experience, but wanted to be able to easily edit some of the timescales and dialogue taking place. The results were very successfully received so I thought I’d just share a tip on how I did it.
- Hand draw a bunch of cells which illustrate the key moments in the process. Don’t worry about the order or making mistakes as you won’t use this as the final deliverable – this really frees you up to just be creative.
- Take a photo of the drawings/scan them in
- Open up Omnigraffle and create the cell layout for your storyboard, e.g. how many boxes you want
- Select a box and select ‘Image’ from the Inspector
- Set your hand drawn image for the box using ‘Set image…’
- Crop/zoom into the appropriate part of your image using the Omnigraffle image tools
- Repeat steps 4-6 for each storyboard cell
- Add the dialogue balloons you need using the Dialogue Balloons stencils available over at the brill Graffletopia. I’m very anal, so I also use the Jack Armstrong comic book font to make it look the part.
- You then have the option to add in boxes to denote movements in time (e.g. next week, 10 minutes later).
- Then you’re done!
This might sound a little complicated, but it genuinely didn’t take me very long and the results were great. I can now easily change any of the storyboard components and my plan is to keep the images and create a personal library of cells which can be re-used for future UX storyboards, e.g. a phone ringing, a website on a laptop, an email being received, a person being delighted by their experience.
 Page taken from 'Why are you doing this?' by Jason I love the work of Norwegian cartoonist Jason (or John Arne Sæterøy), but I’ve never been quite sure why. Exploring this question has reinforced some simple, but useful observations for UX storyboarding.
There’s something satisfyingly Hergé-esque about the clean, visual style of Jason’s comic book work. The stories are often variations on B-movie plots (wrongly accused killer on the run, time-travelling hitman), which morph into the philosophical and occasionally profound. All very nice, but taken independently nothing to get excited about.
However, what I believe is happening here is a very powerful melding of image and text. Jason’s method of using animals to convey complex human emotions and actions makes it easier for us to identify with what’s happening to the characters and how they’re feeling. As Scott McCloud discusses in ‘Understanding comics: the invisible art‘ the more symbolic the representation, the more universal the image and the more chance of identification. He suggests we transpose our own fuzzy mental pictures of ourselves onto comics, creating a “vacuum into which our identity and awareness are pulled”.
I’ve drawn storyboards for my UX work and it’s surprising how difficult I find it to stay at the symbolic level. I always want to add a more detailed face or a certain kind of haircut; I always want to add flesh to the bones. That might be fine in context, but I guess if my intention is to engage as many people as possible (which it often is) and keep the scope for interpretation as wide as possible (which it often is), I should take a leaf out of Jason’s book and exercise a bit more freaking restraint.
My monstrous daughter Bea feasting on the remains of a bolognese.
When dealing with stakeholders, requirements are subject to frequent change, making it almost impossible to produce a document or prototype that accurately reflects their needs at any particular time. Accepting that this is the case, speedy delivery of a prototype is essential, allowing subsequent feedback to be contextualised and given structure by a tangible focus for discussion.
I recently worked on a global news platform product involving stakeholders from different operations in different countries with wide-ranging and, at times, directly oppositional issues and requirements. Internal sign-off procedures meant each iteration of the requirements definition and product specification was subject not only to this normal ‘evolution’, but also unavoidably controversial given the contrasting goals of each local operation.
Plus, we were always one step removed from the most important component: the user.
A digression on wasted research
The only method for dealing with this situation? Start building. However, this is easier said than done in a working culture dependent on expensive external development resource, overly bureaucratic sign-off procedures and strategic dithering at C-level. Without some degree of consensus on the strategic direction of a product, user-centred approach to design development seems like an expensive and over-elaborate indulgence. And it’s all too often the case that a senior management ‘vision’ of what the user wants over-rules truly insightful design and usability research. That research often ends up tucked away in a cupboard or on a hard-drive; thousands of pounds-worth of box-ticking.
Setting discussion parameters
However, I digress. So: start building. I cannot stress enough how important it is to have something tangible as quickly as possible. It’s an obvious point, but it’s worth labouring, as it’s so crucial and so easy to miss when you’re caught up in a game of who can shout the loudest. Setting discussion parameters with a prototype (or even a TST version – I know it’s wrong!) restricts the bulk of subsequent feedback to a feature set. Low-level requirements noise is reduced and those ‘essential’ missing requirements with flimsy business cases can be tagged for future releases on the product roadmap. Or sometimes just be removed and never spoken of again (again – I know it’s wrong!).
Some people will hate it (“It’s not what I asked for!”) no one will love it, but everyone will get behind it and it’ll become the framework you need to actually get it live. And then you stand a chance of delivering something people will love.
|
|
