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."

Comments

This is because of closed software

[argoff]

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.

Customer is the problem.

[RobinH]

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 agree!

[aquarian]

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.

Man, I wish I had mod points today

[kiwimate]

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.

Re:The inmates are running the asylum

[LR_none]

I am not familiar with that particular Covey book, but I agree wholeheartedly with the premise. The UI designer is considered a luxury on almost any development team except the largest or best-funded. Without a UI designer, the job of interface design usually goes to the developers themselves, and without specific direction or guidelines, they have a propensity to produce random and arbitrary interfaces that often are just thought through enough to show the code behind them works. Sometimes the client sees the results in beta, freaks out, and starts giving UI direction to QA, which makes matters much, much worse.

(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?

1. 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.
2. 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.