The whiteboard

IX.6 November + December 2002
Page: 11
Digital Citation

Letter from the dark side


Authors:


G’day Johnno,

It’s 4 a.m., and the gang and I have been here for over 21 hours trying to re-engineer our system in line with your 70 “usability recommendations.” (We do hope that you and the team are getting some restful shuteye at home.)

We’re waiting for a recompilation of the application to finish, so I thought I’d use the time to drop you an e-mail. I’m not sure whether it’s the caffeine talking (we’ve been on coffee infusions since midnight), but we’re ready to be fair dinkum with you about usability from an applications development perspective.

So, in no particular order, here are some things we’ve cobbled together. Please note that we’re not wanting to put in the boot (even though Bazza looks as mad as a cut snake). Rather we’re trying to make sure that you understand what all this usability codswallop does to us and why we feel it’s not much chop.

(See glossary for bold terms.)

Applications Development Ain’t Easy.

Do you blokes have any idea how hard our job is? For the current application alone we had to bone up on SQL, XML, VBA, PHP, ODBC, and J2EE; half the time we don’t know whether we’re Arthur or Martha!

Also, do you know how much of a squeeze the depressed world economy has put on IT budgets? This means that bosses want more for less. Keeping up with the expected output is hard enough (we often don’t have time to scratch ourselves), but on top of that we’re putting in long hours doing self-study and taking certification exams.

When we’re able to breathe life into an application consisting of disparate technologies and get it working more or less correctly we reckon we’ve hit the jackpot. Then your usability party poopers come in and tell us that we’ve got some spelling mistakes on the screen, or the colors are wrong, or the button labels aren’t clear. Do you appreciate how much of a miracle it is that the system works at all? How do you think the engineers of the space shuttle would’ve felt if, after unveiling their achievement, some galah had said, “that’s all very nice boys but I think the door should’ve been on the other side”?

It’s easy to bag out the work of others from a distance, especially when you don’t have to spend hundreds of hours redoing it. And since most of you come from a “touchy-feely” background (rather than from engineering), you’ve no idea of what’s involved. We’d like to see you all trained in application development techniques so you understand the impact of your airy-fairy recommendations.

Perceived Productivity is Critical to Our Career Success.

Further to the previous point, bosses measure our productivity by how quickly (and cheaply) we can roll out new applications. In these times of job uncertainty, we’re often packing death about getting the bullet and it’s sometimes like being on a surfboard with a circling three-meter grey nurse, where every usability criticism has the shark taking another bite out of the board.

Your usability laboratory, with its bright lights, one-way mirrors, hidden cameras, and jumped-up blow-ins is a place of public shaming and death for us, much like the village gallows in times of old. We didn’t come down in the last shower, so we’re well aware that some users will have problems with any IT application (after all, there are still people who think that CD drives are drink cup holders and that mice can be used as foot pedals). For some reason, you always manage to choose users who’re a banger short of a barbie as your test subjects. They spend forever looking at screens like stunned mullets, where anybody with a modicum of common sense could figure out what to do next.

`In this scenario (drongo users and bad publicity for us) it shouldn’t surprise you that we’ll “argue to the death” in defence of our applications, particularly when the usability test occurs at the end of applications development where even minor changes need a massive amount of re-engineering.

If we’re going to be subjected to the humiliation of the usability lab, you need to make the bosses understand that it can’t be left until the end of the process. They also need to be told that project schedules will slip as a result of usability testing and that they shouldn’t expect my team to put in 100 hour weeks in a futile attempt to play catch-up.

Application Development Has More in Common with Dilbert Than with Software Engineering Textbooks.

The software engineering texts tell us that applications development proceeds in an orderly and systematic fashion and is amenable to a high degree of control. That conception is about as useful as a glass door on a dunny.

Because “the devil’s in the detail,” no number of mind-numbing meetings (full of talk about what we plan to do) can ever get close to what’s involved in actually doing it. Only when the work’s being done do the problems appear, turning the project plan to custard. However, despite obstacles and setbacks, there’s still commitment to “the plan”—and this results in the lemming-like rush to completion in which all “low-profile” activities (read: “those that won’t be missed by senior management or whose impact won’t be noticed for some time”) are jettisoned. These include documentation, testing, and, of course, usability.

In this project, as with most others, we’ve put in long hours and weekend work and have been as flat out as drinking lizards. This has left us tired, narky, and ready to do our block at the slightest provocation. When you and your goons march in and take shots at us about pedantic issues, we quickly get a gutful. We feel that you should be equally responsible for the success or failure of the project (rather than being an external “usability police”) and that you should have as much to lose from project failure as we do. Furthermore, you should be required to help the team resolve usability issues (and stay back working long hours with us, if your recommendations demand major changes). Even if you can’t do the in-depth technical work, we could certainly find tasks to keep you occupied, and working together on a common goal under challenging conditions would help promote a spirit of mateship between the groups.

Usability Deficiencies Can Easily be Compensated for Via Documentation, Training, and End-User Support.

Here we are busting a boiler to address some “usability issues,” when they can all be worked around! It’s not a serious problem like having errors in the application and people are enormously resourceful in getting around IT difficulties. You gave me a couple of books a while back. In one, the authors described how hard it was to change a booking on a certain airline reservation system. Yet, despite a few challenges, the booking clerk was able to successfully make the change without chucking a wobbly (so what if she had to scribble down a few notes along the way?) Most people using computers in the workplace have a little book in which they write down everything they need to know and work quite happily using this arrangement.

A way of addressing usability issues that doesn’t bring the project to its knees is to provide users with well-written manuals, training classes, and/or access to an efficient help desk. In your other book, some old geezer had problems using everyday things like doors, because he couldn’t tell from the shape of the handles whether to push or pull. This could have been resolved by attaching simple “push” and “pull” labels to the doors rather than by calling for a redesign of the handles.

Another reason why we don’t like tackling usability issues by tinkering with the application is that the cost of applications support is almost always accounted for separately from that of applications development. In this context, if we increase our development costs (and risk missing our deadline) through usability work, and this work results in lower support costs, the support group will receive accolades at our expense. Even Blind Freddie could see that this isn’t a good idea.

So we don’t know why you and your usability Gestapo give us such a hard time over nothing. Why not hassle the training and documentation people? We have everything to lose under the current arrangement: it means more whinging (from you), more work (for us), and no benefits being passed back to us.

Technology is Smart and Users are Stupid.

I shouldn’t be telling you this, but before too long your efforts will go down like a lead balloon. Sure, right now the bosses are revved up and we’ve got the new usability lab, but within a few years the lab will close and you’ll become part of some namby-pamby “quality assurance” group. The reason for this is that users know machines are smart and they’re morons. If obscure commands are needed to drive an application, that application is considered “complicated” or “advanced” (as though that’s a good thing). People who can master such an application are elevated to guru status (you know a few Unix nerds, I’m sure!) and allowed to come to work in unwashed jeans and sweat-impregnated T-shirts.


Only a major cultural change will make people realize that bad design can make devices hard to use.

 


Help desks have done an outstanding job of making users realise what numbskulls they are by asking inane questions like “is it switched on”? Even workmates are quick to have a laugh at the expense of less computer literate team members, and the difficulty you have in finding volunteers for usability tests shows how much people have accepted the “machine is smart, I am stupid” belief.

A major cultural change would be needed, not only with computers but with all technology, to make people realize that bad design can make devices hard to use. This is something that would have to be driven by the usability community, but thankfully we’ll be pushing up daisies before it takes hold.

We’re Physically and Psychologically Separated from the End Users.

We wouldn’t know our real end users if we fell over them. We’re in a different building and never get to have a squiz at them in their working environment using our applications. We don’t go to the same watering holes; all we see are user managers who boss around the invisible end users but hardly use the application themselves. How can we give a toss about their needs and concerns when we wouldn’t know them from Adam?

Furthermore, end users are the bottom feeders within the corporate pond, and pleasing them has no political value. Would senior managers notice if users weren’t happy with certain features of an application? The help desk might receive a few complaints, but would these be passed up the line?

If you want us to take usability seriously, it’s not enough to show us a bunch of bozos who’d have trouble tying their shoelaces. We need to know real end users. The whole usability lab thing is too artificial; we need real people in the real world. Ideally, we’d be accommodated with them for the duration of any project and get to know them better. You’d also have to persuade senior management to take end users more seriously, to find an efficient way of collecting their views, and to respond to their concerns. Right now our applications only have to please the user managers (and that’s as easy as falling off a log, given that they’re not regular application users).

We aren’t Trained in Usability Techniques.

Most of us don’t know squat about usability techniques. We often come from science or engineering backgrounds and have no worries using complex systems. When we build applications, we construct them for people like ourselves to use and have difficulty even understanding what their problem might be.

Today’s graphical interface tools allow enormously rich user interfaces to be created, and we like to cover our screens with every gadget available and to use a wide variety of fonts and colors. You also need to know that bosses go ape over screens with more controls than the flight deck of a 767 because it makes them feel like they’re getting their money’s worth out of us.

If you want us to worry more about usability, it’s not enough to just do usability testing. You must teach us what you know and work with us right through the project. You’d also have to convince our bosses that simple-looking applications aren’t designed by simpletons.

Johnno, I’ve got to stop here. Right now I’m so hungry I could eat a horse and chase the jockey, so it’s off to the vending machine for well-balanced breakfast of chockie bar, potato chips, and jelly beans. I didn’t mean to stir the possum in writing this, but I did want to clear the air between us. Couldn’t you blokes just tone it down a little and take more of a "she’ll be right" attitude? Honestly, application developers have a hard enough job already, without starting to worry about the users.

Cheers,
Thomas McCoy
Applications Development Manager

Author

Thomas McCoy has been working in the bush capital of Australia, Canberra, as an applications developer for almost 20 years. Since completing his master’s degree in human factors, he’s become increasingly interested in usability issues and is currently an IT consultant to the Department of Defense. From the tearoom, he often sees a mob of eastern grey kangaroos lying languidly in the sun, munching on bush grass, and he wonders if the users will ever look that contented.

Thomas McCoy
Canberra, Australia
thomas@mccoy.name
www.thomas.mccoy.name

Whiteboard Column Editor
Elizabeth Buie
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
+1-301-921-3326
fax: +1-301-921-2069
ebuie@csc.com

Footnotes

This letter is a composite of Thomas’s observations and the views of some application developers he has worked with. Despite the difficult situation described, many developers do take a personal interest in their end users and try to make their applications as usable as they know how to.

Sidebar: Glossary

airy-fairy: of little substance
as flat out as drinking lizards: extremely busy
as mad as a cut snake: very angry
as useful as a glass door on a dunny: completely useless [dunny = toilet]
bag out: to criticise scathingly
banger short of a barbie: dull-witted, stupid [banger=sausage, barbie=barbecue]
Bazza: variant of name “Barry”
Blind Freddie: imaginary person used as standard of extreme incompetence
busting a boiler: overdoing it, working hard
chucking a wobbly: getting upset
codswallop: nonsense, rubbish
didn’t come down in the last shower: being smarter than one is given credit for
do our block: lose our temper
don’t know whether I’m Arthur or Martha: to be in a state of confusion
drongo: stupid person, fool
fair dinkum: honest, genuine
galah: fool, simpleton
get a gutful: reach the end of one’s tolerance
getting the bullet: to be dismissed or fired
give a toss: to be concerned about
go ape: to react with unrestrained enthusiasm
have a squiz: take a look
jumped-up blow-ins: conceited, self-opinionated, casual arrivals
like a stunned mullet: to look bewildered
namby-pamby: wishy-washy
narky: irritable, bad-tempered
not much chop: not worthwhile
packing death: to be afraid
pushing up daisies: to be dead
put in the boot: to attack without restraint
squat: anything
stir the possum: cause a commotion
whinging: complaining, especially in an annoying way
wouldn’t know them from Adam: to know nothing about them

©2002 ACM  1072-5220/02/1100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2002 ACM, Inc.

 

Post Comment


No Comments Found