The New Rules for Enterprise Apps

An insurance company decided to roll out an application for its sales reps. The new app would give them a wider selection of products to offer customers when out in the field. Information on those products was stored in a legacy mainframe system, so the company created a Web interface that let reps query the database to get details on offerings.

1 2 Page 2
Page 2 of 2

There was a time when updates, upgrades or any sort of changes to the software used at work were met with a general groan. But that time is well behind us. These days, employees expect, and even want, frequent updates to the applications they use.

Friendly or Unfriendly?

Three warning signs of a user-unfriendly app

A user-friendly interface is paramount if you want employees and external users to adopt an enterprise application. But what, precisely, makes an app user-friendly? That's a complicated science, with detailed books and research papers devoted to it. But if your app has any of the following three elements, that's probably not a good sign.

1. Too many places to make choices, especially on the same screen. "If you're ever working with a screen that has 40 input dialogs and drop-down menus and radio boxes, it's not really because you have to do 40 different things," says Brian Fino, managing director of Fino Consulting, which advises companies on IT investment. "If you're designing a simple, well-thought-out interface with just a couple of discrete controls, that's easier to use and also easier to test. So hopefully it will be a more stable app."

2. Too many screens. "There are application development principles that really transcend the question of enterprise or consumer," says Gartner analyst Bill Clark. "One of them is the 'three-click rule.' Any time a population has to click on a link or traverse through to another screen, you lose about half of them, in terms of their paying attention or keeping the context of what they were doing in their heads. So after three clicks, you've lost most people."

3. Too much functionality. Consider the first two items in combination. If you can't bunch too much on one screen, and you can't have too many screens, then you're led to an inevitable conclusion: You just can't have too much stuff.

And that's a good approach, according to Mike Croucher, head of IT architecture and delivery at British Airways. "You can't make these things too complex," he says. "You've got to really think about the amount of data and options you can ask people to select in any one transaction. If you start taking people through too many transactions, they start losing the will to live. So you have to look at the value of each piece of information you put on the screen."

The solution, he says, is not to try to create an app that will solve all problems for all users. "Our applications tend to be delivered on the 80/20 rule. That is: Deliver something that does 80% or 90% of what you need well, and ignore the rest so that you don't overcomplicate it."

-- Minda Zetlin

"That's been a really dramatic change in the industry," Fuller says. "Google's probably leading the way, with their incremental changes released nearly every week. You don't know when they're coming -- you go to the interface and it's different. And more than 90% of the time, it's better."

He adds, "We used to use the waterfall method. We would create a specifications document, argue about it until it was etched in stone, and then the developers would work on it and release it." Now, he says, that way of working is "turned on its head." Instead, he and other experts favor an agile development approach, in which new application versions are routinely released every other week, with user input sought between releases. "We make incremental changes," he says. "And because the software is cloud-based, there's not the hassle of sending out disks. You've tested each version thoroughly, so you just push it out to users. And their expectation is that it's OK to have changes. The response is 'What does this do? Let's try that!' instead of 'Oh no, you changed my interface!' "

In fact, Croucher says, it's a good idea to experiment with different user interfaces, changing them frequently. British Airways even conducts an in-app form of A/B testing, in which some users are given one interface version, and other users are given another, to see which works better. "You need to get that segregation of back-end functionality and business services, which need to be correct, and front end, where you can be more experimental," he says.

That doesn't mean, however, that you should expect the back end to remain static. While you may not want to make changes on an every-two-weeks schedule, it's likely impossible to create truly user-friendly and appealing apps without overhauling the underlying functions and databases.

In British Airways' case, that meant changing the way fares were calculated, because the complex tangle of rules involving Saturday stay-overs and many other elements were nearly impossible for customers booking tickets online to understand. "It never made sense why some fares were more than others," Croucher says.

There was no way to do that by improving or changing the user interface alone. "We learned from our customers that you have to simplify the back end overall," he says. "If a process is too complex, you can't make a simple and user-friendly interface for it."

And if you can't make a simple and user-friendly interface, you're sunk. With mobile devices proliferating, screens in every direction, and more and more competition for mindshare, the time when you could count on anyone stopping to learn an application is over. As Fuller puts it, "You have to be aware that the user today has a very short attention span."

This story, "The New Rules for Enterprise Apps" was originally published by Computerworld.

Copyright © 2012 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Discover what your peers are reading. Sign up for our FREE email newsletters today!