Mark Suster has a line in his recent blog that I think perfectly captures the ideal design goal for software:

I think that with this simple statement he captures the direction we all need to be heading to produce successful software design. Particularly in enterprise software, we are always conflicted between putting the newest and most powerful feature front and center and the resulting complexity that puts off users.

By keeping this philosophy in mind, we can help guide our results to something that approaches well designed consumer software in its simplicity and yet meets the requirements of at least the majority of the power users.

The best examples in modern software are IOS applications. Have you ever seen a manual for one? No, well you won’t for the vast majority. They aren’t needed. The main interface and functionality are constrained to do the task at hand (or finger, as it may be). It has to be self evident because there isn’t room for more options. And if the user doesn’t ‘get it’, it is game over. However, some of these same apps have some major configuration options, that change the nature of the app, hidden behind the gear icon. My favorite example was setting up a tethering-router app. This does the same thing that the PC app I purchased a dozen years ago that came with an inch thick manual. But I was up and running in a few self-evident steps.

In the past, a common solution in enterprise software has been to provide ‘role based’ interfaces for different levels of user. However, in some cases this too, causes problems for the inevitable ‘tweener’ who needs more than the basic but it confused by the ‘open class’ UI.

The idea of a personalized, configurable experience is ideal. Initial rollout can be with the normal, simple, elegant (we hope) model. But as experience drives a desire for more power and flexibility, additional aspects can be turned on or configured to suit the need. Done right, these configurations are simple parameters which are relatively easy to manage in a SaaS, multitenant environment and/or through upgrade cycles.

Yes, this complicates the software design quite a bit, but that is part of the point. Lets do our work up front to focus on what is really needed and hide the complexity for where it might really be needed.