Usability lessons learned: Who’s driving who?

Tax season. What better way to welcome the wamer weather than filling out tax forms. Forget about the return of birds, the blossoming of trees, driving with the windows down or the reappearance of short skirts. Spring calls for serious work. To make matters worst, this year I could not manage to find out how much interest I payed on my student loans during the past year.

I wasn’t able to do it through my bank’s online service even though I remembered doing so  the previous years. I felt pretty bad about myself, considering I’m a supposed to be an IT specialist and all.

I called the customer support in shame only to be told that my information was indeed available online. I felt even worst. The very nice lady on the phone walked me through these very precise steps :

1- Go into my monthly statements
2- Select the account from which I pay my loans
3- Select the month of December
4- Go to the bottom of my statement

This is where my information was hiding all along ?!? How intuitive, right? You would have figured that one out, right ? You might wonder why someone would decide to hide this info this deep since it makes no sense at all right? Well it does in a certain way. If you look at the 4 steps above and translate them into an SQL query, it does look more natural. It would look something like this :

Select SUM(interests) from Account where date >= 2009 and date <=2010.

Makes more sense now ? This is what happens when software is developed backwards. When the back end drives the front end. Instead of having the natural user interactions dictate the way it should be implemented, we have the implementation dictating the interactions.

Take radios as another example. Just like one of my university teachers used to point out, most users could not care less about radio frequencies. Yet they had to learn about them in order to use a radio properly. Even though it was less natural to use as a result, it was more cost efficient to bind the user directly to the choice of frequency without an abstraction layer.

When designing interfaces, a good practice would be to always ask yourself : Who’s driving who ? Is the implementation driving the interaction or vice versa?

In other words, are you trying to fit the tool to the user or fit the user to the tool ?

For more on this subject, I would invite you to read this article

Nicholas Lemay