Joshua Ledwell wrote a short article expressing his perspective on designing software that is neither too simple nor too complex. He also links to some excellent other articles on the topic.
Designing For Competent Users
We’ve written in the past about how to design for competent users. In fact, it was Joshua’s link to that article that helped us find his article – thanks! Users start out as novices, and most of them become competent users. Very few of them reach a level of expertise with your product. You need to make sure you support both their growth and their likely “end state” – competence. The feature set needs to support the fact that most users end up in a state of competence.
Maximizing ROI
One of several good links from Joshua’s article took us to Luke’s article on the sweet spot for selling software. Luke references an article from the Harvard Business Review and includes an interesting graph that shows the relationships between the number of features and profitability. In short, more features drive higher initial sales by satisfying the buying persona. Fewer features drive higher eventual sales through word-of-mouth marketing based on improved usability.
The HBR suggests a profit maximizing approach of seeking the middle ground in terms of feature quantity. Trying to please everyone tends to result in pleasing no one, so we don’t have a lot of confidence in this approach. But we still like the graph.
Some great thinking out there, what do y’all think in here?
I have been “fortunate” enough to work on products that have two diverse user sets. One is a very technical IT user, while the other is the business user who in most situations is NOT technical at all. The technical user tends to be responsible for integration/configuration and custom development, so they want robust APIs and access to the command line. In some instances, once setup is complete, they are done, but in other situations, they may provide ongoing support or development. The business user requires a GUI with workflow and an easy-to-understand design metaphor. As the business user becomes more familiar with the application, they want access to more and more advanced capabilities.
My challenge is to provide an initial experience that meets the needs of both groups, and provides the business user with a learning curve that lets them run things from the start, but also allows them to grow into the advanced capabilities. If they are overwhelmed by the user experience, they will become frustrated and that leads to lots of calls to Technical Support and/or abandonment of the application, both of which are undesireable.
I don’t think you can just try to find the middle ground because that can keep you at a competitive disadvantage in the market and has the same problem of trying to satisfy too many users and ending up satisfying none.
Thanks, Ivan!
I definitely agree that trying to design in the middle for “both groups” is the wrong way to go. You’ll be investing in capabilities one group does not value, and ignoring capabilities that the other group doesn’t. The only group you satisfy is the business (assuming you don’t overdo it) – and you do that inefficiently.
What is important, as you point out, is designing for both groups, once they have reached a level of competency with your product – where that means different things to each group.