Karl Smith User Experience Architect (UEA) It's all about making other peoples experiences good ones

10May/120

British Airways security update stops ticket sales

I just logged into my BA account to book a ticket, but BA does not want my business because they have implemented new security without thinking about the impact on users.

After making my selection I'm shown the page below instead of a flight selection page. I could understand getting this if I'm not logged in, but I am so I have already authenticated my session. But there is no excuse for sending me to a blank screen, my firewall does not block Captcha, I know this for a fact.

When was this tested or has it gone up today without being tested, who knows?

---- A few minutes of testing later ...

I have now managed to get it working and BA have fallen for the classic developer problem, the new security page has been developed on FireFox with Internet Explorer an after thought. The Captcha loads in FireFox but does not in IE.

Now here is a description of one of the worst user experiences possible;

  • In FireFox I first log into my account, I'm in they know who I am.
  • Then I do my search selection.
  • I get the Captcha page fill it out, great I'm in my results
  • Now the clear thing is and everyone who books travel online know is that (sorry back now, I was in Heathrow and had to get my flight, ironic that I was in the BA lounge trying to buy a ticket but being stopped by poor usability) searching and finding are two different experiences.
  1. The British Airways flight search tool has always been bad as it does not cross link results e.g. Date, Location, Tier unless you search again, this is because the person who designed it does not think like a passenger. Potential passengers want to get somewhere, that is their first requirement, not to select class of travel. If you want a good standard look at EasyJet flight search, if you can forget all the other painful experiences and thinking the search is really very good.
  2. Now some bright spark at BA has looked at the log statistics and thought we are getting lots of drop outs and re-searching, this could be a denial of service attack, it's not, it is in fact the only way to find flights.
  • So my results only show me one class of flight, to see the other ones I have to search again, if I do I get Captcha again and again and again as I try and cross relate the various sets of results to get the best deal, that gets me where I need to get, when I need to get there.
  • Really, really painful experience, oh and I still have not booked a ticket because I was so angry at my treatment, I gave up.

What to do next?

  1. Sack someone, really, they made my evening hell!
  2. Hire a User Experience Architect (must be technical as they will lead the IT part too, so not a graphic designer) who will tell you how to redesign your search results and change how the back end IT works.
British Airways website security upgrade stops ticket sales

British Airways website security upgrade stops ticket sales

14Apr/120

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.

28Mar/110

Karl Smith Fellow of the British Computer Society

I have just been confirmed as a Fellow of the British Computer Society.  Thanks to all my supporters.
Logo of British Computer Society Fellows
7Mar/110

Website help and support systems should avoid FAQ’s

FAQ's are very much vested in intranet thinking, that assumes if users want help they work for us and know the terminology and have similar tasks / goals to other users on the internal net. Websites conversely support users from every experience of life, who while focused on a product or service are not professionals in that product or service.

FAQ's rely on users knowing what the are looking for in the same way the dictionary works. So if I know your jargon, I can find the help I'm looking for. What happens to normal human beings who just want help? For the most part they are frustrated by poor technology and worse poor thinking which reduces their trust in companies and brands.

Building a modern support system is about users not information silos

Users tend to look for help in a specific context, i.e. to their problem, in the age of custom publishing and personalisation its really simple to provide in context help. Not only does contextual help aid users it provides key management information for companies to understand both their customers (user behaviour) and their products or services (performance) as they are used.

Other types of help

If FAQ's are not usable, what is?

  • How to (video, steppers)
  • Diagnostics (decision trees, interactive triggers in video)
  • Discovery (demo, calculators, scenarios, community of use)

If FAQ's are the only content you have you may end up having to use them as the authors may now be senior staff, but someone should think about users first. When users think of the company or brand is it from the perspective of their experience or word of mouth experience.

What does your help and support system tell people about you?

Switch to our mobile site