John Heckman in his recent blog post, When Is Ease of Use Counterproductive? raised an interesting issue and one I have struggled with in designing advanced interview systems for document automation. He posits that making something too easy encourages foolish and stupid behavior. There is a balance between “constraints on behavior” and making something too simple.
John was likely thinking of practice management systems that strive to use wizards to paper over the complexity of their systems. As a person who routinely turns off the wizard, I can see his point. If you don’t ever confront the data entry form, you will not know enough about the structure of the system to be able to properly work with the data you have entered. I can appreciate a well designed wizard, but too often the wizard makers make assumptions that simply don’t apply to you. And unless the user is exposed to the non-wizard approach, they will often be unable to get the result they desire from the software. Extensive wizards can in fact cripple good software. It is not that they break the software. Rather, it is that they obscure the functionality of the software.
In building document assembly interviews, I am constrained to balance simplicity of design with the complexity of reality. Make an estate planning system TOO SIMPLE, and the templates it produces will only be functional 80% of the time, requiring constant vigilance and tweaks of the final Word document. Make it too complex and the user will not know how to answer particular questions that appear unfamiliar out of the context of the documents they used to edit manually. The solution that I have come up with is a balancing act. Rather than push the complexity under the rug with a wizard, I script the dialogs with an “advanced” option that allows you to expose more complex questions in a particular area. Questions are carefully grouped under headers. There is help text both associated with the variables and on the dialog. With document assembly tools I can also add constraints that prevent bad data from being enter, such as an “division of assets” that might exceed 100%.
There are many purported “simple systems”. The iPOD app store is an example of “simple systems”. DISCLAIMER: I have 2 iPOD Touch devises and a Blackberry Storm. In their advertisements, Apple toots: “There’s an APP for that”. And yet, the sum of the parts is often less than the whole. And that is because each APP is an Island, requiring you often to dual enter data and maintain the same data in multiple places. I find the approach by Salesforce.com and Mozilla Firefox to be quite different. The “APPS” in these cases are plugins that extend the core functionality of the system and allow you to do more with forcing you to separate your data in different Island. Yes, there are thousands of apps for Salesforce.com; but each APP assumes a core set of shared data (Contacts, Accounts, Opportunities) and so these apps together are MORE than the sum of their parts.
And so, when you think of “Ease of Use” bear it in mind with a grain of salt.