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."