The types of applications I’ve created would never have survived without power users, so I do everything I can to keep them happy. If you’re a developer, I recommend that you keep your power users happy, too.
Power users who love your software will talk about it in online forums, say complimentary things about it in their blogs and convince their coworkers to buy it. They’ll make great feature requests, give detailed bug reports, help less experienced users get up to speed and provide an incredible amount of help during betas.
But there is a downside. You need power users, but power users can be the enemies of simplicity.
Power users will request features that nobody else wants, and they’ll ask that existing features provide a ton of options that maybe 1% of customers care about. More than anything else, power users want to be in control of the software they use, so they’ll choose something complicated over something simple if doing so leaves them in charge.
You might think you can ignore them and cater to mainstream users, but you risk having power users constantly deride your work if you create something they hate (Microsoft Frontpage comes to mind here).
So how do you keep them happy without scaring off new users?
It really boils down to doing what I recommended in part I of this series: figure out which features – and which options – you need to make obvious and which ones you need to hide. You can hide things that only power users want.
Most power users are the unofficial support technicians for their friends and family, so they understand your desire to keep things simple. Power users can accept that some features need to be buried beneath a menu or obscure setting, and they usually won’t complain if they have to spend a minute or two customizing your software to get it to work the way they want.
By all means keep your power users happy, but make sure you don’t increase your software’s complexity in the process. Both sets of customers will be happier for it.
Interesting series of postings. But doesn’t adding lots of options and settings, even if you bury them in settings dialogs, mean more complex code, harder debugging and more testing now and in the future as well? This can happen if you want, say, all kinds of settings to apply per feed and/or per folder as well as in general…
All these settings have to keep working in future releases. And once you’ve added an option, power users will not be pleased if you ever decide it has to be removed for the greater happyness of all.
Rijk, you’re right, of course. I don’t recommend adding a *ton* of power user features and options, for exactly the reasons you state. In retrospect, I should’ve said “keep your power users happy – but don’t go overboard!”
Being one of the TS orphans I can’t help but chuckle at this last post!
so I’m a curse now? :P
cool posts, Nick. I’d link to them but I’m not sure if you’ve finished ;)
One other thing about us – when a feature is removed that is well-loved among the power users, there is much wailing and gnashing of teeth – for about 10-15 minutes, then we get used to it.
As an example, I know there was a feature you pulled out of FD during the last beta cycle (I think – it may have actually been during that real short cycle before that) that I really wanted to have put back in; it wasn’t and now I can’t remember what that feature was! :)
The powerusers tend to be more resilient like that, I think…
Andrew, I’m not sure if I’m finished, either! At this point, I don’t have anything for the next part of this series, but I do need to write something to tie them all up.
Critter, I’m not sure if that’s resilience or senility, but either way, at least we’re both happy :)
Keep these coming, they’re great!
Perhaps you should call your blog “Nick on Software”. ;-)
Although I’m a power user of some programs, I there are always a few jerks who push and push and push a program until soon it’s fully bloated, taking on the functions of several separate programs — what about an FTP client in this? When will we be able to do email? How about adding a note manager? When will my compression app have PDF printing abilities? (Huh!?) and on and on.
For those of us who make “suggestions” for consideration by the dev in future updates or versions, it’s pretty aggravating. For others, a suggestion belies a command, which ain’t right.
But Nick, you nailed it about control. Users want control, and for me, control is often the ability to customize parts of the UI, such as keyboard shortcuts, toolbars, and the ability to dock items. If you ask me, devs should keep a donation link nearby for power users, i.e., the more donations I get in favor of a certain feature, the more I’ll consider it… maybe.