Software Reality
Programming with
a dose of satire.

Site Map Search

Agile Development
Extreme Programming
Code Generation


Check out our ageing Reviews Section

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

ICONIX/Sparx Public Classes to Come to London

ICONIX is planning a series of open- enrollment public classes entitled Hands-On Enterprise Architect for Power Users in collaboration with Sparx Systems.

Interaction Design

The Oyster Gotcha

By Matt Stephens
February 13, 2005

When designing software UIs, we can learn lessons from real-world errors (not just in software). The Oyster Card is a good recent example.

In the UK, Transport for London (TfL) recently introduced a public-transport payment system known as the Oyster Card. It can be used on buses and British Rail trains, but seems to be mostly aimed at the Tube (aka London Undergound) - or at least, that's where it seems to exhibit the most problems.

The premise behind the Oyster Card is that people using it prepay their fares online. Then, when they walk into a Tube station, they “touch in” (i.e. rub the Oyster Card provocatively on a magnetic detector thing which reads their details). When they leave their destination station, they “touch out” in much the same way. Their journey fee is then deducted from their prepay account. If there isn’t enough money in the account, then obviously an iron cage drops from the ceiling and sharp knives are poked at them from all sides. (I’m told that this little-known aspect of the new system won’t be implemented for another 12 months though).

First, what’s there to like about the Oyster Card? It’s a robust system which allows thousands of commuters to make their way to work each day, and on the whole it has that magic quality needed by any such large-scale, mission-critical system: it just works. However, it’s not without its usability issues. Perhaps usability wasn’t top of the designers’ list of criteria when creating the Oyster Card system. But then, its marketing is full of bubbly claims about how it’s much more convenient (etc etc) than the traditional paper-age Travelcard system.

The Oyster Card supposedly makes buying season tickets much easier. No more queuing at the train station on a Monday morning; just prepay online, and Bob’s your slightly scary uncle. Some thought has obviously gone into the way people will use the Oyster Card, because there are ways in which certain things are supposed to “automagically” happen. For example, you don’t need to book or declare a specific journey: as long as you touch in and out, it all gets worked out for you. And when you purchase or renew a card, you nominate your “main” Tube station for your daily commute. Then, when you touch in that station your card gets charged-up with your new "virtual travelcard" or topped-up with your prepay credits.




Why the Oyster Card Sucks

So, what's there not to like? Quite a lot, as it turns out. The first thing (not really to do with the main subject of this article) is that the name (to me at least) is quite distasteful. Oysters, yuch: eating an oyster would be like licking snot off a tortoise shell. I really don't want to have that image thrust into my mind early every morning while I trudge to work. At that time in the morning, I'm still not fully awake; my mind is still in its semi-unconcious, probably easily hypnotized state; dreamy; and all grotesque imagery is to be avoided if at all possible.

"It's very easy to forget to touch out"

Back in the corporeal real world though, the trouble with the Oyster Card is that at certain Tube stations, it’s quite easy to walk out without going through one of the “proper” ticket barriers; and often, the ticket barriers are left open so it’s easy to simply walk straight through. In fact the hordes of commuters are often herded through various exits, and with a thousand people pushing behind you to get out into the sunlight, it’s really very easy to forget to “touch out”. TfL’s solution is simple: if this happens, give the commuter the arse-end of the doubt, and charge them the maximum possible fare that they might conceivably have travelled. Nice.

The system obviously isn’t very well thought through. Of course, it’s easy to look at a complex system from the outside and comment on its shortcomings. Henry Smuggins speaks. But in the Oyster Card example, I’m convinced that some application of user scenario-based design would have caught the (really quite major, and obvious) usability issue and allowed some sort of workaround to be worked into the overall system (i.e. not hacked on afterwards as a “bug fix”). In short, they didn’t think about the fringe cases, the “rainy day” scenarios, and how the new system would be applied to the existing infrastructure (i.e. how the “touch in/out” system will work with the existing ticket barriers). If they had, they could have caught the problem and eliminated it from the basic design. Simple as that.

Being charged the full fare “just in case” isn’t necessarily an error: TfL’s accountants would no doubt argue that it’s the only right thing to do. But if the system had been better thought through – i.e. remove the need to “touch out” altogether, or make it impossible to leave a Tube station without touching out – then it simply wouldn’t have been an issue.

Regular commuters who simply buy an old-fashioned ticket (aka “Travelcard”) and push them through the little slots in the ticket barriers don’t get this problem. If the system is set up so that they forget to “slot out” (or whatever the phrase is), they don’t get shafted. Or slotted, or whatever. The reason is because they've declared their intended journey up-front, so forgetting to "close" the transaction doesn't really matter.

"They didn't think about the fringe cases..."

Anyway, for Oyster Card users it’s a rum deal. If you forget to close the transaction by touching out, it really is a big deal. The "fix" in this case is to constantly remind everyone (not just Oyster users) to remember to touch in and touch out. So, walking through the Tube, we are now faced with condescending announcements from sneery-voiced announcers, along the lines of: “Got an Oyster Card? Well, when you start and finish your journey, you must touch in and out, otherwise we’ll charge you full fare. This is for your benefit, not ours.” I’m amazed that these announcements are read out using the most contemptible tone of voice imaginable, as if the announcer is scolding some naughty schoolboys for wetting themselves one time too many. Also (I’m sure this isn’t just me), but there’s something a little bit unnerving about being told to “touch in and out” (and, worse, to “touch your Oyster to the sensor”) by a stern-sounding schoolmaster. Shades of Derek & Clive’s “Sir”, perhaps.

Perhaps a better solution for Oyster Card users would have been to make them walk through a big magnetic sensor, a bit like the anti-shoplifting gateways you see in most shops. (On a side note, have you noticed that when those devices go off, the only time the shop staff leap into action is when the victim/customer/suspected criminal definitely paid, and the cashier simply forgot to demagnetise the goods?)

But, for Oyster users, obviously it’s too late now. The system is in place, it wasn’t thought through very well, and now the responsibility is on the customer to work around the wrinkles in the system (even when they’re being herded condescendingly away from the Oyster barriers, or the barriers have been left open and there’s a crowd of people behind you pushing to get past, or your mind is anywhere but with you in the dank underground – e.g. it might be on the job which you’re struggling valiantly to get to, despite the latest inexplicable delay or tube-train derailment. Presumably those are the commuters’ fault as well).

"A nice little sideline earner"

Analyzing the rainy day scenarios can often have surprise benefits. For example, when I queue up to renew my travel card each month, I also have to buy a car park ticket for the privilege of leaving my car in the overpriced British Rail car park. If the Oyster people had thought it through, they would have realised that allowing you to also top up your car park ticket on-line would be a nice little sideline earner. In fact, you could just register your car’s registration number and it would all happen automatically whenever you top-up; no need for a physical ticket; and no sneaky gotcha if you top-up but forget to renew the car park payment. Elimination of “gotchas” is one of the key benefits of exhaustively analyzing the rainy day scenarios.

Discovery of new opportunities is another benefit (though should be handled with caution lest it lead to the kind of scope creep that often results from over-enthusiastic feature brainstorming workshops).

Another example of how the Oyster Card system’s rainy day scenarios weren’t properly thought through can be found in these two blog entries from a disgruntled commuter: Oyster Sucks and Oyster Sucks Part II.

In the first example, the rainy day scenario was: “The card stops working and must be replaced.” This in itself led to an unnecessarily long saga for the commuter. But the problem was worsened because when he later topped up his new card, the credits actually went onto his old, defunct card (because the website (mis)guided him down this nasty route, i.e. yet another Oyster Gotcha). This in turn led to an embarrassing and frustrating confrontation with surly staff in a dank Tube station deep under the streets of London, made worse because the Oyster call centre closes at 6PM but the Tube doesn’t. Another Gotcha (again)…


Lessons Learned

What can we learn from these many problems, and apply to the world of software design? The parallels are many. Some signs of a badly thought-out system are:

TfL/Oyster System Software UI
The passengers have to be constantly reminded to touch in/touch out, and not to ignore/walk around the ticket barriers, or straight through if they’ve been left wide-open. Constant presence of pop-up dialogs to remind the user to do something, or not to do certain “very bad things”, or to point out that what they just did isn’t allowed (it just shouldn’t give that option in the first place).
The announcers feel the need to use a condescending tone, as any errors are obviously the passengers’ fault. Dialogs adopt a parental tone, or end with exclamation marks, or make the user feel stupid (usually a combination of all three).
The Tube is such a horrible place to be (hot, stinky, overcrowded and noisy) that the commuters’ minds will be anywhere but down there with them. That doesn’t make them stupid, just self-preserving. But as a result, if there’s a trap or “gotcha”, you can guarantee it’ll catch them out at some point. The software is a chore to use (lots of manual, fiddly steps) and the user must remember to do (or not to do) certain things which aren’t made obvious in the UI. Also the user’s mind is more likely to be elsewhere (thinking about that argument they had this morning, or multitasking on an important task). This doesn’t mean the user is stupid, just very busy. But as a result, if the software contains a trap or “gotcha”, you can guarantee it’ll get them eventually.
It’s very easy to slip up and get charged the full fare (i.e. to get shafted because the Oyster system wasn’t properly thought through). It’s very easy to slip up and cause some irreparable damage to the system (or which takes a long time to undo, e.g. having to unstitch a complex transaction in the database) – i.e. to get shafted because the user/system interaction wasn’t properly thought through).
Once shafted, it’s a painful and arduous process to get a refund. (Actually I’ve never tried, but I’d hazard a guess…) Once the data is in the system, it’s staying there; e.g. no “complex/transactional undo” facility, so the transaction must be manually unstitched in the database. Ouch.
Commuter #1438746 has to queue up every month anyway to buy a car park ticket, so supposed convenience and ease-of-use of buying on-line are bludgeoned out of existence. Alternative courses not fully thought through, making part of the system difficult to use, impossible to use, or just plain pointless for some of the users. For each “missing” scenario, another 10% of users become silently disgruntled.
When a card stops working, the commuter must step outside the path most travelled, and as a result encounters a whole series of frustrating Gotchas; one after the other. Alternative courses a mile deep, but only analyzed to about an inch beneath the surface. Result: one tiny thing goes wrong, and the software just isn’t up to the job of helping the user to help it recover.


In the software world, a good example of the first item (pop-up dialogs telling you that the option it just gave you isn't actually allowed) is in Microsoft Outlook. If you book a meeting, Outlook cheerily asks you if you'd like to update your calendar. "Ok, sure," you think, and click OK. Instantly Outlook drops its friendly paperclip facade and reveals its true personality, snarling: "But you can't do that, you're the meeting organizer!" Then why did it just offer to do it?

The second item in the table above (announcers’ condescending tone) is an important giveaway. The Tube organizers seem to be blaming the commuters. If the commuter forgets to “touch out” then it’s his fault; but why should he have to “touch out” in the first place? Similarly, it’s very easy for a software developer to blame the users for his shortcomings. If a user continually makes the same basic error, is it the user’s fault for being so stupid, or the software developer’s fault for designing such a difficult-to-use, trap-laden product?

Luckily, as software designers we’re in a position to do something about it, at least with our own software systems. We can make the conscious decision to be nice to our users. It takes a little application of thought, but it’s worth it, and really will make the world a better place, at least for the people using your software. Think about how they’re going to use the system. Analyze some personas (typical end-users) and user scenarios, and walk through the UI as if it’s being used “for real”.

If you’re driving your software design from use cases, then it’s important to remember the 3 “magic questions” that any use case writer must ask repeatedly (see Agile Development with the ICONIX Process):

For the basic course, first ask:

1. What happens?

Then ask:

2. Then what happens?

Then repeat question 2. until the basic course is complete.
Then, for all the alternative courses, keep on asking:

3. What else happens?

And keep on asking it until the well runs dry.

By analyzing the alternative courses, the “rainy day” scenarios, you catch the wrinkles and gotchas, and pave the way so that the user’s path will be a smooth one, especially if they have to complete the same “rainy day scenario” several times a day.

In short, go to great lengths to make your application a joy to use and to eliminate traps, otherwise it’ll just be another Oyster Gotcha.


Further Reading

Click the images for links to

The solutions described near the end of the article (analysis of rainy day scenarios, persona analysis and user scenarios) are described in more detail in my book Agile Development with the ICONIX Process (co-authored with Doug Rosenberg and Mark Collins-Cope).
About Face 2.0 I can also highly recommend Alan Cooper’s book on interaction design, About Face 2.0 []
Domain Driven Design Domain driven design can also be of great benefit whilst analyzing rainy day scenarios. Eric Evans’ Domain Driven Design provides a thorough in-depth discussion of the subject (also see the link in the sidebar).


<< Back to Design

<< Back to Software Reality


All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.