How to be Honest with Hard to Use Features

Good friend of mine, Tony Dye, wrote a blog post here. Tony said:

If a feature isn’t used, it might as well not exist.  If a feature is too difficult to use, well, that’s the same thing.
.
When evaluating, instead of saying “does the product enable doing X,” say “Is Bob [or Jane or whomever] readily capable of performing the steps to accomplish X with this product?” If the answer to the second question is ‘no,’ then for all practical purposes, it’s ‘no’ to the first question as well! Using that simple criteria, many product checklists would be reduced to a bunch of empty boxes!

I think Tony and I agree mostly about this but I’d like to dive a bit deeper.

Just because a feature is hard to use doesn’t mean it doesn’t exist as long as there is somebody putting in the effort to understand it and make it work. You aren’t going to get it perfect the first time or even the first several times. The pioneers who will suffer this process will make it better for those who follow. Systems that don’t evolve through usage and feedback are the problem. As long as you are making progress, listening, and rethinking all the time, then there is great hope for things that attempt to do the hard thing even though today they might be hard to use.

So what about the statement "If a feature isn’t used, it might as well not exist. If a feature is too difficult to use, well, that’s the same thing." It may indeed be too difficult for Bob and Jane but perhaps not too difficult for the pioneer, who will clear the way. There are some parts of BVCMS that are indeed complex and hard to setup if not hard to use. If I am asked whether Bob and Jane are readily capable of using that hard thing X, then my answer might be:

"Right now, I don’t expect Bob or Jane to be able to accomplish this. It is too hard, but we’ll help you do it. We’ll step in and take the brunt of the task. We’ll help you get the job done by eating our own dog food and make it more palatable."

In other words, it’s called outstanding support. And a willingness to partner with your clients and help them help you help them. I often tell my clients, if you are feeling any pain whatsoever with our software, let us know, make us feel that pain too. We respond quickly and well to pain. We’ll make it better. That’s what Agile development and fast iteration methodology is all about. It’s called "to succeed, fail early and often".

High value and easy to use software is difficult to produce to say the least. But it is the right and God-honoring thing to do with our God-given talents. But the old adage applies here "if at first you don’t succeed, try, try again."

One thought on “How to be Honest with Hard to Use Features

  1. Tony Dye

    David, I don’t think we have any big disagreement here (hopefully). Good software, good training, good support, all mix together nicely. Someday maybe we’ll have software that is so great, so intuitive, that there isn’t a need for training and support. Not holding my breath on that one! Perhaps as much as anything else, having users with the attitude of “I wonder if …?” can go so amazingly far.

    Thanks for the good dialogue!

    Like

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s