ION - Waterloo Region's Light Rail Transit

[danbrotherston]

First of all, nobody is talking about fault, this isn't about fault.  And if you believe your statement is "unarguable" then there's no point in discussing.

This isn't a chainsaw, a chainsaw is a dangerous piece of equipment that people expect to need training of some kind to use. This is a transit farebox, something everyone should be able to use with no prior training.

If I have a door which 1% of people walk into, that's a failure, 1% is a lot on a high frequency system. And you're right, we're way way below 99% success. Like I said the statement holds, but it needs context...

The “unarguable” bit is only the idea that sometimes it needs to be the users who take responsibility for understanding the design, rather than the designer who has to take responsibility for understanding the users. I agree that, in general, we have a tendency to blame users for misunderstanding the design when instead we should be trying to improve the design. On the other hand, I think there is a tendency nowadays in computer interfaces to prioritize new users over people who use systems regularly.

Of course, in the specific case of a transit tap machine, if a significant number of riders are having a problem the fix is probably changing the design. As others have pointed out, the machine needs to be designed so that the action that it appears is needed is the same as the action that is actually needed. On the other hand, even here we need to be careful. I suspect that an “insert card” design like an ATM would have an extremely low rate of people misunderstanding it (especially if it accepted the card in any orientation, unlike an ATM); but it would be unacceptably slow in a busy station. So any design changes have to stick with the contactless operation.

I suspect nobody really thinks that user confusion is always something that needs to be dealt with by changing the design. If they do really for real think that, however, then it gets awfully hard to have a rational discussion about when design changes are needed and when user training is needed. It’s like trying to have a rational discussion about road pricing with somebody who can’t understand that we currently do not have road pricing, or a discussion about congestion with somebody who thinks that streetcars and bicycles block traffic but somehow cars don’t.

This is only the question of context again. Yes, I should not be able to sit in an airplane cockpit and immediately be able to fly the plane with no training, but if I'm trained to fly that plane and more than once I'll accidentally retract the landing gear instead of deploying the flaps on landing, then the problem isn't my training, it's the design of the landing gear and flap controls (this is a real-life design failure).

In the case of the context of riding transit, there is no expected special training, I really do take exception to the idea that transit systems should require training.  There are many first time users, and frankly, the function being completed is not overly complex, there should not be a requirement for substantial training.

The instructions and use should be intuitive. I'm what I'd call an advanced user, as I'm both an expert in technology and user design, and also riding transit and I *still* find the machines difficult to use and make occational errors, and I happen to know how to recover from those errors, but the error messages themselves provide ZERO value in recovering from the errors.

In terms of speed, you also have to look at real life operations, not just theoretical speed. If every 10th user takes 5x the time to overcome errors, and every third user must retry but knows how to recover, then your tap operation is very slow indeed, and the ATM operation you describe may very well be faster.

And I do really think that usage errors are always the fault of design (within the "in context" caveat I described at the beginning). It is the job of a designer to build a system which is easy to use.  That is not to say that there aren't other tradeoffs in design, absolutes are rarely useful, and extremely infrequent errors may not be worth the effort of overcoming, but it is a principle of design that systems should be easy to use, errors should be hard to make and failing that easy an intuitive to recover from. I do highly recommend the book by Don Norman: http://www.nixdell.com/classes/HCI-and-D...dition.pdf