Developers Can't Discount Human Nature

By Paul Chin

Originally published in Intranet Journal's Chin Music (16-Jul-2009)

back back to portfolio

Every system designer has at one time in his or her professional career had to play the role of developer, sales person, and psychologist. The developer writes the code for the system, the sales person tries to sell it to management and the user community, and the psychologist tries to figure out why users don't buy into what they're selling.

It's IT's responsibility to create technology-based tools that meet the needs of its organization—saving it time, effort, and money. These tools must be an extension of users' innate abilities to carry out their tasks and not some cryptic oddity that requires a 500-page manual to decipher. Although these ideals sound great on paper, in reality there's always going to be a segment of the user community that will resist IT's efforts regardless of how well the tool is developed.

Developers are then faced with the challenge of trying to reconcile the objective facts of a system with the subjective reactions of its potential users. A developer can say to a user, "You know that thing that normally takes you two hours to do? Well, now you can do the same thing and more in two minutes," and then proceed to list all the ways their new tool will increase productivity. Unfortunately, while the developer is making a case for the new tool, users are hearing, "Excuse me, I donít mean to interrupt your dinner, but what if I told you I can save you 10-percent on your long distance rates?"

Why do certain users resist new technology-based tools that, in theory, are supposed to improve every aspect of their jobs? Perhaps it has nothing to do with technology or objective logic. Perhaps itís human nature: Fear of the unknown, resistance to change, an inability or unwillingness to break a comfortable routine. Users might even resist out of spite—overtly or passive-aggressively—for what they perceive as developers forcing them to change how they're accustomed to working.

Let's face it, people are creatures of habit. I recall an incident early in my IT career where a mainframe programmer threatened to resign if his IBM dumb terminal was replaced with a PC. Despite having to walk to the far side of the building and wait in line at a PC kiosk (shared among everyone who didn't have a PC of their own), he was perfectly happy with this routine.

But we can't place the spotlight on users alone for a lack of system adoption. Developers have a part in this too. I've seen countless instances of developers and commercial software makers creating new technology-based tools that are far more complicated than they have to be. This happens because too many developers want to gratify their own technological curiosities and needs. They end up developing for the sake of technology, not for the sake of users. The result: Users are left to wrestle with a bleeding-edge tool that should never have left the R&D stage.

Greater focus needs to be placed on human-driven development as opposed to technology-driven development. It's the technology that has to accommodate the nuance and diversity of human nature, not the other way around. It's unfair to say, "This would be a perfect application if only we had a different set of users."

Ego- and technology-driven development helps no one other than those writing the code. Good applications are centered on the people who use them, not those who made them. Users are results oriented. They just want to get the job done—by whatever means. They don't care about the underlying technology that gets them from Point A to Point B. They just want to get to Point B in the shortest route possible. Their system could be powered by a giant man-eating loris for all they care. And if thatís the case, and the system delivers everything developers promised, users will be the first to call an annoying relative to "feed the system".

Copyright © 2009 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.