Self-Centered Software Design

It’s well known that most software developers hate providing support, training end users, writing documentation, basically anything that doesn’t involve programming. But when you force them to do what they hate the most, you can expect dramatic improvements in the software that they create.
It’s kinda like “If you are a dog who makes cat food, let the cats come to you if they need to throw-up.“

One of my roles at work involves the development of Activesite - our content management solution. Due to it’s nature, most of the users of Activesite are “knowledge workers” (aka non-technical users). And since we aren’t a large multi-billion dollar conglomerate (yet), sometimes support calls on Activesite come to me.

I used to hate providing support to users. Especially when I would get calls while I was in the middle of working on something fun (in the “flow”). I don’t particularly enjoy writing Help and How-To manuals either. Thinking that if I write good documentation, I’ll get less support calls, I tried to assure my self that this was time well spent. However, the hard truth is that “users never read the documentation before trying to contact support”.

My agony led to a very useful side effect in my software development philosophy.
Simply put, I decided to make Activesite intuitive enough to

1. not require end users calling me up for support
2. not require an extensive “How-To” manual cos no one ever reads it and more importantly, I don’t enjoy writing it
3. not require a training session with the users before they could start using the software

To reduce my support pains, I started re thinking parts of the software that seemed hard to explain to end users. If I got calls for help on how to use a feature more than a couple of times, I looked at redesigning it. If users asked me “what does that check box do?” I considered removing it. I started to think pro-actively on how or what to build such that I don’t end up supporting it in the future.

Very soon I noticed that as a result of my selfish attitude towards software development, I ended up with a better application that was easier to use, easier to demonstrate and ultimately easier to sell.

This realization led me to look at providing support in a much more positive way. Now I see support calls as a treasure trove of ideas which I was too dumb not to have thought of.

Those companies that have separate support departments or worse still, those who outsource support are missing out on a great deal of free feedback. Providing developers with reports is not nearly as good. The developer needs to be bothered, in real-time, by someone he cannot ignore.

We have all heard that how most good software is created to scratch a personal itch. Let the developer provide support to the users so that it starts to itch him enough to improve it.

(4 votes, average: 5 out of 5)

 Loading ...

This entry was posted on Monday, November 13th, 2006 at 8:05 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.