I’ve worked on several design projects that resulted in “dead ends,” situations where what we created didn’t really work. I always try and learn something from these experiences, and a key lesson I’ve learned again and again was that benefits that seemed obvious to my design team weren’t obvious at all when the work was tested with potential customers. We were too close to the work, and had convinced ourselves that we were adding value and solving problems… When we really weren’t.
I don’t look at these projects as failures, because it’s better to “fail fast” than to go all the way to implement something… that then fails after investing hundreds of thousands of dollars making it real. This is one of the key reason to test your designs – the budget you save may be your own.
Unfortunately, not every company or development shop shares this approach. There are multitudes of computer and mobile apps that are… well, they’re a solution looking for a problem. Some are very slick and quite beautifully designed, but you look at them and wonder, “what were they thinking?” These applications are all sizzle, and no steak… really cool and utterly useless. These programs provide no benefits to anyone.
And I have found that this is a key differentiator between success and failure: Benefits. What value is being provided by the application or offering? Why would anyone use it? What do they get out of it? And are these benefits obvious, within seconds of use? When starting on a design project, put yourself in the user’s place and ask yourself the above questions. If you don’t have a clear and simple response to each, you either are overcomplicating things or need to think about it some more.
The importance of a “benefit case” varies depending on what is being designed, but if you dig deep enough you can identify a clear benefit case for most of the programs we repeatedly use in our lives. From e-mail to web apps to games… You can even make the case that the clearer the benefits the more successful the offering has been. This is why many companies still advertise their products or services with bulleted lists of features – each bullet explains a benefit that, hopefully, will appeal to an interested buyer.
The thing about benefits are they often are in the eye in the beholder. I use Twitter to engage and share with a group of people I like to chat with… Other people use it to promote their “personal brand” or to sell products. Other people think Twitter is a huge waste of time. I think the best offerings have an “extensible” benefits case, malleable to different usage patterns and interpretations. The more something can be personally beneficial (emphasis on the personal) the more responsive the person is to the application, product or service.
Finally, always remember that people are different. The more you know about your intended customer the better you can understand (and message) the benefits you are creating for them. And, because people are different, also be understanding if some people during testing bluntly tell you they would never use what you have created… because they don’t see how it would benefit them. When you hear that more often than not, though, you probably need to revist what you are trying to do… and clarify your “benefit case”.