User experience as a process
Process thinking in 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 method but rather there is an armoury of methods each with associated risks, limitations and plus points. Anyone offering a standardise method without flexibility should be ask to leave as they about to cost you a fortune.
Offering user experience services is a bit like dungeons and dragons in that you role your 12 sided dice and hope the business does not throw some trolls at you.
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.
1. Understand the problem
2. Do research
3. Analyse research
4. Get validation
5. Compose concepts
6. Create buy-in
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
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
12.1 Selection of type & method
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 & Visual design integration
13. Functional specification & analytics specification
- Pass to development
14. Usability Test plan
15. Accessibility Test plan
16. Functional & Content Test plan
17. Testing handover with participant screening document
18. Review testing results
19. Modify labels, interactions & structure in line with findings
20. Done, until .....
21. Check interactions based upon analytics and more user testing.
22. Offer enhancements to clients.
Requirements gathering methods determine value
There are lots ways to elicit UCD requirements so I don't intend on listing them all here, what I will note are some of the effective ways that I utilise. They can be described as structured, unstructured or a mixture of the two, but importantly the methods produce differing depth of requirements dependant not only on the method but on the skill of the facilitator and the characteristics of physical location used. In effect the method used is limited by the capability of the facilitator.
Research Structure
It is critical to determine if there is enough usable information around the project to be able to establish a valid research start point. Get the questions right and the answers follow, get the questions wrong and you’ll waste a fortune. If your unsure carry out a pilot study to find out what the questions are.
Methods
Observational / Reflective
Asking users to carry out their normal activities while being observed does take quite a bit of setting up so that the activity data is not skewed as a result of the observation. It is critical not to participate or lead the user. It is especially common when users are told the fine detail about the project; they will try to give you what they think you want. Often this is because they feel threatened by the process, the old notion of time and motion leading to them getting sacked is embedded in British culture. However this type of method is very useful in a pilot study to determine what type of activities should form the basis of questioning or workshop based co-creation.
Narrative
Narrative is about stories, like the narrator in a play, they see the whole thing being able to talk in the present, remind of the past, note the future or describe a similie that others can relate to even if they cannot yet relate to the main story. Asking users to describe how they think something should work, what the differences might be for different user types, how it’s done now, is there anything in other technology or experience that they can relate it to. In this way a multi-path picture can be built up from each participant for each interactive pathway within the new system or technology.
Diagnostic
Diagnostic is about testing something this will often manifest through workshops with groups of people. By setting a group a task or co-creation ‘Design the front page of your new website’ spending ‘K10,000,000 that’s Karl’s currency’ on to meet your goals and noting the group dynamic, decision making and outputs, very rich information is revealed by participants.
Show and Tell
Show and tell is imperative to feed back to participants what has happened to the information they have provided. More it can be used to validate key concepts and project directions in a fairly light environment, where participants can be highly critical knowing that everyone else is in the same frame of reference for that meeting.
Some of the Problems
Although the whole process exists to elicit information suitable to influence the project, some participants will have pet requirements that if not given the correct level of sycophantic response they will seek to invalidate the entire project as it does not represent their vision of what the project is any more. This type of attitude is very common when working with low pay low (self) risk bureaucrats, as they can personally destroy projects then blame it on 'expensive' consultants.
Case Study 4
On a national census project that was due to be run online and offline a member of the bureaucratic project team insisted that their opinions were correct on the basis of having won an award for a website ten years earlier. The opinions were very dated to the point of being bad practice, incorrect and were a constant disabler to the project. This client refused to consider an open support system, marketing website (to prepare country) or full language landing pages to support the full ethnic background of the country in question. The day to day engagement was painful, but the UX for the several forms, question logic and user interactions were eventually signed off even though the client never signed off the personas based upon the requirements they gave.
iPad Blotter App
I'm currently working on an iPad blotter app as a white label product is there any interest from financial services or investment banking companies in this product?
Lies, damn lies and user experience
User experience has in recent years become the greatest area of fraud and theft in business. The most common request for people involved in user experience is to produce wireframes (low fidelity pictures) a task that a child could do.
The rest of this is missing, but I will recover it from the archive.

