Software Design – What comes first: Functionality or Usability?

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.

Resource Update: GoF Design Patterns – Only notations, no text!

Sometimes, a picture is indeed worth a thousand words. Especially I always felt that the Design Patterns book was quite verbose and distracting in its approach. It would have been great if the examples had been a little more simplified and did not clutter the space. Also, a bit of comparative study of these patterns could allow one to appreciate the subtle nuances and the differences between these patterns, which look quite alike to a newbie.

Finally, I struck gold when I found this link. Some old site that contains the pictorial or PepperSeed images showcasing the Design Patterns. The notations are quite similar to UML notations. And There is astoundingly no text, whatsoever!

I find this a very essential 5 minute referesher that the Architects should keep handy for reference, whenever a moment of uncertainty, while designing a complex application, renders them actionless.

This is the link to the site. Gang of Four Design Patterns

Here is a sample of Adapter Pattern and Bridge Pattern, when placed side by side once can see the subtle difference so clearly, and without any textual clutter around it.

Adapter Pattern



Bridge Pattern

I hope you appreciate the essence of text less GoF Design Patterns!

P.S. The images were stolen from Gang of Four Design Patterns.

Hello World – I am here!

There can’t be a more apt way of entering the Java world than “Hello World!”. Those magical words can transform about the most ordinary lives. At least for me they did.

I am relatively an infant in the Java world, but I am a precocious infant so I will say whatever I think is right and you have only two options, you agree with me or you die.

Java technology stack has grown from strength to strength in last decade and today it has reached a level of maturity that inspires confidence that the world could indeed depend on software. That intangible, quirky stuff some nerds keep punching in on their keyboards and that can do some wonderful stuff only we don’t know how it does that.

My ride through the software world allowed me to witness the prehistoric programmig languages like Fortran-77 and Pascal but as I moved ahead it has only gotten better with time.

In the life of a programmer, the real transformation occurs when one moves from straightforward procedural languages to the world of Object Oriented Programming, which kinda adds a realistic paradigm to the world of software. The complexity of objects in the real world and their relationships are translated verbatim in the OOPS world and that is when things start getting better. It’s like a boy turning into a man. Both the programmer and his code enter a new level of maturity and capability.

So, who am I? My name Rishik, and I would like to think it is a unique name, however it is no more. I have worked as a programmer for last 6 years now and worked on different sets of technologies. Currently, I am having an affair with Java Technology Stack. And I can’t express how rewarding this relationship has been right from its inception. I work with Pramati Technologies, and I have recently added another role to my portfolio, which is “Relationship Manager”. Apart from being a developer I am now into business development for half of my time. And I started this blog to bring out the lighter side of Java.

Let’s see what comes first, the chicken or the egg!