Real Story Group. Make Better Technology Decisions.

Kas Thomas

Are we reaching the limits of UI buildout?

28-Jul-2009

Tags: Digital and Media Asset Management, Web Content Management, Information Architecture, Content Manager Enterprise Edition, Cumulus, R3volution, Sitecore , Tridion 2011, TYPO3

As you can imagine, in the course of covering more than 200 software products, my colleagues and I get to see and touch a lot of different user interfaces, and one thing we've all noticed lately is the trend toward larger and larger interfaces. To put it bluntly, many products (particularly in the WCM and DAM spaces) now have client UIs that are just plain enormous. By enormous I mean busy and option-rich, with tons of controls, and often with a super high-resolution monitor required just to see the whole UI.

In the WCM world, products like Alterian Morello, SDL Tridion 2009, Sitecore CMS, and TYPO3 (among others) have seen their user interfaces grow to the point where even power users find it challenging to learn the product -- and then stay current on it. The same is true, in the DAM world, for products like Canto Cumulus and Mediabeacon R3volution (among others), which have seen UIs grow in tandem with product functionality.

UI sprawl is not limited to any particular tier or type of product, of course. Creeping featuritis has led to bewilderingly complex UIs for Microsoft Word, Adobe Photoshop, and countless other familiar software tools. In the Web CMS world, the problem seems to be compounded by a recent trend toward re-centralization of control and consolidation of roles in web publishing (just the opposite of the trend toward decentralization and specialization that was so common a few years ago) -- whereby power users dominate systems activity, and often system selection.

Looking forward, it's clear that "UI buildout" cannot continue much longer. For many products, cognitive overload is no longer a threat, but a reality. How many toolbars, tabs, nested menus, and clickable controls (not to mention nav-trees in which you have to scroll horizontally as well as vertically to find things) can a mere mortal handle? If a cognitive limit exists, I think we're pretty much there.

The question is, what can be done about it? Is there a way forward?

As a stopgap measure, simply hiding controls based on role can be useful. Many vendors make at least a token attempt to give you control over the visibility of important UI pieces based on a contributor's permissions.

As a whole, though, the industry needs to do a lot better in giving system implementers and admins the power to custom-configure task-based interfaces for different system personas. It can be very difficult (even impossible) in some systems to make a given command just not show up. It's hard to understand why that should be. Not everyone needs every command. Why put controls in a user's face if you don't have to? As noted UI expert Aza Raskin says, "If you notice the interface, that means you're thinking about the interface and not the thing you're trying to do."

It's been said that something like 45% of the features in a typical software system are never used, while another 19% are rarely used. That means the majority of executable code in a product seldom, if ever, executes. Clearly the opportunity exists to scale back UIs. The problem is, products with super-lean UIs don't demo well. In any featuritis arms race, the product that can stand up to the most overspecified RFP has a big advantage.

Maybe there are lessons here for all of us.

Vendors: Strip the UI to a skeleton and make it easy for implementers (and/or administrators, and/or power users) to add functionalities back one by one.

Customers: Stop "requiring the world" in RFPs and PRDs. This only exacerbates the featuritis arms race. And make sure non-tech-savvy casual users (not just power users) are properly represented on product selection teams. It's your non-techies who will push back hardest on hard-to-learn systems -- and ultimately decide the success or failure of the system.

We say it throughout our reports, but: Take time to do some usability testing of your own. Find out up front if a product's UIs are going to be a problem for your organization, and don't assume you can fix the problem with training. Training isn't the answer for users whose tired brains are already, even before you roll out the system, saying, Don't make me think.