Think of it like Jenga. In the game Jenga you must pull out the bottom blocks and place them on top. Every time you place a new block on top the structure becomes shakier and is unable to support the weight until it eventually all crumbles to the ground.

Imagine an application that is under this same pressure. You start out developing and have an ok UI that “seems” to support the weight of the tool and then you release the product to the consumers. They begin to complain of slow load times, confusing UI interactions. Back in the design room discussions are held about how to improve the usability. And the #1 thing brought up is add new features. No, No, No!

Take another look! You may not need to start from ground zero but, the foundation on which the application has been built is weak and trembling already and about to collapse. The last thing you should do is throw more weight on top of the impending disaster.

This is exactly what seems to have happened in more places then you can imagine. You eventually reach a point where the application looses it’s ability to scale to the increasing features. Sometimes you have to just close your eyes walk away and wait for the impending I told you so.

At this point you should be utilizing real user feedback, comments, and in house usability testing first hand to see what problems are plaguing the user. Sure some features that may be missing may be the culprit, but more often then not the tasks we perceived to be simple are way too complex and the base functionality of the application MUST be revisited to support future growth.

Kathy Sierra talks a lot about this in her blog.

I still have yet to find ways to counteract this line of thinking, but it’s just human nature – more is a perceived better. Any more ideas on how to combat this line of thinking?

Lately, I’ve been trying to push the power of paper-prototyping. It’s a tough concept to get across though because some just don’t see the value. In fact, the customer, BA, Product Owner, just want you to show the customer a mocked up (coded) prototype. This is nerve racking because problems and issues in the design can be ferreted out much quicker using the paper prototyping method.

The overwhelming response to paper prototypes that I have personally faced is: They don’t seem professional, are hard to read, may be difficult to understand complex web actions. These people need to quiet down and listen. Paper is cheap and easy to modify on the fly. Paper prototyping is more than just showing a piece of paper. It’s about defining, refining, and streamlining the interaction between the user and the proposed widgets, functionality, etc. Paper and markers and traditional means can represent all these concepts with little difficulty. You just have to get a little creative at times, but the new ideas that come from these paper prototyping sessions can point you in a new direction.

Several times I have worked through a prototype with limited customer feedback(not recommended) and discovered core application function that was not identified. By discovering this up front you can better prioritize absolute functions from secondary functions. IE: I need to be able to save my book title, but I also need to give it a custom save descriptions.

Customer: “Wow, we never thought about that. We just wanted them to save the book using the title as the saved name.”

You may even discover larger problems such as entirely missing pieces of functionality.

If at all possible you should involve the end customer of your product. I’ve been trying to get this practice cemented into our process but it’s not an easy one. The general premise is this; everyone feels they are right and specs were translated correctly into business needs. It kind of makes sense that you need the customers input to ultimately test the system? However; this type of input rarely seems to happen at the level required. Focus groups, usability testing, is an afterthought and tends to be reactionary instead of proactive