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 structure determines success
It is an understood factor in travel that if the journey starts even half a degree wrong then the final destination will be considerably different from where the person intended to be, this is for many why there is a make do culture when working with technology requirements. Unfortunately bad requirements gathering can seriously derail a project before it really begins.
There are several types of requirements gathering research that are carried out as separate workstreams.
- Market requirements which includes competitor analysis and proof of concept.
- Business requirements, including business stakeholder perceptions and business KPI’s.
- Technology requirements often described as non functional requirements, including existing capabilities (hardware, software and skill base) and comparable technologies.
- User experience requirements which include behaviour research, KPI’s, perception research and interpretation for the specific project domain.
One of the key things to understand is that the structure and implementation of requirements gathering in each type is different even if some methods may appear the same, their interpretation and output are not. Additionally in UCD (user centred design) the method of interpretation and output are user centric rather than business centric, I find user stories a very helpful output method as it maintains user goals in a structured format that can be reused in the development process.
Case study 1
In a recent project the client requested assistance in setting up the requirements gathering process, they were intending on having groups of people from the same department together. One of the key things to understand in structuring research is the possible points at which the data can be skewed and therefore become less valid. It is human nature in a group for people to temper what is said if senior staff is present.
Instead of running the requirements gathering along department lines it was defined by UCD stakeholder roles;
- Senior managers (strategic high level thinkers)
- Managers (project capability thinkers)
- Production (detailed problem solving thinkers)
- External users (frustrated users with wide subject based experience)
- External consultants (cutting edge thinkers with wide subject based experience) as a design panel
There was also screening documents for participant selection for each role in order to assist in defining effectual research methods. Participants were sent an overview prior to sessions so that they would understand what was going to happen at very general level. In parallel an external agency was commissioned to research market requirements in the same domain and in a comparable domain. A technology audit was also carried out to support the technology requirements component.
Case study 2
In another project where the client was intending the project to effect change in multiple countries and markets requirements gathering research was conducted in several countries. The United Kingdom was used as a baseline country with adaptations defined through in person and remote research for Eastern Europe, Western Europe, USA, South America and South East Asia.
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