#Agile #User #stories is a #UX #method

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

Agile has imply appropriated UX 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

Cognitive Walkthrough is a method utilised to express how the system works from a user perspective it exposes potential usability failures and defines happy and unhappy pathways

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

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, Human Centered Design and Human Centered Development.

They are not exactly the same but the essential method is,

  1. think like a user
  2. describe what you can do
  3. build the system that enables a user to complete a task or aquire a feature


Author Links

Tagged : / / / / / / / / / / / / / / / / / / /

O2 support has awful usability

O2 gets points for trying

I like other users were quite happy when O2 decided to spend some time and money to tie together their various online systems to at least give the appearance of a unified system. You can tell it’s all user experience and no information architecture though, everything links so there are no dead ends, unfortunately the information being sought is missing it’s an annoying merry go round.

Lucy help box in O2O2 fakes live support

The thing that I cannot think of an excuse for is an automated support search tool built to look like live support. Dear Lucy you gave me hope, then you took it away, you made me think O2 cared about me and the business I bring them. But no your not real your a search tool, that’s not really all that good. Changing interactive and interaction metaphors is indeed very brave and extraordinarily stupid as it aggravates users. For users in a support system the normal response is to look for another service supplier or phone up to vent on someone.

Still at least there was a feedback form for me to say how pathetic the experience was. Feedback form for fake live support

Tagged : / / / / / / / / / / / / / / / / /

#Usable #security in investment banking and #wealth #management

1.0  Usability principles in security systems

Security and trust are vital principals in building interpersonal and business relationships. These same principles should be employed to both directly and indirectly communicate with users. The following post shows how the construction of password reset challenge questions tell a narrative story of capability and intention as much as supporting text and brand values of the system and service that is secured by them.

2.0  Characteristics of good questions

Correctly structuring and defining the content of password reset challenge questions has a number of characteristics that underwrite a good user experience and establish the environment as high quality, well considered and competently managed technology.

2.1   Cannot be easily guessed or researched

The most important characteristic of a good security question is its own difficulty to discover.  A good security question would have answers that are not easy to guess or deciphered directly or indirectly from what is known or can be researched about the person.

Good security questions meet a number of specific requirements and have high entropy (the number of possible answers) and that the probability of selecting the correct answer is very low.  Only the authorized user is likely to provide the correct answers making a highly secure system.   Answers are even unlikely to be known by a family member, close friend, relative, ex-spouse, or significant other.

Bad examples:

  • What is your address?
  • What is your phone number?
  • What is your mother’s maiden name?

Good examples:

  • What was your dream job as a child?
  • What is the first name of the boy or girl that you first kissed?

2.2   Doesn’t change over time

One of the most common mistakes in creating reset challenge questions is the use of “favourites” as a concept.  Favourite vacation, teacher, colour, movie, book, animal, song, artist, etc. The list is endless and worthless as people change their minds about these favourites.  Last year my favourite holiday was France; this year it is New York.  Not only does the type change from country to place but the next time I login and have to answer a security question, I can get locked out because I’ve had several favourite holiday locations and activities. For the user the result is frustration, “I answered the question, didn’t I” leaving them feeling foolish and with a perception that the technology and its user is untrustworthy.

Bad examples:

  • Where did you go on holiday last year?
  • Where do you want to retire?

The answer to a good security question doesn’t change over time.

Good examples:

  • What is the middle name of your youngest child?
  • What school did you attend when you were 16?

The other problem with favourite or preference types of questions is that people are displaying more information on social network sites like Facebook and Myspace so this type of information enters the public domain.

2.3   Is memorable

The answer to a good security question should be easy to remember but still not available to others. Ideally, the user should immediately know the answer without doing research or looking up an association or reference or having to remember too far back in time.

Bad examples:

  • What is your driver’s license number?
  • What is your car registration number ?

Good example:

  • In what month were you married?

The problem with memorable questions and answers is that they may relate to a social context that not all users have i.e. Married, Brothers/Sisters etc.

2.4   Is definitive or simple

The question should require a specific answer.

Bad example:

  • What was your first car?
  • Answer: Ford, Escort, Ford Escort, 1972 Ford Escort

The answer can be remembered and entered differently and still be correct for the user but wrong for the system.

Better example:

  • What was the make of your first car?
  • What was the make and model of your first car?

This is where the use of language and cultural context starts to have a major effect.

2.4   Does not embarrass

When users are presented with questions that offer open text answers they will sometime use language that they would not expect to be questioned about or worse still have a colleague of manager see them enter into a form.  Also very personal questions cause users to negatively view the technology and ‘ask, why would this company want to know that?’

2.5   Security Level

The most important factor to determining the types of challenge questions used is the level of security required and what risks are opened up by the questions being used.

3.0  References

Ariel, R., University of California, Berkeley 2008. Personal knowledge questions for fallback authentication: security questions in the era of Facebook, SOUPS ’08: Proceedings of the 4th symposium on Usable privacy and security.  Available through:  ACM Digital Library [Accessed 26 October 2010].

Florencio, D., Herley, H., Microsoft Research. 2007. A large-scale study of web password habits, WWW ’07: Proceedings of the 16th international conference on World Wide Web. Available through:  ACM Digital Library [Accessed 26 October 2010].

Just,M., Aspinall , D., University of Edinburgh. 2009. Personal choice and challenge questions: a security and usability assessment, SOUPS ’09: Proceedings of the 5th Symposium on Usable Privacy and Security.  Available through:  ACM Digital Library [Accessed 26 October 2010].

Mohammad, M., Van Oorschot, P. C., Carleton University Ottawa. 2008. Security and usability: the gap in real-world online banking,  NSPW ’07: Proceedings of the 2007 Workshop on New Security Paradigms. Available through:  ACM Digital Library [Accessed 26 October 2010].

Note: A longer version is in process and this post will be updated soon.

Author Links

Tagged : / / / / / / / /

#Context matters in #Usability

Context matters in usability

While any kind of user testing is better than none, usability testing out of context is like testing a car on water, it gives some basic information and not a lot more. If performance and use are important at all, then testing should take place in an environment standard to the expected users.

Contextual Usability

In practice this means testing children’s games at their homes, schools or clubs. Testing e-commerce websites at work, on mobile phones, PDA’s (on the bus, train, plane), internet cafes and in the home. Testing software in call centres, oil rigs, supermarkets, small shops, banks anywhere that they are designed to be used.

Can anyone honestly say that their environment does not affect what they do and how they do it. An extreme example would be fx traders using complex software, telephones and chatting to their colleagues while working within a constant stream of information that changes their activities, focus and effectiveness. Not only does context define how long things are used but it restricts attention span, acceptance of navigation and take-up.

Intelligent business requires a full understanding the effectiveness of new products and services. By testing in context, clients can get realistic data on the performance of systems. Such data can be valuable to making decisions on changes, or having confidence that the benefits you expect will be realised in practice. By testing real users in context potential problems can be eliminated and new previously unconsidered opportunities developed.

Republished from article of August 07, 2006

Tagged : / / / / / / / / / / /