User stories is another name for a cognitive walkthrough
I have been involved in Agile for a very long time, mainly because it uses methods from the human computer interaction scientific process (CHI/HCI).
I’m surprise no one else has blogged about the use of CHI/HCI processes in Agile before, but though I should say something as I keep getting told that it’s interesting how many CHI/HCI people have embraced Agile. In fact it’s the other way around we have simply re-appropriated our own techniques that have new Agile names.
The main one is User Stories; they are in fact a reuse of the Cognitive Walkthrough, but I’ll let you draw your own conclusion.
Cognitive Walkthrough is a method utilised to determine the potential usability failures within an interactive system.
The method starts with a task analysis that specifies the sequence of steps or actions required by a user to accomplish a specified task. The system response to each action is noted. The designers and developers of the software then walk through the steps as a group this enables an agreed view. They ask themselves a set of defined questions at each step to determine all the potential outcomes. Afterwards a report of potential issues is compiled and the project team has a clear focus on the various user pathways including happy paths, risky paths, error paths and failure paths.
User Stories are a quick method to determine the who, the what and the why of a business requirement and are produced in a narrative format as if a user was walking through their use of an interactive system.
User stores are written at two levels Epic Stories that define groups of functionality (registration) and User Stories that define a single piece of functionality (sign in).
User stories are written by the product owner (an Agile tile for stakeholder or product manager) a user experience architect or a business project manager (not a scrum master) or the development team when they break down stories that are too large (these are then confirmed by the product owner).
The method starts with defining the Epic stories, then breaking these down into smaller stories that relate to an encapsulated (self standing) component. In design and development these stories can be parcelled to the various specialisations including user research (end user validation, How It Works), visual design, user experience design, back-end development (feature and service delivery), security and front end development. These stories will have their interlinks (to other components) stubbed out until those stories are built and can be integrated.
Agile + CHI/HCI = User Centred Requirements, User Centred Design and User Centred Development.
They are not exactly the same but the essential method is, think like a user, describe what you can do and build the system that enables a user to complete a task or gain a feature and that is the same.
User Experience (UX) Roles vs Information Architect Roles (IA)
This is just a quick post showing the basic level differences between User Experience (UX) Roles and Information Architect (IA) Roles. I'm working on a full model post as well, but that is still being written.
User Experience (UX) Roles.
User Experience (UX) Roles Diagram
User Experience Architect (UX Architect)
Gathers requirements, defines the system features (functional specification) , user journeys, personas, interactions, sitemaps, wireframes, data models, conducts research, writes testing protocols and conducts testing.
Interaction Designer (IxD/UX Designer)
Defines interactions, sitemaps, wireframes, based on requirements from the more senior UX Architect.
User Experience Researcher (UX Researcher)
Conducts research for the User Experience Architect (UX Architect), Interaction Designer (IxD/UX Designer) or for a User Interface Developer (to apply common patterns).
Usability Tester
Works with User Experience Architect (UX Architect) or Interaction Designer (IxD/UX Designer) to define the testing formats that are conducted during research, design and development project phases.
Accessibility Tester
Works with User Experience Architect or Interaction Designer (IxD/UX Designer) to define the testing formats that are conducted during research, design and development project phases.
User Experience Tester
Conducts user acceptance testing for the experience in line with the personas and user journeys.
User Interface Developer (UI Developer)
Interprets the functional specification, sitemaps, wireframes with the aid of the User Experience Architect (UX) Architect and Interaction Designer (IxD/UX Designer) to avoid losing key featured defined for the specific audience. This is a negotiated process where the UI Developer is able to express their deep knowledge of the front end code capabilities and can be an area of conflict if the UX practitioner does not respect their capability and fully explain the reasons for the design elements.
Information Architect (IA) Roles
Information Architecture (IA) Roles Diagram
Information Architect
Gathers requirements, defines the system information features (information specification) , conducts content audits, information research, data architecture, writes tone of voice, defines taxonomy, content strategy, word based marketing strategy and content object model.
Content Auditor / Researcher
Conducts information audit of existing system (if one is there) and research into area specific language.
Taxonomist
Defines the taxonomy for the system based upon the Content Audit and Research.
Content Strategist
Writes the content strategy based upon the Content Audit and Research.
SEO, SEM, PPC Strategist
Defines the keyword structures based upon the Content Audit + Research, keyword logging and meta standards.
Content Object Modeller
Writes the content object model based upon the Content Audit + Research, Content Strategist and SEO, SEM, PPC Strategist.
Content Author / Developer
Delivers content that fills the content object model and is in line with tone of voice.
Related
- Information Architecture (IA) the classification of information
- Information Architecture (IA) the classification of information Part 2 - Educational publishing and courses examples
Save 35% ££ on banking change, requirements gathering should take no more than six months
Best practice, puting the missing part in a puzzle
Requirements gathering in Banking change programs are over detailed, over long and for the most part undeliverable.
There is and has been a huge requirement for change in British banking for several years as senior bankers have sought to lever the capabilities of technology and distributed workforces. This has in turn a great opportunity for IT consultancies to enforce their business models on the banks and make huge amounts of money without delivering anything. This has of course not gone unnoticed and forced many banks to increase their internal IT teams, but the problem remains, as the overall strategy is wrong.
The current strategy for business change requirements gathering is to fully understand the current problem with the assistance of subject matter experts (SME’s) and then defined the end state with the internal client. There are several major problems with this approach;
- Fully understanding the problem is almost endless in Banking
- Using SME assumes they really are experts which for the most part they are not
- That the internal client can see the future of their business
- That the same consultants will carry the project all the way through
The solution to this problem is a new strategy, in fact an Agile based one;
- Defining 6 to 10 features of the new system at a high level
- Involving the enterprise architects to see what has to be new, legacy or adapted
- Launch the development team during the definition phase
- Detail the features and get time costs from the designers and developers (not the PM or delivery manager)
Doing the above will change the relationship between requirements and delivery making requirements a service to the delivery of the project rather than an impossible set of promises made by people who will never have to keep them.
The 35% savings is probably low it’s just the 14 months and 35% of a budget wasted on an investment banking project that were eventually discarded. I’m considering a new concept in banking requirements gathering, value for money, is anyone interested?
You can contact me on karl@karl-smith.com
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.
Translate
Switch site
Twitter Updates
- After seeing the http://t.co/3e6fV6UA boom and bust, I know business model is important revenue is critical. http://t.co/df6Kprl2 3 days ago
- I still keep seeing graphic designed UI without any UX thinking so 'Less UX fluff and more Proof of the pudding' http://t.co/NUBfyZfx 6 days ago
- When I did my exec training in the 1990's this sort of thing was described as a key indicator of a disconnect between vision and capability… 1 week ago
- The sad thing with British Airways, I was in T5 trying and failing to book a ticket. I want to buy, they want to sell http://t.co/sg4V6mdR 1 week ago
- British Airways security update stops ticket sales « Karl Smith User Experience Architect (UEA) http://t.co/htJxLsuA via @Digg 1 week ago
- Does the 'have a go' attitude of many companies detract from real digital strategy?: http://t.co/e3KbdQjF 1 week ago
- http://t.co/HYOeiOy3 You don't allow changes during a sprint, you suspend or review tasks and put them back into the backlog, but you... 1 week ago
- Writing strategies for digitalization corporations since 2002 that have business process change, market movement, governance and technology. 1 week ago
- http://t.co/Nfmsw2lO I have been writing stratagies for digitalization for major corporations since 2002. Digital changes every day but... 1 week ago
- http://t.co/5bP9W37b UX research and design can evolve in Agile however the framework should be established 1 or 2 iteration before... 2 weeks ago