In a recent presentation, you identified a common cause of software product failure: the product didn't account for user levels of expertise. Can you explain what you mean?
Software product failure can occur when the application is too complicated to use the first time a user attempts to do so. Overwhelmed by the product, some users are unwilling or unable to climb the learning curve needed to solve their problems. You can address this with training, tutorials, support teams, embedded help and wizards -- as well as communities of users who are willing to help each other out.
You can also address software complexity by simplifying the product, making it easier and more intuitive to use.
Some products are very easy to use from the very first try. As users develop expertise with the products, however, they start to feel a sense of tedium, frustration and impatience, as their individual capability for efficiency exceeds what the simplified product allows them to do. They feel slowed down or limited by what they are able to accomplish with the tool. At that point, they look for something better suited for the experts they have become.
If we don't design a product that novices can use, they will abandon it before ever becoming competent.
The key perspective for avoiding this catch-22 situation is to realize that your products do not solve problems. People solve problems, and your product is something they may use to help them. Keep this in mind when thinking about what software users need -- it isn't just a list of capabilities. They need a tool (product) that works well for them. And as those people gain experience using your product, they gain expertise, and what they need from a product changes.
Users will continue to need to solve the same problems, but they will need to solve them differently. Whereas new users require guidance in how to use your product -- and possibly how to solve their problems -- experienced users will not require that direction. Instead, they will want to be more efficient, more effective or more nuanced in how they solve their problems. It may be that users move from solving simple problems to more complex ones with your product.
And although most of your users will never become experts, at any given point in time, most of them will not be beginners, either -- they will be competent. If you think of each user as really three users -- a novice, a competent user and an expert -- you're faced with the question, for which "user" do you want to design?
Which brings us back to the catch-22: if we don't design a product that novices can use, they will abandon it before ever becoming competent; if we don't design a product that experts enjoy using, they may not recommend it to others.
The approach that I have found works well is to primarily focus on helping competent users solve problems. They make up the bulk of your product's users, so they are the ones who will realize the most value (in aggregate) from using it. Next, I focus on helping novice users become competent users. People learn through experience, so the novice users have to get value (and not just training) from the product, but my emphasis is on accelerating their transition to competency. Lastly, instead of trying to build a product that is perfect for experts, I focus on building a product that they are most likely to recommend to others (who may not be as seasoned).
Dig Deeper on Topics Archive
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing. Continue Reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype. Continue Reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision. Continue Reading