Three Warning Signs
Of an 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
I T 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 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 some-
thing that does 80% or 90% of what you need well, and
ignore the rest so that you don’t overcomplicate it.”
— MInDA Ze TlIn
Brian Fino
ing APIs so that not only can we build against them, but our customers can build against them too. If they want to do something
with their data other than our prepackaged application, we’ll give
them that API. In the past, our customers didn’t know what an
API was — our industries are not particularly cutting-edge. But
now customers are beginning to request and expect them.”
Rule No. 3: Update It Often
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.
“That’s been a really dramatic change in the industry,” Fuller
says. “Google’s probably leading the way, with their incremen-
tal 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 thor-
oughly, 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 differ-
ent 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 ap-
plication is over. As Fuller puts it, “You have to be aware that the
user today has a very short attention span.” u
Zetlin is a technology writer and co-author of The Geek Gap: Why Business
and Technology Professionals Don’t Understand Each Other and Why
They Need Each Other to Survive. Contact her at minda@geekgap.com.
