Design for expectations


I’m currently working on a system which is as close to greenfield development as you can really get in a 13 year old system written in a propriatary language. It’s a web system, using modern-ish javascript frameworks, Knockout and Backbone, with a C# middle layer covering the complexity of the backend and its older SOAP web services.

We’re working with an initial client as a partner, however this will be a generic system for other clients as well, so we are being thoughtful about how we write a system which is useful and works as expected for all our clients and their customers. To that end, when we’ve been talking about design decisions, variants of this phrase have come up a lot:

“That’s how people expect it to work from other sites.”

This tends to come up when we’re talking over two or three options, and it’s often used to justify a worse user experience for either no reason at all, or a reason which is not particularly difficult to overcome. I’ve done it myself - worried about whether or not users will understand our interface, so decided to stick with a worse experience because I think they’re used to it.

We tried to justify asking people to login again after resetting their password, even after we’ve taken great care to verify their identity - this adds no security at all, yet we discussed it at length simply because a lot of sites ask their users to do this.

The Vesper team talked about a similar issue on Debug podcast 37, regarding user registration and asking for retyped passwords. We enter our password twice whenever we register for any site online, and for what? If we make a mistake, the forgotten password interface is right there - why can’t we just trust our users to take care when typing their password, and use the interface we provide if they don’t? It’s often a far worse situation if the user mistypes an email address, particularly if it’s used as the username, as there’s not always a forgotten username process (short of ringing up a call centre).

When we find ourselves taking ‘what users are used to’ into consideration, we should be careful. Are we hindering our design and usability and holding back progress, perhaps due to now-solved technical issues? Don’t let past mistakes hold us back, work on your interfaces to make them straightforward, but give the user credit, as you’re there to speed up a process for them, not hold their hand.