IT Magazine – November 2007

Business leaders everywhere have started caring less and less about how IT guys build an application. All they want to know, early, is what they can expect in their whole experience with the application.

You guessed right. If we were able to have them ‘interact’ with the application even before writing code, they would be more than happy to actually ‘freeze’ their expectations and live up to their word of accepting what we deliver.

What I realise, rather grudgingly, is that it would actually help even us immeasurably, to be able to deliver what we promise. For over a decade now, we’ve been hearing about how look and feel are so important to any software application. IT purists are seemingly out of their depth in this particular area; they relegate it to being the work of graphic designers or, at best interaction designers.

Thinking of look and feel as an end-of-the-pipeline ‘cosmetic’ enhancement is a blunder of gigantic implications. There is something intrinsic—which tells me that beauty is never skin deep—especially about the ‘feel’ part, which requires a paradigm shift.

WOW! That’s two times in a row that you have guessed right. What if we included a step between the Requirements Book and the Development Phase? Some kind of simulation or a rapid visualisation step. We could then actually build a ‘fake’ application using a suite of rapid development tools. Imagine a presentation of the final application that the client teams could interact with—a mock-up representation of the contents of the Requirements Book.

(interpretation if you wish) that looks and feels, even if somewhat, like what we intend to finally deliver. Imagine it being sent around to users in the client organisation for their feedback. Imagine how little we would have to explain to our software development teams. When we started our company, I actually used the above approach to get one of our first international projects. It was interesting that the client rejected what we presented,not because we didn’t meet expectations, but because we went beyond his wildest imagination of what could be achieved.

Two full months of work with interdisciplinary inputs from our best people went into making a simulated version of our proposed solution. Hold your breath. He not only agreed to pay us for our effort but we even interactively used our ‘mockup’ to clarify the requirements. We pushed one third of the features to a later phase, added a few and finalised a project four times the size we had imagined! That’s right. No amount of textual documentation can tell you how an application will behave.

Pardon my use of a cliché here that ‘a picture is worth a thousand words’. Quote me if you wish that ‘an experience is worth a thousand pictures’. My simple math tells me that we would all be a million times better off, every which way, if our clients could ‘immersively experience’ Requirements Books. Look at it from their point of view.

They have a job to do and it isn’t software development.  They have to run a business. They need IT systems, applications and whatever else so they can do their own jobs better. “Does the driver need to know details of the engine in the car s/he’s driving?” they ask. Are they trying to tell us that engine quality has little bearing on the driving experience?

Nothing could be farther from the truth. The truth is that the engine is still perhaps the most critical part of an automobile, albeit only from a technological perspective; from a driver’s perspective, its quality, performance and function are – and must be – taken for granted.

So it becomes our job to ensure that they have a better overall driving experience as well, and not just that the engine is more efficient or reliable. They must feel comfortable, in control, and safe. I don’t know that our current software development practices account for this.

Answer this one for me. Why do I always want to test drive a car I’ve decided to buy, before cutting a cheque at the dealership? Why isn’t it enough to have read reviews, driven a friend’s car of the same model, read the brochure, seen the promos and spoken to the company? What is it about sitting in the ‘cockpit’ for a couple of minutes, driving around the parking lot and feeling the controls that makes me sure I want to buy it? My case rests. My client can test drive the application … anytime.

Download Article (185 K)
Opens in a new window