One of the major design projects I worked on a few months back involved redesigning a financial management web application. As part of that initial work we created a concept that used a calendar as the system’s primary navigation. Users could add or move financial transactions on the calendar by dragging and dropping, or see projected balances on certain days – the idea being that users could manage their finances through that screen.
The design was very excitedly reviewed by stakeholders, as well as my peers… even our CEO loved it.
Then we tested it with users.
The reaction? It was… Meh.
We soon realized the problem with the design. It wasn’t that it was bad – it was cool, interactive and very Web 2.0. The problem was it didn’t match the mental model of our users. We were forcing an inappropriate metaphor on our users, and were trying to make “list users” into “calendar users.” But, more than that, we misunderstood the context of use.
(This is where I insert my obligatory “and that is why you test with users” quote.)
Our users did not plan – they reacted, usually to inputs that were not available in our system. Giving a holistic calendar view to them did not help – in many ways it reduced clarity and focus… They were overwhelmed. They couldn’t react to the UI affectively because there was too much to react too and it didn’t “fit” the way they worked.
The system did not support what I am calling the Immediacy of Now – the need for users to quickly accomplish an urgent task. It may not be urgent to you or me, but it is to them.
More and more designs and systems are being created to support this behavior – look at mobile applications, intended to support short discrete tasks… Look at Twitter, for goodness sake: it’s core concept is to support the users need to immediately communicate with their community of followers and express their opinions.
So, how do you support this behavior? Well, keep it simple. Don’t add needless abstractions or features – support the core task and stay out of the way. And if you are designing mobile applications, reduce the process steps to one or two at most. You’ll be quite surprised how well your design is received when you don’t overdo it.