An Elephant in the Room

The whole reason we make software is so someone can use it.Yet just who these users are–their needs, skills and goals–is so hard to determine that they are often simply ignored INTERACTION DESIGN helps you stop treating your customers like AN ELEPHANT IN THE ROOM.

"I think we need to spend more time than we originally planned on the configuration user interface for this new feature I'm coding. The configuration is more complex than the rest of the application's configuration, and it takes a long time for the user to complete all the settings," Sylaja tells me.

Sylaja's new to working with this product, and this will be one of the first new features she's designed and built herself. It's important to her that the quality of the features is high. Having said that, I know the customer is paying a pretty steep hourly rate for her time, so the sky isn't the limit when it comes to spending that time.

Info to Go

• Start by describing users and their goals.
• Determine whom you most need to satisfy.
• Make design decisions based on these insights.

"What's this feature for again?" I ask.

"It's an optional plug-in for a feature some of our customers have requested. Our biggest customer is helping with the development cost to add it."

"If it's the configuration you're concerned about, remind me who will configure this feature."

"The application’s administrator."

"What do you know about the person in that role? How skilled do you think this person is?" I ask. I know who the guy is for our primary customer, and he's pretty sharp. But I'm curious to see if Sylaja knows.

Sylaja does know and announces, "Rob at our customer's site is doing that job now. He knows the domain better than anyone, and he's pretty good with a computer. He knows the application very well, almost better than I do."

Sylaja knows the skill level of the user. What about frequency? "How often do you think he’ll go to the configuration screen you're designing?"

"Well, just once when the feature is initially set up. Maybe again in a few months if he wants to change it to work differently."

OK ... she knows the task’s frequency, let's get some idea of risk. "What if Rob configures it wrong? What would happen?"

"Well, the application would generate incorrect information. Then he'd have to change the configuration. It wouldn't damage anything. He'd just have to go back to the configuration screen, reconfigure, and then regenerate the information. That might take him a few minutes."

"So, given that this feature is for the application's most skilled user, this configuration task is performed infrequently, and the risk for doing it wrong is low, how much extra time do you think you should spend making the configuration screen more friendly?"

"Hmm ... not much," Sylaja admits. Of course, we'd never intentionally forget the users working with our software, but sometimes we get a little disconnected from them. Sometimes we attribute skills to them that they don't have or forget those skills they do have. Sometimes we forget how frequently a task in our software is performed and the value or risks associated with that task. Keeping those people front and center during the design, development, and testing of software is the primary goal of a class of techniques referred to as interaction design . The dialogue above, which took place recently between a co-worker and me, is an example of how to practice interaction design in real time.

In In The Inmates Are Running the AsylumIn , Alan Cooper