Building user expectations vs managins user experience

I see this over and over again with the applications I build. Each project, while professing to be different from last time, inevitably falls into the same old pattern of development. One area which falls victim to this more than anything is standardization.

For the most part our applications get data and display data. In those rare occassions where data is actually manipulated, it is most often done in some sort of grid format. And while my peers may grumble at the humble excel like structures, it is a format which is reasonably familar to the average user.

Sit an average worker in front of excel and they can do something with it. It isn't rocket surgery. Word and Excel manage to thrive because as functionality is added over time, the core product remains the same. Buttons, behavior and layout remain virtually untouched in the majority of functionality facing a user. Microsoft has done an amazing job building user expectations. When the next version of Word or Excel comes out, I will jump right into it creating pivot tables and writing long-winded diatribes.

This is boring. But this is how we ultimately get things done. Less time is spent learning relearning and training and more time working.

But there is another counter trend which appears from time to time, especdially at our company. Doing things in the same way is no longer acceptable. In each project a tiny group of business product owners and even smaller group of developers decide how THIS project should behave and how THIS grid should act. The 'THISNESS' of the project acts blindly towards previous projects as well as typical usability conventions. Why is this?

One potent motivator is the need for people to feel as though they are involved in the project. Everytime someone opens the application and the first cell of the grid is red, they can smile and say "I pushed for that". Whenever columns are read-only for no apparent reason, someone can point proudly to the fact that users are being saved time by not wasting valuable writing time. When it then becomes impossible to enter a cell because upon entrance the current cell becomes the cell to the right, well thank the Lord because the user does not have to even enter a cell to try to type in it.

Overanalysis is the second motivator in the example seen above. It is like a snake in the middle of your path. You carefully walk by the snake. It doesn't move. You feel the need to be certain, so you go back and prod it with a stick. You get bit. The problem is that someone already told you the snake was alive and indeed very poisonous.

Analysis is not bad. But the focus of the anlysis should be clear. There is a big difference when analyzing "What should be done vs How to do it". Often more time spent on detailing out the objective of the application will decrease the time spent figuring out how to do it. There is a big difference in thinking regarding the following two sentences:

"We need a way to highlight vacation times greater than one week"
AND
"We need to highlight vacation time greater than one week with a red underline"

One way of thinking is generic and adaptable. The other is much more rigid. In addition there are far more assumptions made in the second statment. Why red? Will the user know what a red underline means? Alot of time can be spent over analyzing such issues while more important business objectives fall to the wayside. This is even more true if there are no standards across development. And this is still only in the planning phase.

Strangely placed buttons, wierd acting grids and the like aim to manage user expectations. Development teams (including process owners) often see this as a way to save time and create something unique. However, people work much faster if they have new tools which imitate existing tools. Imagine if everytime you typed in a certain application, the letter C came out as a P. But with another application C came out as N. I could almost guarentee there would be no good reason for doing this, but it is not out of the realm of the impossible. Far greater assumptions have been made while developing applications.

Business applications should strive to build user expectations by building on standard behavior and presentation as well as standard business processes. Product owners should review existing applications when modeling future ones. Similar naming conventions, color coding and language goes a long way towards productivity and can cut down on development time by reusing code and cutting out the need to cumbersome help files to document not only how this works, but even to a less visible degree, how this applicaiton works as opposed to another internally developed application.

But I am just one man...well it is time to get back to my grid, which has readonly columns without indication, blinking, twirling and other useless features. Don't worry, it will save your data...well some of it....well eventually.