Monday, January 29, 2007

the accidental user

People won't use your software how you think.

Sometimes you lovingly plan, spec, prototype, usability test and construct your software to do something - something so wonderful that your users will dance ecstatically through the streets and erect statues in your honor. And sure enough some people are using your program - in ways you absolutely didn't expect.

I wrote the system configuration utility for Windows as a vendor (you can see it on an XP or 2003 machine by choosing "run" from the start menu and entering "msconfig"). It was designed to be a support tool for assisted support scenarios, when you're talking with the help desk and they direct you to run the tool to disable things and work out the problem with the system. It dealt with services, edited the boot.ini file plus a bunch of other things. It was designed to work this way by a series of program managers and usability experts.

So of course everyone just uses it to turn off their startup programs.

If we were designing a startup program, um, turner...offer, we would have done it differently. It's not a particularly elegant tool for the job. On reboot it announces itself and tries to run again, something that makes complete sense for the original scenario but a pain if you're just turning off startup items (fortunately it's easy to tell it to stop). But since it is built into the OS it's easy for users to instruct others on how to run it.

This kind of re-purposing happens all the time in pharmaceuticals: side effects discovered during clinical trials turn into the main use of the drug. It's a happy accident when users find your software's benevolent side effects but there are some steps you can take to make this more likely:


First, you can build in extensibility. This can be through something like a plug-in architecture or a scripting language (a few of the requirements for Steve Yegge's living software). Let your enthusiastic users mold your software to do new things. It's more work to build in extensibility but for significant systems it's worth it. Photoshop wouldn't be the ubiquitousness tool it is today without it.

Listen to Your Users

There are some obvious ways of doing this - running forums, e-mail links in your program to send comments, etc. Be sure you monitor those channels. You can also build some of this into your application, automatically collecting data on how it's being used. Be careful with this, though, and make sure your users know what sort of information you're collecting and what it's used for. Your users need to be able to turn this off (and you should never turn it on without asking them).

Finally, your bug reports can give you valuable information on what areas of the program are being used the most. And whenever you close a bug "by design", ask yourself why the user would have made the assumption he or she did. Should your application work how they expected?

Release Often

It doesn't go any good to listen to your users if you can't change the software. If you have a web app this is easy (just post the new code). It's harder for traditional applications but you can make it a little easier. The more thorough and automatic your tests are the better you can sleep at night during fast release cycles (you've certainly heard this before). Most modern software needs to be able to check on the net for new versions and inform the user (again, get permission from the user to make this check - it is not cool to make random net accesses your users don't expect).

Some day your software might adapt might be smart enough to see how people are using it and change the underlying architecture and code to work that way. Better than it was before. Better, stronger, faster.

But we probably ought to fix the buffer overflows first...

No comments: