Building Web-Based Applications

The Sling and Rock folks have posted a great review of The Building of Basecamp. The session covered a wide variety of tips and experiences for building web-based services (or any software for that matter).

As a UI ( UI, UX, HF, whatever we are called these days) I really love the point "Start everything with the screen design. The screen IS the application. The screen drives the functionality, not the other way around. The screen design is the requirements document. " I love this! But if it was only this easy. There are a significant number of enterprise applications I’ve worked where the screen design, albeit important, does not drive the functionality or the requirements. We recently deployed a customized position encumbrance module to integrate the payroll (HRIS) system to the finance system. The screen designs did not drive any part of the functionality, we were constrainted by the general ledger and the business rules (policies and collective agreements) about how to account for funds for each position. I’ll be honest, I still don’t like the requirements documentation and UML models we did use. I think there is significant room for improvement in the clarity and meaning of our artifacts.

The tips and the experience looks to have been really positive. Maybe Jason and the 37signals gang will take this on the road like the AdaptivePath or NN Group (be sure to check out Dr. John, possibly the funniest man in usability with some extremely useful content usability tips too). I am convinced that that 37signals is different from other usability gurus, because they are actually building software. Their Basecamp and SingleFile products are evidence of their experience, expertise, and understanding.

From Gadgetopia 2004/06/29

  • Say "no" by default to any feature request. Make a feature work very hard to be implemented.
  • Remember that there are significant hidden costs with new features. Besides the actual time to code there’s (1) time spent supporting it, (2) unforseen changes that result because of it, (3) time spent documenting it, (4) the overall degradation of the user experience if it makes things more complicated, etc. Sometimes, the coding time is just the tip of the iceberg.
  • Start everything with the screen design. The screen IS the application. The screen drives the functionality, not the other way around. The screen design is the requirements document. (I know, I know ó the hair on the back of your neck just stood on end…)
  • Get something built quickly. Iterate, iterate, iterate. Release early and often. Plan a major feature upgrade within 30 days of release.
  • Be honest with pricing. Clearly display the price, and avoid any hidden fees.