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."
HCI - Human Computer Interaction.
It is a new major at such schools as CMU, Georgia Tech (the program I am in), UMich and a couple others. It addresses just this fact, that software is simply not made usable. Maybe it will be the up and coming craze, to "make software so that our mothers can use it"... or at least those of us in the major hope so.
Nick Burns your companies computer guy.
I'd so go off on you now if you didn't offer such a wonderful service :)
Ignore the "p2p is theft" trolls, they're just uninformed
At least in part, because they make more money each time they re-invent the wheel, and what's in their best interest is not in the users best interest.
With free software, it is just as difficult and technical - but long term standards are allowed to emerge and be built on, learnt slow or fast, used all or just some. You can form an education and a culture arround them, you can build learning, sharing, and application into that culture so that it becomes more and more second hand as society moves onto other things, and as those who really want to can specialize and grow as fast as their able to without artifical or closed limits.
The acceptance of closed software as normal commercial behavior has caused a lot of collateral damage, and I think this is one of the symptoms.
The basic argument of the article is that due to "techies" being analytical and "users" being intuitive that the techie is not anticipating what the user needs. Maybe this seems to be the case from the perspective of the perplexed user, but it quite simply is not so. How many young children are near experts with their family computers while their parents haven't a clue. The fact of the matter is that most computer technology, including most software, is quite intuitive. Otherwise children would not have such an easy time picking it up without any training. The problem lies in how the "users" have trained themselves. As we grow up, the technology of the time is introduced to us and we implicitly trust it, and learn to understand it. But most people do not do the same thing with technology that develops as we grow older. How many of us have grandparents that can not set the clock on a VCR? The users just need to learn to trust the technology and learn how to interface with it. They are probably never going to understand the underlying technology, and noone should expect them to. Just as I am never going to get into the particulars of in depth news reporting (which this guy sure seems good at), but I obviously can interface with it, ie. read the article.
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
That SNL skit resonated because it's true. Hey, they don't call 'em "geeks" for nothing -- many technical people *are* socially retarded.
I too see a lot of this on Slashdot -- a lot of one-dimensional thinking, and serious immaturity.
"Why doesn't he just leave it on and use a screen blanker like everyone I know."
I turn my computer off when I leave in the evening (say 6 PM), and then back on again when I come back in the morning (8 AM). Why should my computer sit there, eagerly awaiting a keypress that won't come for 14 fscking hours, drawing power all the while? Why should the monitor (even an Energy Star [tm]) draw power all that time? Multiply it by several hundred computers at my workplace, times some 300 days per year, and it can make a difference. Especially in California, where we have had problems with prices set by unregulated utilities. Note also that a power failure during the middle of the night won't affect a machine that's turned off already.
Correction: "The Inmates are Running the Asylum" was written by Alan Cooper. Another review here [uidesign.net].
I'd mod you up and the parent post down. Really, I'd love to rant a little more, but you've pretty much said everything I wanted to say.
It's funny -- most of the replies in this topic basically prove what the article said -- that IT people have poor people skills and can't understand that different people think and work in different ways. Most of the replies are people pissing and moaning that users are stupid.
Amen. IT people are amongst the most arrogant and, paradoxically, insecure people in the world. When users are faced with increasingly complex systems and the only support to which they are pointed is a conceited jerk who can't understand why they don't get it and isn't shy about saying so, is it any wonder that IT departments are being disbanded in droves and the work is being outsourced? Generally speaking, the consultants who get paid more can work as a consultant at least in part because they -- shock, horror -- understand how to relate to people in a positive manner.
And part of relating to people in a positive manner -- bigger shock, horror -- means making software easier to use and ultimately more useful and productive for the end-user at which it is aimed. The people who fail to realize this are the same people who will also fail to understand that they're being laid off because the rest of the company is tired of dealing with prima donna brats.
But there's nothing about the previous Mac OS that inhibited applications from having the problems described in the article. One only need look at a few of them to see it in action. Certainly AppleWorks/ClarisWorks changed significantly with each release. Such common apps as PageMaker would change. In many cases the changes were reasonable or necessary, I'm sure. I'm not taking a blanket line against change. It's computing after all-- a rapidly changing field which scarcely existed 50 years ago. My main point was that Apple was hardly immune from this. One only need look at the constantly changing default browser situation for a good example of this.
I do not have a signature
Believe it or not, everything you just said, except for the "load of..." part is covered and descriped by personality type theory. Over time, the normal progression of a personality is to learn to mimic, or actually develop, the skills of the opposite types. So, with age and experience techies start to understand feelies and vice versa. But it isn't ever perfect. It only gets better with age and experience. And not all people ever get past their original orientation. No matter how well I can act like a extrovert, and I do a good job of it, I still find it tiring and need time alone to recover from over exposure to people. I, of course, am and introvert.
In our current techie world, one in which you are considered to be over the hill at 35, the majority of technies never really have a chance to develop the skills demanded by the majority feelies. By the time you have a chance to develop the skills, you're having to learn to work as a fry cook.
A study I read recently measured the MBTIs of a large number of engineers in all fields. Then cross compared their yearly evaluations to their MBTI scores. They found a better than 90% correlation beteen an engineer being rated excellent, and having an MBTI of INTJ. INTJs make up roughly 1% of the population. Most people will go their entire lives without ever meeting one. And when they do they will find the person to be very odd. And yet, they are the population of top engineers in all fields.
The greatness of humanity is not in our sameness, but in our variety. It is through recognizing and appreciating the differences that we gain. But, if we don't recognize the differences we can't embrace them. If we belittle people for being different, we can never embrace the differences. The first step is admitting that the differences exist. The second is learning to value and respect the differences.
I have found MBTI to be a very valuable tool in dealing with people. Once I understood that the other preferences existed and what they meant, I found I could deal with people more effectively and understand where they were coming from. I'm an INTP, one of my dearest friends is an ESFJ. Before I learned to understand the differences and the value of the different preferences I would have considered her to be odd and annoying. Now, I have some understanding of her point of view and can communicate with her easily. And it works the other way too, now she understands what it means when I don't say anything, or just ask questions.
Pretending that everyone is the same, is as bad as belittling people for being different.
Stonewolf
(BTW, I do not consider the people who work in ad agencies or web design shops by and large to be UI designers. Usually these people are graphic designers who have no background in software usability, but instead delight in creating pretty image buttons, rollover links and the like. Having one or more of these folks on the team has no correlation to producing usuable products.)
How can we improve our UIs if we can't afford to hire UI designers on the project team?
- Educate the analysts, architects, developers and QAers on design for usability. There are two resources, classics in the field, that make great starting points. Although neither directly addresses software development, both books present a theory and logic system that can be readily applied to UI design. The first is Donald Norman's book The Design of Everyday Things, which mostly addresses designing products that are manipulated with controls (of one kind or another). The second book is Edward Tufte's The Visual Display of Quantitative Information, which covers designing information displays for maximum clarity. Tufte also gives seminars around the country where he gives an intro to his philosophy of design.
- Establish UI standards in a document that can be referenced by your developers when creating interfaces. There are references by Apple and Microsoft which are good starting points, but your UI manual should cover material specific to the domain your team is working in. For instance, if you're a securities firm, you should standardize on how you represent security names, prices, and labeling of market data points (e.g., "52Hi" vs. "AH" vs. "YrHi", etc.).
Many development projects also neglect to spend sufficient time observing how the target users do their work. Even though there are lots of users whose work requires too much keyboard dexterity and accuracy to use a mouse, developers don't often account for keyboard shortcuts, hot keys, etc. I've seen a trader pick up a monitor and throw it because he couldn't use the program running on his computer fast enough to do his job. Not a good way to discover a hole in your requirements process.