Simplicity is still my favorite feature

• Posted by Brian
• Posted on October 17th, 2007
• View Comments

Our development team recently completed a redesign of the product page for a suite of e-commerce sites. A few new AJAX features are spread throughout, and additional DOM scripting in the guts of the application allows for some complimentary functionality. Yet, the one thing we all noticed and appreciate the most is how “clean” the new design is. Strip away all the features, and I would still be impressed by the simplicity.

This is one reason why I enjoy my job. Although we are constantly looking to differentiate from the competition, the very nature of what we do (sell Niche products) is what makes us unique. When it comes to best business practices, all of our ducks are in a row. The e-commerce sites we support clearly communicate product information, reviews, pricing, shipping costs, and customer service is of primary concern. Fancy new features are nice, but they are just the tip of the iceberg.

This is counterintuitive to the development culture today. Most Web developers would prefer only to work on high-profile features and functionality that stretches skills to the max. I will admit, I enjoy these challenges, too. However, the achievements I celebrate most are those that bring about measurable success through user satisfaction and sales. Regardless of the number of features.

BS is the new ROI

An unfortunate byproduct of Web 2.0 is an adverse focus on the cool factor. Venture capitalists are constantly on the prowl for the next big thing, and as professionals we are more apt to sellout usability and simplicity for panache. Justifying fancy features is unnecessary as long as Web sites and Web applications are marketable by today’s fad standards. Analytics are fuzzy at best, and hard numbers that reinforce a solid ROI are non-existent.

Situations like these cultivate a madhouse atmosphere, where smoke and mirrors are setup to confuse our clients. If our competitors are doing it, then we should at least give the illusion that we are as well. Who cares if it is necessary, or if we can prove the true worth of this feature. If we can sell it, then we certainly should. Motives, quantifiable trends, user experience testing, data mining, research — these are all sinking beneath the weight of the BS.

Is it a bug, or is it a feature?

Not to malign Firefox, but I had to laugh after users began complaining of memory leaks when numerous tabs were left open for any significant length of time. I did not laugh because it was happening, but because of the explanation. This was not a bug, but a feature. Firefox was caching data in order to support this feature, so that users would not have to constantly fetch pages when “tabbing”.

Although not quite a bug, the example illustrates that increasing the number of complex features introduces the opportunity for adverse performance. Even to a user, all might appear well and good, but browsers can quickly pull PCU performance down as an unforeseen side effect of a new feature. While fear of the unknown may be a poor excuse to streamline, it should be given due consideration. If a feature is perceived to be faulty, then clients and users will consider it broken.

That waterfall is a Tsunami

If you are one of the few developers who agree, then there is really only one solution to the problem. You have to get involved earlier. This is easier said than done, especially if you work for an organization that implements the Waterfall Lifecycle (Model). As much as I fear Agile methodology, I fear the Waterfall even more. Over the course of my career, every company but one (an ad agency) ran projects in a strict linear fashion, trickling down responsibility, and passing the buck, from one discipline to the next.

The key is to use a qualitative analysis to prove your point. We went over budget, and we were late with delivery, because we implemented a feature that was not thoroughly scoped or researched. To prevent this from happening, we need more programmers/developers/engineers involved at the beginning of the project. If several developers are making similar assessments, the likelihood that you will be allowed to offer valuable input at the onset of a project will increase significantly.

Even if your company does not support Agile methodology, suggest a prototype approach, or foster interest in iterations. An intelligent developer who can efficiently communicate beyond the realm of technical expertise will be more valuable to a company, even if the ideas are simple.

Tags: application, feature, simplicity