Version Control & Simplicity: The Fatal Error(s)

Since 2004, I've been using, working and training my peers in the ways of Basecamp Project Management system. Now before you roll your eyes and think I'm trying to sell you vitamins and pitch "don't you want to be rich too!" around some tool you cannot live without. Just understand that I'm only using their product as a platform for discussion.

The purpose of this post is to outline the critical flaw that most get trapped in when building an application, website or technological tool – stopping at the point that you've accomplished you desired outcome and going no further. This is also the rule of thumb for designers as well. There's always a point that the design seems complete but you could push it further. It's not to say that it's wrong if you do, but there's a line of demarcation that you may pass where you do more harm than good.

Basecamp is a great representation of an application that does just what it's supposed to do and no more. Ever since I've been using the project management tool, I've had staff and clients alike say "I wish it did" this or that or the other thing. Well the fact of the matter is it does just what it's supposed to do and no more. The simple truth is having more doesn't always make an application better. Often, it creates needless complications in usability; destroys processing power or simply just never gets used by the end users. It's very easy, however, to see things that you 'could do' vs. what you 'should do.'

Version control is where you take your application to the next level. This way you can do usability, A-B testing and get solid constructive feedback from real-time users. But remember, just like anything -- designs, applications and websites – everything has a shelf life. So take the information that you are given during your version control developmental periods with a keen eye on what's really important vs. what seems like a 'cool' thing to have.

One last great key to creating a killer app is multiple ways to accomplish the same task. Users are people -- people live, work and react to situations and environments differently. Therefore, try to take into account that while keeping it simple, you still need to design openly for different users. Adobe Photoshop is (to me) the ultimate example of an application that you can do one thing ten different ways. Admittedly, Photoshop is, indeed, an application that has everything (and the kitchen sink) added to it, so I'm being hypocritical in that example.

Let's take a simpler and more practical example of this: "Navigation." You might use a search tool, the navigation bar, hyperlinked text, breadcrumb trails or site maps. All accomplish the same task, but different user will navigate in different ways. When you've created this experience, you've stepped into a new phase of usability for the outcome.

Take it from the top:

• Develop the application to complete the primary challenge. (Control the overwhelming urge to put more into it than you had originally sought to accomplish.)
• Give it the ability to complete the same task in more than one way.
• Test, test and retest.
• Listen and itemize all the feedback (within a defined amount of time) prior to revising it with version control.

Lastly, I'll return to Basecamp in closing and note that when 37 Signals (the creators of Basecamp) were within versions of the application, the offspring of that learning turned into OTHER applications, and thus alternative revenue streams. From Basecamp, other applications such as Highrise, Backpack and Campfire were an created. So, while it's incredbily important NOT to over-feature our product, out of that attention just might come some fantastic new products.