My approach to user experience combines consideration of the emotional responses people have when they’re online with the statistical analysis of what people actually do.
When I’ve gathered that information, I make services that meet people’s needs.
I broadly use two methodologies to kick start my user experience process: I talk to people, and then I find out what they do when they’re online.
I think the most important thing to know when you start talking to people to be confident in the what questions you’re trying to find the answers to. User experience is about solving a problem, and it’s important to be able to define what challenges people are experiencing.
"How do we get more people to buy our product?", "How do we get people to trust our company?", "How can we make sure people know what we offer on our website?". These are some of the questions I’ve helped client find the answers to.
What people say and what people do, or think they do, aren’t always the same thing. They might talk about having an experience of disengagement, but be acting with engagement.
I've always found that people will tell you their motivations but show you their intentions. What you can observe people doing does not overrule what they tell you they want to do. It informs it.
Ask people what coffee they want to drink they will say "dark and strong" but give them the choice while making a coffee they will make a milky bland drink. Are they lying about what they want or are they incapable of making what the drink they want?
I'd say that the failure of a lot of a lot of user experience work is to suggest that the answer is one or the other rather than a spectrum of answers on a continuum. Some people can't make the coffee they want, some people want you to think they want a different coffee to the one they do, but most are a little of both.
My process starts with finding out as much as I can about the problems and questions poised but finding out the data is not the same as understanding it. To understand it you need analysis.
I separate research and analysis into two distinct steps rather than rolling them into one. Research is about amassing data, whilst analysis is about understanding what information is available.
A good user experience process starts with a question poised. Run a research group, fire off an poll, look at some analytics and you will gather a lot of information. Analysis is where you decide if you've got the answer to that question within the information you've gathered.
A big part of my process is to understand what research can tell me, and - if it cannot tell me enough - go back and research some more.
I can only make decisions if I understand the research I have. and that understanding comes from analysis. Analysis tells you if you have enough information, and it lets you see if you have the right information, and it lets you understand the information.
How to do this differs from project to project. Sometimes I’ve found a small room and a good colleague, and started to correlate and collate information, sticking it up on walls and grouping things together.
When I do this I can discover a piece of information and challenge it with something else. I talk about what I've discovered and debate why it might be wrong, as well as why it might be right.
My UX Process is all about understanding the people who are using a product; why they are using it, and what they are using it for.
Personas are a great way of capturing that understanding because they focus on people. A well crafted persona will tell you enough about that person, and what motivates them, that the tasks they want to perform within a product will be both obvious and easy to test against.
Tasks help when working on a smaller UX challenge - or small bits of big UX questions - because they focus on a specific outcomes without getting too far into motivations.
I find that personas are the best way of understanding people in a user experience brief. Half a dozen personas can not only inform my work, but are a really great tool for communicating to stakeholders and colleagues. Half a dozen well crafted personas will allow anyone to critique the work they are doing against what users actually need.
Personas are a tool which enable me to create user journeys. They are constantly under review and can always be improved, and are essential in understanding what a person wants from a product.
When I start my journey mapping I feel like I'm beginning to design a product.
My journey mapping is a methodical way of going through each persona and planning what they will find on each of the visits they make, whilst also determining what they want to avoid.
My User Journeys inform technical considerations as well as content planning, tone of voice and visual styling.
Each persona has a number of paths which go through a number of pages. Sometimes there is one page which suits two people, and other times a page needs to be written twice to suit the persona.
My User Journeys deliver a picture of the required pages, what users will do on those pages, and therefore what functionality those pages must have. When User Journeys overlap, I build the decision points which structure the information and guide people to the right experience for them.
My information architecture is where I pull together all my journey mapping into a site map. I have found that the traditional site map of square boxes linked together with a hierarchical structure is often inadequate as a communication tool.
I deliver sitemaps that not only show the hierarchy of pages, but also what should be contained within pages and what the hierarchy of that content should be. My sitemaps communicate:
- Where a page will sit in the overall hierarchy
- What a block of content on a page will be for, and what it’s own hierarchy within the page is
- Detail which personas will interact with which elements on a page, and what their expected behaviour will be.
The real strength of adding this detail to the sitemaps is the amount of critique and discussion they generate. Project stakeholders can see what will be on a page, and what the purpose of that content will be, and that generates integral discussions which help to improve the final product.
This is the stage where I visualise the content defined within Information Architecture to determine how the content will work.
My wireframing begins with pencil and paper so that I can get a feel of the common elements on a page, and a few of the bigger structures. I formalise these scribbles into a wireframe, and then ensure that the wireframes can’t be broken by adding the predefined content. I carry out this stress testing on different size screens to make sure that the content fits on anything from mobile to 21:9 displays.
Having ensured the wireframes don’t break, I showcase the pages with user groups. Feedback at this stage - and at every stage - is paramount in my process since refinements are most cost effective at this point in a project.
I mainly use Balsamiq for my formal wireframes, but can use almost anything as I don't include any functionality. I provide scripts on what will be an interactive element within a page, but I avoid using something like Axure's panel control to simulate those interactions.
Instead, my HTML/CSS skills allow me to create a wireframe prototype once initial feedback has been gathered, meaning I can deliver a rapid, realistic and testable experience of a finished product.
The problem with wireframes are that sometimes they are a little abstracted from the reality of how people use things.
My Prototypes are working versions of HTML pages that allow people interact with wireframes in a realistic experience. They are a working, living front end version of the wireframe that can show the effect of a click on a button, the speed that effect will be enacted in, and the impact that effect has on the page.
Prototypes are especially useful with responsive web design where elements of the wireframes are resized or moved at smaller and larger screen sizes.
I’ve found that prototypes are the missing link in most user experience processes. Being able to test a prototype allows - for the first time - users to experience a product in an environment they are familiar with. Looking at static wireframes is often an abstract concept, but looking at a browser with some basic visuals moving around provides a familiar experience.
I find prototypes to be really useful because they feel more real for people than wireframes. Feedback on a prototype is feedback on how a product will work, not just how it will be structured.