Doing user experience

The first step in user experience needs to be the recognition that every problem is different and will require a separate solution. Because if they are not, then every business is the same which they are clearly not.

In effect there is no quick fix or standard solution method but rather there is an armoury of methods each with associated risks, limitations and plus points. Anyone offering a standardise method for user experience without flexibility should be ask to leave as they about to cost you a fortune.

I have worked with very well known agencies who are unable to get their clients to understand the importance of user experience – research, testing and design as they focus on the design component without proper understanding that it is only one part of a three stage process. The reason that clients give for not paying for research and testing is the assumption that user experience people a such great experts that they can do their job in total isolation from the business and the end users. Maybe ‘Super User Experience Person’ does exist but I doubt it, more importantly users change.

Some process steps for user experience

This process list is based on personal experience and is open to reduction or extension based upon just how savvy the client is and how must they really want to be successful rather than just being seen to be doing something.

PART A
1. Understand the problem (better to appear to be stupid, than to actually be so) UX reserves the right to ask stupid question to avoid doing stupid things.
When trying to find out what the problem is try to get an associative answer, what else that they see is it like.
What other businesses and systems are they similar to them? What works for these other people?
What insights do the clients have to the problem and where do they want to end up?
What are their perceived expectations and what are the levels they see as Resolution, Gain or Advantage.
Don’t skew or try to influence the client in what’s wrong or imply the solution is simple (that’s just rude).

2. Do research find out what the problem means, don’t assume that your understanding is the correct one.
Language is fascinating in how it drives understanding, but understanding is also a derivative of culture and personal experience. If you grew up in the same family, house and town as your client you would have many cultural touch points in understanding ‘what things really mean’. But you may still be wrong as you can’t see through someone else’s eyes or fully understand their motivation without taliking to them.

3. Analyse of research with an open mind, again don’t fix the results to fit an easy answer. To analyse research in any area you need to define expected or hoped for results and outliers that reflect a diverse perspective. Combining and noting these variants enable a true view of the research that does not hide inconvenient perspectives.

I come across a lot of trite analysis with recommendations that reads as though the practitioner has not done any research at all.

For example the client wants to assure users that they are important to them. A trite recommendation is to;

• Enable users to complete a feedback form

Well that just tells the user the company quite insecure and most people unless they have a problem won’t respond.

How about providing;

• Confirmations
• Expected timelines
• Tracking

These are things that assure users that their issues are important to the company and therefore they are also.

4. Get validation
5. Compose concepts
6. Create buy-in

PART B
7. Define the audience (actors)
8. Create personas
8.1 Research
9. Define critical tasks
9.1 Research
10. Define key pathways
10.1 Main pathway
10.2 Alternative pathways
10.3 Failure pathways
10.4 Build sitemap (iterative process)
10.5 Select pages / interactions / responses that will be wireframed

PART C
11. Set the tone of voice
11.1 Type of language
11.2 Level of formality
11.3 Use of jargon, brand identity or subject specific words
11.4 Content style
11.4.1 Meta standards
11.4.2 Content object model
11.5 SEO if web based

12: Wireframes (iterative process)
12.1 Selection of type and method of production
12.1 Wireframe Concepts
12.1.1 User testing
12.2 Wireframe sketches – Client sign off
12.3 Wireframe prototypes
12.3.1 User testing – Client review
12.4 Wireframe and Visual design integration (template definition)

13. Functional specification and analytics specification – Pass to development

PART D
14. Usability Test plan
15. Accessibility Test plan
16. Functional and Content Test plan

17. Testing handover with participant screening document
18. Review testing results

PART E
19. Modify labels,  interactions and structure in line with findings

PART F to Z and A
20. Done, until …..
21. Check interactions based upon analytics and more user testing.
22. Offer enhancements to clients.

Related

• Getting into User Experience Part 1
• Getting UX done the engagement process
• User Experience as a process