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.
Banking Change Management through User Centred Design (UCD)
There has been massive change management taking place across all sectors of British banking over the last three years. Much of this is driven by buy outs and mergers, some by efficiencies and a little more recently through questioning the nature and controls around risk management.
However simply changing the owner has caused major problems in these banks as their competitive advantage and therefore their value has been an amalgam of very different skilled people, internal processes and market penetration from the bank or group buying them. These internal processes have often evolved in a highly organic method through acquisition and proven delivery often driven by individual people. However once this people based relationship is broken and these processes are exposed to a wider audience they pose serious questions in relation to risk management, value and the continuance of revenue flow.
The standard process applied has been to pass these processes over at division level to change program managers, at department level to business analysts to define the scope of the current structure. After definition many of these process based activities are passed over to information technology to resolve. I remember being taught at University (Napier, Edinburgh) that technology should never be used as a substitute to sound business process; however this technology determinant does not seem to have been passed on to banking business people. While not the best starting point, people who work in technology do tend to ask the right questions, to define epic requirements, even when it’s unpopular with the business.
Information technology analysts take these epic requirements and define an A to Z system 'what it does'. However to get the B to Y user requirements (or stories), a user centred design analyst, ux research and designer spends time with the users to define 'how it works'. This may seem obvious to digital practitioners outside banking, but it’s a revelation to those inside banking and banking technology, that users who normally find ways around poor software are able to define the requirements that turn a useful application into a killer application.
This is not really the end, more a beginning, if other sectors can learn from banking, that users (not stakeholders, usually no longer active users) can determine the overall success of software. And that user centred design (UCD) can assure and amplify competitive advantage if underwritten by skilled practitioners, then the possibility of success is significantly raised in all software and change programs.
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.
Requirements gathering preparation
People focused
Capturing requirements is subject to other peoples availability, this remains one of the most painful parts of the process as few participants seem to understand just how important their experience is to the project. Often a participant can shape the final output without realising they have done so, I include a Show and Tell component to requirements research as it informs participants that the information provided is important, has been used and is affecting the whole project. Additionally Show and Tell is critical to validation and creating buy in. I will post more about Show and Tell later.
Screening Participants
Creating a participant profile
There are several key questions that the facilitator needs to ask themselves when preparing to do research;
- What do I need to know?
- How will I cross relate requirements sessions?
- Does this domain have it's own rule system?
- Does this domain have it's own language and is it inclusive or exclusive?
The participant profile needs to represent the answers to the above questions, a good place to look for participants is senior managers (not directors) as they still have direct reports from the bleeding edge of business but have gained a level of strategic understanding both for their area and the ebb and flow of internal politics. Dependant upon the project type an understanding of the their knowledge base (within the business or organisation) is required as it determines the weight their views should carry. Other significant factors include; length of service (often describes personal drivers), education background and level, attitudes and behaviour (tend to be observational by selectors) and social / business importance.
Selecting participants
There is a huge amount of internal politics involved in projects and often unsuitable participants are forced on projects, often as internal staff have failed to create buy in internally. I tend to work with a selection group of two to three internal people to help me understand the value each participant add to the project or the threats and risks associated with their internal agendas.
Case Study 3
I was involved with a offshore wealth management (HNW and UHNW) companies major project as a UX consultant for a new truly complex asset trading and policy construction system (a type of which I had completed before as an Enterprise Solutions Architect). I had requested but never received a profile of each participant as they had been pre-selected by the client. I had spent several days meeting people with valuable hands on experience and then I was put into an office with a Director of Sales who after 10 minutes showed an obvious controlling agenda stating "they work for me" when describing several staff members (who incidentally did not work for her). I completed the requirements gathering process and found that the Director of Sales requested other staff in the agency to work on the project. The agency involved had no specific experience in this type of system so had acquired my services specifically to work on this project. I understand they are now on to their third UX person on this project since I left, frankly the project is not standard UX and they are in deep trouble. On my side I was stunned but still think it's one of the funniest experiences I have had working with people.
In short if your standard preparation methods have been circumvented by your clients it is a clear indication that there are problems now and will be problems on the project in the future.
Usability and Accessibility Legislation
International projects should be constructed in consideration of the most stringent standards this is expected to be those pertaining to the USA, but also to include ISO9241 guidelines;
Australia
Australian Human Rights and Equal Opportunities Commission - http://www.hreoc.gov.au/
The Act provides key legal standards which inform their Disability Discrimination Act 1992 (http://www.austlii.edu.au/au/legis/cth/consol_act/dda1992264).
Their disability standards and guidelines are hosted at http://www.hreoc.gov.au/disability_rights/standards/standards.html.
Canada
Canadian Human Rights Act and the Employment Equity Act 1976-1977 (http://laws.justice.gc.ca/en/H-6/relprov.html )
Treasury board of Canada Secretariat
The Equity and Diversity Directorate of the Public Service Commission of Canada (PSC) - http://commissiondelafonctionpubliqueducanada.com/research/world_ps/canada_e.htm
Europe
The Euro Accessibility Consortium, launched in Paris on April 28th 2003 is intended to foster European co-operation toward a harmonised methodology for evaluating the accessibility of Web sites (see http://www.ddm.gouv.fr/dossiers_thematiques/documents/cisi2003f.html). This initiative is a joint undertaking by 23 organisations from all over Europe and the W3C/WAI (http://www.euroaccessibility.org/).
An overview of European legislation, not specific to the Internet, is available at Horizontal European Activities in Rehabilitation Technology (HEART) http://www.w3.org/WAI/EO/heart.html.
New Zealand
New Zealand is served by the New Zealand Disability strategy administered by the Office for Disability issues (http://www.odi.govt.nz/nzds/).
United Kingdom
In the UK, the legislative initiatives are aligned with the Disability Discrimination Act and equal opportunities directives.
- Disability Discrimination Act (DDA) 1995, 1999 - www.disability.gov.uk - http://www.disability.gov.uk; http://www.disability.gov.uk/dda/index.html; http://www.legislation.hmso.gov.uk/acts/acts1995/1995050.htm
- Disability rights commission act 1999 - http://www.legislation.hmso.gov.uk/acts/acts1999/19990017.htm
Special Educational Needs and Disability Act (2001) - http://www.dcs-gb.net/part4dda.html
United States of America
In the United States there is strong governmental support that has led to about 11 pieces of disability legislation. The key legislation, the Americans with Disabilities Act (ADA, 1990) which applies to all walks of life was effected in 1992 during the George Bush (Snr) administration.
- Americans with Disabilities Act (ADA) 1990; 1995 - http://www.usdoj.gov/crt/ada/
- Section 508 of the US Rehabilitation Act (1986; amended 1998) - http://www.usdoj.gov/crt/508/508home.html
- Workforce Investment Act 1998 - http://usworkforce.org
Report on application of ADA - http://www.rit.edu/~easi/law/weblaw1.htm
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