paulchinonline.com

Human-Centered Intranet Design

By Paul Chin

Originally published in Intranet Journal (28-Nov-2005)

back back to portfolio


Have you ever tried discussing Tolstoy with a vacuum cleaner? This is precisely how many users feel when trying to interact with their systems in a technologically driven work environment. And I do mean interact. Although the word is usually associated with social activity, interacting with technology is exactly what we're doing every time we sit in front of our computers.

There's an unfortunate disconnect between how humans naturally function and what a lot of technology delivers. Technology needs to function as an extension of our own abilities, but users are often left scratching their heads or pounding their keyboards in frustration. It's ironic that while intranets aim to bring workers together in collaborative effort they can also alienate individual users who struggle to decipher poorly developed or overly complicated systems. This makes about a much sense as creating more bureaucracy to eliminate red tape.

The human-computer relationship can be an uneasy one. But it doesn't, and shouldn't, have to be that way. Just as physical ergonomics is important to the health of the body, cognitive ergonomics is important to the health of the mind. Developers need to have a deeper understanding that regardless of what technology allows them to do, the end product must conform to the natural way in which humans work.


Human-System Disconnect

Users have always tried to reconcile the way in which they naturally work with how technology makes them work (or in some cases changes the way they work). For those not in a technology-driven field, or not used to working with computers beyond a word processor, this is not an easy task—especially when software is getting bigger; more elaborate; and consequently, more complicated.

We've all heard the same buzzwords associated with software—intuitive, user-friendly, easy-to-learn, ready out-of-the-box—but more often than not, users are in conflict, rather than in concert, with their systems. Simplicity is touted as a major selling point to convince users that what they're about to install or use isn't threatening. But user manuals end up longer than the code itself, system interfaces make users cross-eyed, and figuring out how to perform a task requires more effort than the task itself. This makes users feel as though they have to run a mile to gain an inch; and the payoff of technology, in the long run, isn't always apparent to those outside of IT.

This disparity in the human-computer relationship can be fueled by the manner in which software is developed. Too often solutions are created with technology as the primary focus, when it should be the users. This notion of human-centered design isn't a new one, but it's one that hasn't received the attention it should from developers.

The vast discipline of human-computer interaction (HCI) is dedicated to improving the relationship between human users and computer tools. The Association for Computing Machinery's (ACM) Special Interest Group on Computer-Human Interaction (SIGCHI) defines HCI as "...a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them." HCI practitioners include professionals from various fields including engineers, designers, psychologists, and social scientists.

Human-Computer Interaction Resources

Understanding the Causes of Human-Computer Disconnect

There's really no single overriding cause for this human-computer disconnect, and it varies from individual user to user. The list of human factors affecting interaction with technology is a long one. It can be the result of poorly written software, human limitations and behaviors, personal intuition, user habits, prior experience, cultural biases, and environmental conditions.

Effective use of technology, like most other skills, must be learned. No one can use a brand new system with efficiency from the outset regardless of how user-friendly it claims to be, or how much skill the user has. The opinion users get during this stage will form the basis for their future interaction with the system—a sort of technological first impressions. They will either connect with it after some basic training and independent experimentation, or they will find the system too difficult to use (or learn to use) effectively and eschew the technology for simpler manual methods.

It's the intranet developers' responsibility to make this connection with users. But it's easy for them to get carried away when developing new systems with new technology because of the initial WOW-factor. Soon they start adding in bells-and-whistle just because they can, and the central focus of development slips to technology and experimenting with what it can do. Developers can't connect with users through their own excitement with technology. Users don't care what it can do, they just want to do.

Marketing—whether by commercial software makers to the public or by in-house developer's to management—can also indirectly influence the human-computer relationship by affecting the end-result of a system. Users crave simplicity, but marketing can cause software to become bloated with unnecessary features in order to create the impression of a "fully loaded" solution. It's also done to mark up commercial software's retail price, or to inflate the system's value (real or imagined) to management to justify development expenses.

These superfluous features, however, are often added at the expense of usability and user comprehension. Software becomes so complicated that users no longer see these tools as answers to their problems, but rather as more questions heaped on top of an already laden pile. There's no progress in forcing users to swim upstream. It will only lead to exhaustion, stress, and a loss in productivity (More on this can be found in my past articles "The Problem with Jack-Of-All-Trades Intranets" and "Beware the Bleeding Edge and Feature Creep.")

Nothing will drive a wedge between user and tool more than poorly developed or overly complicated systems. Not only do intranet owners—and to a greater extent, employers—have to worry about initial system adoption, but there's also a danger to users' personal skill sets if they actually do accept an inefficient system: Negative habituation. Getting accustomed to using poorly written software can change the way in which users work for the worse and cause them to adopt bad habits.


Tips on Making the Connection

Intranet owners and developers don't necessarily need to immerse themselves in the field of HCI. There are many basic design principles that any intranet developer can apply to make technology more human-friendly. Being conscious of fundamental human behaviors and their users' specific needs will go a long way towards promoting positive user experience:


Closing Thoughts

Developers are coming up with all sorts of ways to try "humanizing" IT systems, to make it seem more like users are "conversing" with people rather than through a keyboard. Effective human-computer interaction is part science and part art. "Natural" and "intuitive" are highly subjective terms. Every user will have a different experience with, or tolerance toward, technology.

Technically inclined users who are already accustomed to interacting with technology might find it as natural as turning on a light switch. Users who are more accustomed to dealing with people on a face-to-face basis might find it awkward if, for example, they were suddenly put in front of a WebEx session and told to chair a meeting with other WebEx users scattered across the globe.

The role of the developer is to ensure that their systems don't put undue stress on users simply for the sake of technology. Developing for technology alone helps no one. It may showcase the advances in the industry and impress those in-the-know; but after the oohing and aahing stop, it does little to ease the disconnect between the user and the tool.


Copyright © 2005 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.