K.I.S.S. (Keep it Simple Software)

I had an enjoyable conversation today with a trusts and estates lawyer. She is very good about generating regular email newsletters for her clients, and I was curious about the application she uses. I was somewhat interested in the product myself -- it had a lot of appealing features. Not only did it have extensive email functions, it included a customer relations management tool and some interesting database features.

To my surprise, this attorney hated it.

She described spending many hours trying to learn all the complicated features and still needed to invest additional time to get the desired results. She was set to "downgrade" to a product with fewer features.

I think a lot of lawyers can recount similar experiences, especially those willing to experiment with new technology. They waste a lot of time learning how the tool works, only to discover that it works poorly or does a lot of stuff they don't need it to do. They discover the product is feature rich, but the features are incomplete and awkwardly executed. And, of course, each new feature entails potential conflicts and bugs.

The converse also seems true. Simple but well executed applications are a joy. Elegant solutions are satisfying.

When I got the iPhone, for example, I initially was disappointed by the inability to customize. And, when compared to my BlackBerry, certain features seemed to be missing. Over time, however, the missing features have translated into improved usability, flatter learning curves -- and frankly, fun. What I really need is included and done well.  As a result, I'm more efficient and less frustrated.

Heavy technology users want to customize applications and they reflexively search for new features. We think of customization as a way to better match the application to our idiosyncrasies. We want features to maximize utility. But in reality, this isn't about optimization. Usually we customize and employ features just to make applications work, as compensation for poor design.

Technology consumers should resist their initial impulses -- our instincts have been mistrained. Forget about the nifty features. Find something simple that actually works.

D. Mark Jackson

Designing Software for the Workflow

There's an interesting article on Customer Relations Management (CRM) software in this month's California Lawyer.  It does a nice job describing what these applications do,  as well as some of their limitations.  And I was both surprised and pleased to read this section:

But in practice, most CRM systems do require a change in the way attorney workflow is handled on a day-to-day basis. Building a robust CRM system depends on a resource many firms are reluctant to surrender: attorney time.

"Your success or failure with CRM software is less a technology issue and more a process problem," says Andy Havens, a legal marketing consultant and founder of Sanestorm Marketing. "It has more to do with what you're going to require lawyers to do as part of their daily work than [with] the features of the software. You have to know what things your lawyers are willing to do that are trackable."

I find this dynamic to be true with any technology roll out, unless it's completely on the backend.  A great deal of management time goes into developing and then training on the new workflow.  If possible, our technology team works to customize the application to fit our workflow preferences, and facilitate any necessary changes to the workflow as gently as possible.

But isn't it amazing that many developers expect the users to model their processes around the application, rather than the other way around?  And it's not necessarily about customizability.  A lot of enterprise software, while including many powerful features, seems to have been developed with only minimal consideration of the workflow it is designed to facilitate.  Workflow should be a key element of  software design.

D. Mark Jackson