Designers and developers have very different views on what should a product look like, how it should behave and even what its sphere of influence should be.
I started building my design skills around designing classes and their relationships, service interfaces and software architecture. Gradually, I moved to designing UIs since an increasing number of Web Applications were turning RIA, both in Enterprise and Consumer world; the industry was moving in that direction. I focused on building applications with UI that would be easy to use while maintaining the necessary complexity of business requirements. Like that of any other developer, my instincts were naturally tuned to designing the applications for better code reuse, appropriate use of design patterns, generic functionality and extensibility. Everything but usability. Almost every software engineer that I know has been conventionally focused on functionality and the other things I mentioned above.
But hey, what is more important – Functionality or Usability?
This question, to say the least, is unfair. Usually, this question is asked by Software Engineers the most. Why? Because for them prioritizing their tasks is the biggest challenge. Most often developers enter the scene too late in a product management life cycle, which is the development time, of course starting from Low Level Design. Most of the high level design or problem solving is limited to people who are either too far removed from the ground realities of implementation or have too little bandwidth to delve in such issues. Their main focus is making the customer happy and they seem to do their jobs pretty well, except they end up making the engineer’s job hell. An engineer is required to make all the tactical decisions with free will, yet under the constraint that the product they are building must remain highly usable as perceived by the business analyst or technical product manager, or customer.
Why do Engineers put Functionality first?
Engineers like rational thinking and naturally go for the optimal path in solving problems, and they like to solve the whole problem at once. They don’t understand the concept of a “Dumb User”, because they see the world being made of intelligent beings. They like to build products that are feature rich and can have various layers of complexity like human mind. Yet, they fail to realize that an ordinary user rarely ever thinks of a complex product as an intellectually rewarding puzzle, for her every software product she uses serves as a means to an end. Engineers like to throw in a little extra on the functionality hoping the user will some day, lost in their tracks as they usually are, hit upon a remote corner of the application and be pleased to find something useful to do there and be awed by how deep the engineers mind had penetrated. Whereas, users mostly like to stay in the well acquainted territory of known functionality which is usually only a 20% of the total functionality of a product so they would rather have that 20% delivered to them rock solid robustness and tremendous ease of use.
When to bring in Usability?
In principle, as soon as you conceive the product. In reality, every development milestone should be trigger for a Usability Test like it is for a Sanity Test. Usability is not just about decoration, it is about serving a pleasurable experience that user may want to return to, over and over again. Now, even though it sounds logical, Usability is rarely a part of development or design discussion amongst engineers. The only people you see ever discussing about usability are Designers, QA, Product Managers, Sales and Customer Support. Which means, except developers, everybody else thinks about it. And you might wonder why so, and how it might be resolved?
Engineers need to Understand “Why?” before they start on “How?”
If a developer, while writing code, finds a situation that doesn’t make sense, it probably really doesn’t make sense, yet the developer ever so engrossed in getting things done, churning large volumes of code every minute, doesn’t want to examine it. That is where the usability is compromised the most. If developers understand what business purpose the feature is serving, they can never build an unusable product.
Is that it?
Yes and No! For basic usability scenarios, that related to low level controls and basic interaction between the controls, developer paying more attention can solve the problem.
In Next Post I will discuss how usability can move higher up on an Engineers priority list.