Enterprise Software - The Worst Kind of Swiss Army Knife

I’ve been doing a lot of thinking lately about enterprise software and how it fits into the current river of super-simple, super-focused web-based apps in the market. When I was designing enterprise products I spent a 60%-40% split in time focusing on desktop versus web application design. Most of the web projects end up being an afterthought or was viewed as a analog or mirror of the rich functionality. I believe that’s changing and business is evolving to a point where the focus can justifiably be on the web. That said the same problem plagued overall direction of both platforms.

The Knife

I remembering having a conversation with a manger in the past about what the biggest frustration with the products I was designing was. My response was this: “We design a swiss army knife, which is great. Lots of features that fill various needs, always available. But the problem is our interface forces the user to have every blade and gadget open at the same time, by default. So you have a tool that’s infinitely useful but on the verge of useless. If all the blades are open all of the time you’re not just going to cut yourself, but you’ll never find the toothpick.” I think the analogy struck a chord, and I think it’s still the biggest hurdle in enterprise and high-end commercial products. Products are driven by market and internal pressures to enhance functionality, and no matter how good your interface is, if it’s release out-of-the-box with everything turned on you’re going to confuse and mystify your users.

That Damn Box

Solving this issue goes well beyond interface design conventions, snazzy interactive widgets or progressive disclosure of elements. You have to look at how the product is delivered, implemented and ultimately rolled-out to users. There is a tendency for interface professionals (developers, designers, UX folks, etc.) to ignore the final piece in the product puzzle. Often rolling out large enterprise applications takes months to years, and on-site developers work to enhance and extend the core application to meet specific client needs, integrations, etc. If you’ve never met with these folks or seen what your product looks like at the end of this cycle you’d be shocked. Many times a large portion of this effort is in TURNING OFF functionality that’s exposed out-of-the-box. Why? Well we have contractually obliged ourselves to having a boatload of new and great features in the product, that’s how we’ve gotten customers to pay for the latest and greatest. So there’s a perceived need to show all of that off - every-time - something new is rolled out. Out-of-the-box tends to mean the newest stuff in the box, which makes sense for marketing but makes no sense to a user. If it’s a new feature or considerable enhancement to existing functionality chances are slim to none I need that up and running by default.

The Fixes

There are a few potential remedies to this issue that may surprise development and marketing teams.

Turn it off - When a feature is introduced turn it off by default. This requires a robust feature management capability that’s exposed to the end user - not just admins. Give users the power to manage what they see and how they use it.

Tell ‘em about it - Taking a cue from successful single/limited focus web apps, make sure you have a message center or place within the product to announce changes and tell your users about the new features. Rather than confound and frustrate them by adding new things, simply tell them there are new things. Empower them to add what they need and make it as simple as a click from your messaging center.

Let them test drive - Even though your developers spent 200 man months on this great new enhancement, there’s a chance a user may not like it after they’ve activated it and had a chance to play around. They may prefer an old way or simply not find a need for your great new widget. No worries, just give them the ability to turn off functionality as easily as they can turn it on. Check your ego at the door, if they don’t like it’s not a big deal - they will be happier with your product if it concedes gracefully than if it’s a jerk about going away.

Put it in the manual - Documentation is softwares oft-forgotten ally. Put it in the docs, make sure users can search for new features the day the product ships. If we make documentation a key component in delivering the message of new functionality it we be elevate its usefulness and necessity.

If you’re involved in enterprise or larger commercial software endeavors I hope this helps. If you’re already doing this drop me a line, I’d enjoy hearing about your stories.