Slashdot Mirror
Why Users Hate IT Products and Developers
bfwebster writes "The Washington Post has a commentary by one of its regular columnists, Marc Fisher, on why computer users hate what he terms 'our techie masters.' One of his more pungent and, I suspect, on-the-money comments: 'Computer training has become the living hell of the American workplace...each new system is more confounding than the last, and each new product strips away many of the advantages of the previous system.' Not a Luddite screed; more an angry outburst asking why commercial software systems are often so wretched. Worth reading and pondering."
The short answer would be:
RTFM
The software is usually designed for the wrong reason in the first place: to fulfill a marketability niche seen by some buzz-word driven demand. It's sold from a marketing and sales rep, whose usual job description could be summed up under "schmooz with customer", who pulls out his checklist of latest technologies to make sure he promises X, Y, Z and hyperbaric interoperability with toasters from obscure places like Kansas.
These requirements and obscure promises are handed to engineering who satisfy the technical aspect and ship it. Never have any of the QA departments I've seen have a dedicated usability expert; most of the QA engineers were just re-tasked programmers without any HCI design principle background or experience.
So, since corporate and enterprise level software development is driven by the sale by those out of touch with the true needs of those making use of the software the incredibly wide gap develops that frustrates the @#$( out of everybody.
Any spoon would be too big.
Also, why in the hell are companies "upgrading" constantly? What ever happened to the days of buy something and use it. Hell, that's what I do for my tiny business. Every "upgrade" is expensive and time consuming. I'll just use what I have, thank you.
Perhaps when developing a new system the developers could take some time to study the methodologies that are used in the gaming market. After all Games are highly technical but must be very easy to learn and use to be popular.
If anything they might start thinking more about the end user then they do right now
Example - Sniffer. Great piece of software. Does everything you could want. But it's so confusing with random tabs all over the place, buttons that are similar but do different tasks in different parts of the program, and completely lacking in intuitive interface....
He must be new, and uninitiated by his bofh. My users would commit suicide before uttering such heresy. Almost.
Not a Luddite screed; more an angry outburst asking why commercial software systems are often so wretched.
Heh, let's give 'em all Linux kernels to play with, and sendmail.cf files and procmail filters too while we're about it, and watch their eyes shine with joy as they appreciate the wonders of the non-commercial world...
Er, maybe not.
There is a good point there. Users don't always understand what they want, or can't think through the "unintended consequences" of a system change. They see the result, not the process.
But on the other hand, I know that us geeks have a tendency to read our own agenda into what we're asked to provide, and to ride hard on anyone who disagrees with our intepretation of "how it should be". We deliver a wonderful process, and if it has a good result, that's just icing on the cake.
I used to work with a group of professional architects, and I learned a lot from watching them take user input, question it, refine it, and try to turn it into a project. They spent a lot more time learning about the customer's personality, what sorts of things they liked and didn't like... and the ones who were consistently loved by customers were the ones who were the best listeners.
(A nickle to the first person to identify the person I quoted above!)
In software..
1) Corporations think it's a good idea to add more features to their software.
2) Corporations have no idea what people actually want to do with their software's new features.
3) Corporations fail to realize that what we often want are not new features, but actually smoother design, better ease of use, more speed, and more stability.
Thus, what we get is "bloatware" such as ICQ - where so many new "features" are added to the program that it becomes impossible to use and navigate even when you want to use the program for even the simplest functions. (When I got the latest version of ICQ it took me 5 minutes to figure out how to add a new contact by UIN#.) AIM is headed this way, too.
I can't stand Office XP because of all the stupid features you don't need.
Even Office 97 has a large plethora of thoroughly useless features.
Send To Routing Recipient, Send To Fax Recipient, Footnotes, Comments, Document Map, Field, Cross-Reference, Index & Tables, Insert Object, Insert Bookmark, Look Up Changes, Track Changes, Change Case, Style Gallery, Merge Documents, Letter Wizard, Formula
It gets worse as the version numbers get higher. Maybe what we want is more ease of use and less damn paperclip animations.
So 20 years ago I would have had to pay more for an airline ticket than today, to fly to Washington, to by a copy of the WP, to read whatever this bozo has to say. Now I can do it sitting at my desk at the arse-end of the world withing seconds of him hitting the "publish" button. No progress or convenience there that I can see.
-- Free software on every PC on every desk
Note however, that Fisher doesn't propose returning to his trusty Underwood typewriter to write his columns.
Opinions on the Twiddler2 hand-held keyboard?
Upgrading to XP would suck. I've used it, and it ain't purty.
But come to think of it, this is one area where Linux is *much* nicer from an end-user perspective. I've been using Linux since RedHat 5.0, running Afterstep. I 'perfected' my GUI years ago, and it hasn't changed since. No matter how many times I've upgraded. Granted, the other apps I've used have changed, but this one constant would be nice for many end users.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
This is exactly the problem, so far as I know. Whenever I've seen an app, I pick it up instantly. Easy to hack stuff, read help, etc. The interface is mostly intuitive because the programmers designed a lot of things like I would. Not always, but at least I can reason it out. The "clueless" "end-user" just thinks fundamentally different. For whatever reason, they can't figure it out. Just as I can't hear the difference between tones or pick up a dance step or whatever. So, even if I design things I think have a good interface and is intuitive and so forth, many of those out there still don't get it.
I think part of the problem is fear or lack of real desire to learn in or something pyschological that prohibits them from picking it up quickly. But there is a fundamental difference and that has created a divived between those that can and those that cannot.
In times like these, it is helpful to remember that there have always been times like these. - Paul Harvey
Whereas Righteous Free Software programs like crontab and gnu make and grep always have intuitive, orthogonal systems that make sense at once!
Mind you, oddly enough I do find vi[m] extremely intuitive.
Whence? Hence. Whither? Thither.
The first answer is simple. Ease of use and power are inversely proportional. If you increase ease of use you decrease power. A CLI with toos like grep is powerful, but harder to use than F3 in windows. You can sometimes get more power without losing ease of use, but only to a certain extent.
The second answer is that people fear computers. The tech industry on purpose or by accident has created the illusion in people's minds that computers are difficult to master, extremely complicated, and hard to learn. This is not the case. I tell people every day to build their own computers, and they have this fear they will mess it up, or that its difficult. In fact it is no more difficult that putting together a set of legos. Square peg and square hole. If people stop fearing computers and begin to believe they are simple, then people will have an easier time learning them.
The third problem is trainers. The method of teaching computers sucks. People learn processes, click this, click that, then click this. They don't know the meaing behind what they are doing. To use the old car analogy, they've reduced the number of controls in a car to steering wheel, two pedals, and stick. The driver doesn't have to know how the car works, because they can memorize what all the controls do, since there are few. In a computer it is impossible to reduce the number of controls to so few. So in order to make use of it, you have to know at least a little about how it works. The biggest thing people need to learn is file systems. We all know about the metaphors of desktops, files and folders. But common folk just don't get it. Because of this "easy to use" programs like MS Office become difficult. Trainers should teach people the parts of a computer, how they work, how their operating system works, and all the basic things that apply to everything they do on a computer. Once they comprehend this much, picking up a new system is not so difficult. Instead the trainers just say "click on the OK button in this box". If they don't know the meaning of this, they don't know what to do when something weird happens.
Summary
A)power or ease, can't have both
B)don't fear the reaper
C)learn the basics then the specifics
The GeekNights podcast is going strong. Listen!
In a large company, that is true. I've sat in change meetings, where what the company wants is discussed and the IT drones are charged in implementing it.
Now I'm MIS/CIO/CTO and chief bottle washer for a small/mid sized company (~200 users). No one here has a clue how to 'implement policy'. I tell them that the domain security policy should be set to disallow users from installing software, as they may bring software from home, which is illegal and the company may be libel. They hear "disallow ... users ... installing software ... illegal ... company libel ..." and hear $ker$chink$. Anything technical . . . it's just deer in the headlights. Implement that policy . . .no way.
I am the IT person, and it my job to see the need for a policy, decide on that policy, and implement that policy.
"History doesn't repeat itself, but it does rhyme." Mark Twain
From what I have seen, not having the IT staff train all the employees is a good to avoid friction between IT and the other departments. Have IT train a few enthusiastic and knowledgable non-IT people, and then have those people go out and train the rest of the employees. The teachers will be able to sympathize more with regular employees, and the regular employees will look at the teachers with more respect than if they were IT.
They're on to us! Hide all the evidence that we've been deliberately writing confusing software and in an effort to become their techie masters!
Remember: You have no idea what they are talking about and we never had this conversation.
I'm one of those software instructors who provides the training on the huge custom software package to the customer.
Typically when I arrive on site to show the customers the software we just spent a year creating for them, (**after the customer signs off on the requirements**) and I show them some super wham-o-dyne feature that is not included in the base package, I usuallyt get one of these responses...
1. (90% of the time) What a stupid feature. Why do we have that? Does anyone on earth use this feature?
Typical answer: No one else has it but you, your firm asked for it, and we spent about a jillion hours of developer time working it in and testing it even though the only person on Earth who thought it was a good idea was your project manager.
2. (10% of the time) What an excellent feature! I'll really use that. It will make my job easier. I'm glad we have this super wham-o-dyne feature.
I've seen it again and again. Most of the software ends up confusing users and being far too complicated because a few people insist on adding bizarre stuff to the base package.
I've seen the same thing in some open-source projects too, where the main developer can't resolve (or doesn't want to resolve) a dispute between two other coders, so they add in "options" so everyone can be happy. But it sometimes ands up making the final product a mess.
And as for spending enormous amounts of time in training on the new computer systems, I have to say that many times customers demand it.
If a customer lays down a lot of money for a custom software package, they simply expect an instructor to appear on site, in a tie, wielding donuts and coffee and lunches. We have CBTs that take about 2 hours and cost virtually nothing and cover the base package really well, but customers would rather have half thier staff sit around in a class room for two days instead. For non-technical personnel especially, they just demand that level of service if it's needed or not. So at least in my case, I can't take the blame for forcing the end users to sit through training! Guilt no more!
Never confuse feeling with thinking.
Still, there is a counterargument that the "we hate 'techies'" pundits tend to gloss right over. It can be encapsulated in the old saying, "if it were easy (or fun) they wouldn't call it 'work'".
When Indycar racing went from smooth shapes to lifting bodies, do you think that race car drivers just jumped in the new cars and set records? No, I imagine they spent a lot of hours at the track practicing, I mean working. When lumbering went from 2-man saws to chainsaws, and from chainsaws to diesel logging machines, do you think old Sven just picked up a chainsaw and got started? No, I imagine he had to do a bit of training and practice so he wouldn't cut his leg off. If Shakespeare showed up today, would he start off with a best-seller, or would he have to do a bit of research about modern society, language, etc? In other words, a bit of... work?
You see where I am headed. When a simple change is made to a computer system, the worker bees who use that system in their daily tasks expect that it will just automagically be understandable to them. None of that nasty "work" here - it's a computer!
Now since "techies" spend 40% of a typical day teaching themselves new systems (since Marketing bought it but forgot to budget for any training or support, IT has to figure out how to make it work. You don't understand the procedures for analyzing sales of women's underwear? Better learn that quick too so you can get the new system set up right!). We do the work. The worker bees just kvetch.
That's another line of thought, anyway.
sPh
The short answer seems to be "get a mac". Ease of use, standard ways of doing things, tendency to failsafe even if it wont let you eject the disk, and desscriptive error messages are the hallmarks of mac's human interface. even the computers cost more because in part they have higher standard for fabrication and higher level of standard features (fire wire, ethernet) so the software and users can count on commonality in operation and fewer options to choose from.
microsoft on the otherhand has won the market by doing exactly the opposite. Proliferation of features. Constantly changing features. This permits both the embrace-and-extend and the planned obsolescene (word 5 cant open word 6). It also muddies the waters so much thet people give up any buy the product with the most features rather than the product that integrates its features the best. And it lets them release code as they go, no need to plan ahead, just slam out the next feature.
This is not an isolated effect. its well documented in economics theory under the rubric "bad apples drive out the good". meaning when the buyer has insuffient information to make a comparison between good and bad before the purchase, then it becomes a race to the bottom, or a race for irrelevant aspects that a buyer can judge.
I am reminded of Dilbert Interviewing the elbonians for iso9000 compliance with a documented software development feature:
Dilbert: so what is your process for code development?
Elbonian1: We hold a village meeting and boast of our skill
and curse the devil spawned end user.
Elbonian2: sometime we juggle
Elbonian1: Then we slam out some code and fo roller skating
The amazing part is that as long as they always follow their process they are ISO 9000 level 2 compliant. They might even generate uniformly better code than someone without a process.
Some drink at the fountain of knowledge. Others just gargle.
As much as i've personally spearheaded various upgrades throughout my time working with computers this article raises a very interesting point.
I can't remember how many times I have had users almost beg me not to do upgrades. It is not as if they didn't care about security concerns or the latest greatest version of the software, it's the trouble of having to re learn how to use the software. My most recent experience was with Quick-books Pro for Macintosh. The small business I worked for had spent approximately 3 years working with a copy of Quick-books Pro 4.0. All the inventory and accounting information had been tweaked to suit this particular business and for the most part everything worked as it should have. From my perspective this outdated copy of Quick-books was a constant thorn in my side. It had numerous bugs and the user interface was awful. Well, one week ago I got a call from the bookkeeper of the business. She was delighted to hear that Inuit had released a copy of Quick-books for OSX! This shocked and surprised me as I was under the understanding that Inuit wasn't going to release any more copies for the mac (not enough demand the phone rep told me). As I headed back into the shop to help do the upgrade I had visions of a improved user interface complete with networking support. To make a long story short they didn't change much. In fact they managed to remove some of the features (perhaps bugs) that my client had come to use quite frequently. The toolbar comes to mind. In the older version of Quick-book Pro the toolbar had about 15 or twenty buttons with icons. It could be moved all around the screen and even disabled if needed. The best part was the ability to add almost any report to it. The owner and bookkeeper of the company had become very used to opening the pending sales report from the toolbar. The new version changed that, you could no longer add reports to the toolbar. You where even limited to less spaces in the toolbar than the older version! After spending a few more minutes working with the newer version I discovered quite a few bugs that where still present. This was definitely not an improvement.
I think this outlines one of the basic problems that programers have in relation to their users. What is obvious to the programer or even the power user is not obvious to the end user. For programer the task up dialing up is as simple as finding the ppp program and telling it to dial. For the end user this logical progression of steps isn't so obvious. Why do they need to know what a dialer is? Why not have the system just work as expected. I find it hard to come up with concrete examples of this problem because most every system I work with is logically laid out. For the client that I work with it is not. He is a mechanic and what is logical for me isn't logical for him.
In my most humble of opinions apple has made great progress in this regard. They have tried to keep their interface consistent across many changes in the underlying operating system. Even when they made drastic changes to their system as in the case of OS-X the user interface was still quite the same. However small things did change. Once again from a computer users perspective moving the status icon for the dialer to the upper right hand corner isn't a big deal. But for my client it is just one more annoying thing he is going to have to relearn.
Computers are tools. I feel that the industry sometimes forgets that with every change we make in the name of progress. I for one love having a updated system and latest technology but for my mechanic friend a simple consistent system is the most valuable asset.
I get pretty sick of these stories. I certainly understand that there's a lot of bad software and user interfaces out there, but I'm aware of it, and I put a huge amount of effort into designing interfaces to be intuitive to whoever's going to use the system.
However, here's how my projects go: we get a contract in mid-January to write a custom software application. It has to be completed by, say, May 1st, because that's what our sales dept. sold them. They never asked an engineer how long it would take, they just promised the moon to get the contract. Then, we write a functional specification, and give it to the customer for review. We need to get it reviewed and signed before we can move forward, but for some reason, my contact with the customer doesn't have the authority to sign anything. Not only that, it goes through countless revisions as the customer finally realizes they don't actually want what we sold them. Of course, the deadline of May 1st never changes, so by the time the functional spec is approved, it's April 25th, we've had to start writing the application without a fully approved functional spec, and we've got a week to finish writing, testing, and debuging the application, so no matter what, we're going to deliver late and overbudget.
That's when your boss comes by, shows you the budget numbers for the project and says, "We can't afford any more time on this project, so just do whatever it takes to make it work." Making it work does not mean spending hours designing and revising user interfaces to make them intuitive. I hate it, but that's why software interfaces aren't intuitive.
"I have never let my schooling interfere with my education." - Mark Twain
The author got it almost exactly right. When you study the Myers Briggs Type Indicator (MBTI) for techies you find that they are made up almost entirely of 4 types INTP, INTJ, ISTP, and ISTJ. nearly all the core software that runs the Internet was written by INTP and INTJ people. (In general INTs are more likely to like python or lisp while ISTs are more likely to like Perl.) NTs are concept oriented with STs are detail oriented.
INT*s make up about 2% of the population and IST*s make up about 10% of the population. The key is the IT in the type. "I" stands for Introverted and "T" stands for Thinking. The ITs make up only 12% of the population. The opposite types, the EF Extroverted Feeling folks, make up 36% of the population. The EF folks like to talk to people and make friends. The IT people like to learn things and make systems that work.
The result is that the people writing the code have a point of view that is shared by only a small minority of the population. While the largest subgroup of the population has a point of view that is exactly opposite of the techies.
Obviously the techies can not design for the "feelies". And, the "feelies" will not take the time to communicate with the techies. They write us off as "geeks" and "nerds" and belittle us every chance they get. While we tend to call them "air heads" and ignore them.
There really are two cultures. Until people on both sides of the divide understand that the divide exists and work to bridge it, we will keep seeing articles like this one.
Stonewolf
"I think a lot of this has to do with the elitist mind set of a lot IT workers. They see themselves as the masters, the ones who ought to be in charge because so much of the work is done through systems they built. But really, they should think of themselves as servants, trying to build the best system they can to support the end-users. After all, in a business setting, the end users are the ones who produce the true value of that business. IT people are just there to make it easier."
This is dribble. Pure, 100% unadulterated Dilbert. I am thoroughly fed up with this "master, servant" BS.
Why do IT folks worry so much about what their position is relative to non-IT folks? How do we come to the point where IT pin-heads dictate that people who work in the same organization are to be referred to as "customers"?
Lets set the record straight. People who work for your organization and do not happen to be in IT are co-workers and peers, not "customers". They don't pay you, they can't fire you, they can't send you back under warranty and you don't get to refuse to do business with them. When they fuck up systems you have as much right to complain about them as they you. I'll begin to behave as though non-IT folks are "customers" the day I get to install a cash register near the door to my office.
Is it true that some IT "professionals" are elitist? You bet. The fact that they are elitist isn't the problem. There are elitists in every walk of life, from the Vatican to the local Jiffy Lube. The problem is some IT manager hasn't done his job and fired the hell out of the "elite."
IT staff doesn't exist just "to make it easier". Computing long ago transcended the simple role of reducing labor costs. Computing is the single most important method of communication in the business world. Modern business is not possible without modern computing.
Screwed up people (IT and otherwise) using screwed up software for screwed up reasons, all under the auspicious of screwed up management. Some people think all this screwing up can be fixed if we just straighten out the relationship definitions; make sure IT knows that everyone else is the "customer." It cannot. Making systems work well requires talent, hard work and investment. This is required of all parties involved; IT and otherwise.
Here's a bit of common junk science from the article:
In a study of 8,000 tech projects in businesses, only 16 percent of the new systems were deemed successes
What, exactly, is a "tech project"? Define "new systems". What criteria is applied to conclude whether things may be "deem successes" and by whom? I could pick this apart in my sleep. Suffice it to say, that statement is ambiguous to the point of being worse than meaningless. It is laughable. Anyone naive enough to quote such a thing in their own material is equally laughable.
Whatever the case may be, I'll take it on faith that up to as much as 16% of "tech" projects can, in fact, be "deem successes". What I know for certain is that every one of those successes were created by hard work, talent and mutual respect among IT and non-IT contributors, not because some CTO publishes a memo about how the word "user" is offensive and will no longer be tolerated.
Maw! Fire up the karma burner!
Steven Covey wrote a book a couple/few years ago titled "The Inmates are Running the Asylum". In it, he makes a compelling case the modern software development is divided into four areas:
1. Management, which sets requirements and determines resources.
2. Developers, who, uh, develop the code.
3. QA
4. Support.
His premise is that what is lacking is a fifth group whose purpose is to design the usuability features. In my software development group, we've got all four of the above mentioned groups and what we end up with is a powerful, feature rich, stable tool that is the devil to learn. The developers do their best to design UIs that are intuitive, but what's intuitive to us is often backwards to our end users.
Covey states that developers fear ceding control over their work. It is this fear that was the basis for the resistance of the initial creation of QA departments. Apprarently, back when dirt was new, developers tested their own code and resented QA encroaching on their turf. It took a bit, but now QA is more or less entrenched and developers rely quite heavily on QA (I know I do). Covey argues that the UI design work that is currently left to these same developers should similarly be farmed out to teams of UI designers. Granted, it just so happens that he happens to run one, but I still think his point is valid.
Developers have no place designing how a user inteacts with the back end processes. Asking us to do so, or, more likely, not asking anyone to do so results in software that is a PITA to learn.
I remember when I first started to use a WIMP system (Acorn Archimedes). I had not the slightest clue what I was doing.
Since then, I have found that what I have learned is not just how to do things, but 50% of it is how to deal with unexpected/confusing circumstances.
I think sometimes thats the real reason I can use one - I'm not scared out of my wits about what is going on. I know it, its my environment, and I understand the (in)significance of various popups/error messages, actions, etc.
I suppose I really went on a steep learning curve because the software wasn't aimed at any specific user type; rather, it is aimed at everyone, specifically those with prior experience.
But there seems to be less Training given in the basics of operating a computer (filing, security, etc), than there are in using a computer to perform a small set of tasks (MS Office XP course, anyone?).
I have also noticed that once new user has worked out only what they want to do (not what they *can do), they will in general stick to that small range of skills but not branch out any further - wether that be through fear or laziness. A lot of the training for applications is quite mollycoddling in that way - the trainers know the users limitations - and they just want to show them how to use "mail merge" and get out of there, rather than increase the user's confidence in using a computer, overall.
*That*, ultimately, is why it is so hard for people to use new Software. Most of the time, it's not the software - it's that the users are pissed off that they have to relearn everything, for the same tasks they could do before. (as I said, its a heck of a lot easier with prior experience of a variety of other apps)
Of course manufacturers could remedy this by having every tool look and operate the same way (albeit near impossibly), but in the long run it would make more sense to teach people how to explore and deal with their overall environment. Its only natural that this ability and confidence spreads into the other areas.
<B>note to self:</B> <I>post as html</I>