The voila factor is the embodiment of well written software. When the user sits down to use the application, be it command line, web, or GUI, it should just work. Voila.
For some reason so many applications fail to do this for a number of reasons. I have my theories of why this is, based upon personal experiences.
Here are a few:
1. Application designs are developer-centric.
The developer personality is usually one that likes solving problems. Because of this most developers love getting their hands on a juicy feature that they can “solve”. What sets the experienced developers apart from the less experienced is the amount of resolve that goes into ensuring that the design is what is best for the client instead of what is best for the developer. For example, I wrote an administration console for a client once that I was extremely proud of. I designed the system in such a way that I could add a new module to it without having to update but a few lines of code. This was back in the day before Ruby on Rails and Grails and it basically gave CRUD functionality to the administrator. They hated it. While the design was great from my standpoint, as it made updates extremely simple, it failed to meet the needs of the end user because they couldn’t relate to the system or figure out how to use it well.
2. Application designs are designer-centric.
We’ve all been to sites that are a marvel to look at but are near impossible to get anything done in. This item falls into the same category as #1, only with the designer at the core. Design applications for what users need, not for what designers want.
3. Someone forgot the KISS principle.
KISS stands for Keep It Simple Stupid or, as I like it, Keep It Stupid Simple. Developers are a creative bunch at heart and like to add cool extras as they are in the code. Many times these extras won’t even become apparent until an engineer has the code open and is digging through. While these bells and whistles may be nice one has to wonder if they actually adding to the overall user experience. In many cases less is truly more. If a good user experience can be achieved without the addition, perhaps it is best left out.
4. Time was not allocated well for the project.
This is the kiss of death for any project. You can’t decrease the time projects will take by throwing more people or more technology at it. While there are isolated cases where this will work, the body of evidence suggests that adding manpower will usually increase the time it takes to complete projects. When time is short developers are more likely to choose the fastest way to complete their work which, because of #1, makes the design developer-centric and rarely bodes well for the end user.
5. Things change from release to release without notifying the user.
This should be obvious. If CTRL+K serves one function in one release it should either serve the same function in the next release or the application should notify the user that things have changed. Many applications seem to get this right, however many don’t.
