user-absent design

[jrtom]

The NY Times reports on a rocky adoption process for the San Jose PD's new Windows-based computer system. It seems they forgot to ask any of the cops to provide feedback on the design before they delivered the system.

I feel that San Jose has a lot less excuse for this sort of problem than most cities: I mean, it's in Silicon Valley. You can't hardly throw a brick without hitting six software engineers, at least a couple of which have had some experience in interface design.

Are we still graduating software engineers that don't recognize the importance of user testing, or is this a management problem? I've had several conversations with my dad about problems like this: he's a doctor at the University of Arizona hospital, and it seems no one asked his colleagues about the design of their new software system either.

These are critical services, folks. (For that matter, it's your money.) Do you really want the doctors that are looking after your kids (Dad's a pediatrician) to make mistakes because your software sucks? (Maybe you don't care, if Dad's in Tucson and you're in Atlanta.)

For companies that charge extra for post-installation consulting, the motivation for poor design seems obvious: if you do it right the first time, you won't be able to charge $150/hour for a consultant to come out and fix it for you. But I assume that all companies can't be working like that, so it's hard for me to see why this problem would continue to persist.

*sigh*

Comments

[red-frog.livejournal.com]

Dad and I talked a lot about this while I was in AZ. It's the usual problem: because the app sucks (and it sounds like it does), no one will use it because it's worse than useless. Since the app is running on a MetaFrame server, the problem is suddenly "Citrix".

[lightning-rose.livejournal.com]

Never blame the engineer for a poor user interface, unless it's vi. :)

Seriously, most ui's are decreed from the sales/marketing dept, with little or no input from the coders.

[jrtom.livejournal.com]

Had I spent less time working with (and teaching!) software engineers to whom the concept of user testing was completely foreign, I'd be less inclined to consider it possible that it was the engineers' fault. :P :) As for where the UI gets decreed...in my experience, it depends on the company, although you may be right in general.

[red-frog.livejournal.com]

Sometimes I wouldn't mind more time with such UIs. I have too much experience of developer-designed ones. :P

In the case of Dad's app, though, it's not just that the UI is bad, but that it has this annoying tendency to make it look as though it's saved changes without, y'know, actually having done so. This led to the abandonment of an expensive app and the task that it was supposed to be accomplishing. :P

[jrtom.livejournal.com]

I'd call that a UI problem of the first water, actually: the UI is leading you to believe that something is the case that, well, isn't. Arguably this is often worse than the more usual sort of UI bug that people talk about (i.e., overly complicated/obscure interfaces).

[red-frog.livejournal.com]

I distinguished because apparently the underlying code doesn't work. Not only does it appear to have done something it did not, but it's borked.

[jrtom.livejournal.com]

Oh. That's a UI problem in conjunction with an implementation bug. Best kind. (I know I prefer to design all *my* UIs so that I can't tell when the underlying code is buggy.)

I tell you, the fallout from the introduction of rapid UI prototyping as a Major Thing is going to be plaguing us for years to come. (I used to think that it was all Visual Basic's fault, but I think that the problem is more fundamental than that.)

Spoken like a true academic.

[fdmts.livejournal.com]

Now that I'm actually out in the world, trying to deliver software to people and offering consulting to those folks who need it after the fact, I have a certain amount of sympathy for the other side of the equation.

Additional ranting on request.

Re: Spoken like a true academic.

[jrtom.livejournal.com]

Um, I have worked for three years as a software engineer. Plus a summer doing software consulting. Plus I'm currently the lead developer for an open-source project on SourceForge (JUNG (http://jung.sourceforge.net)).

Nonetheless, I'd like to hear your additional ranting.

[gwyd.livejournal.com]

I think failing to ask the actual users what they want/need is industry standard. Every library worker I've ever met hates upgrades. This is not due to any kind of technophobia. (Librarians love computers, which have made library management so much better and more efficient as well as making information so much easier to find, things librarians love). No, they hate upgrades because no one ever consults them about what features they actually need/use regularly and what areas need improvement. Instead some random management type talks to the developers and all the short cuts and easy ways of doing things get replaced with much more onerous sequences and useful stuff occationally gets removed in favor of stuff they didn't want. It can take a year or more for a library to recover from the supposed improvements.

[red-frog.livejournal.com]

Believe me when I tell you that some of us are trying. It adds time/money and it can sometimes be difficult to get busy end users to participate in the queries, but this is what I want.

[gwyd.livejournal.com]

I've been involved in quite a number of these "upgrades," and I've never seen the end users asked in advance. They wait until the newest nightmare is installed and everything grinds to a halt due to bugs, weird security measures, or missing functions. Then the consultants arrive to ask the seriously pissed off library folk what they actually wanted. Library folk would make time if given the opportunity since upgrades are frequently disasterous. I suspect the mistake is assuming administrators have any clue about how things work on the ground.