"I don't understand the problem here. The interface is intuitive, it makes perfect sense! So why do they want to keep the old one?"

A coworker said this to me during one of the lunch-and-learns I present every couple of months at my job. What he unwittingly did was reveal one of the core challenges with taking smart people and tasking them with solving someone else's problem: people tend to assume everyone thinks and behaves like they do.

The situation goes like this: One of our teams (including both this coworker and I) redesigned a core web application to be more user-friendly. It took a single page which had about seven different searches on it, each with a different purpose, and reduced and combined a few of them into a single text box. This text box did both a location-based search (e.g. the nearest locations to an address, or zip code, or city) and an ID-based search (which would bring up details about one of our service locations based on searching its ID number).

The developers and technical designers (including myself) loved this search. It reduced the amount of code and visual real estate the search required, it fit the minimalistic ethos the designers wanted, and most of all, it worked perfectly. Even better, many of the users we tested it on loved it! So, of course, the development team was positive that the search would get approved with flying colors.

It didn't happen that way. Sure, many of our users liked the search, even praised it. But just as many users hated it. One user in particular, a high-ranking executive, loathed it. So much so that s/he asked us, told us, to restore the old seven-piece interface that s/he was so used to.

My coworker didn't understand this decision. The single-box interface was concise, extendable, functional. Everything a programmer could want. So why couldn't this lousy executive (and several other users) understand and appreciate the elegance and simplicity of what we worked so hard on, and just learn how to use it?!

The problem was that it changed too much. We took away their security-blanket familiar search interface, and replaced it with a cold, short, uninviting text box. We were trying to force them to learn a new system. But what happens when you try to force someone to do something? They tend to rebel.

To be perfectly frank, users don't want to think. They don't want to learn new ways of doing things. They couldn't care less about readable, modular, perfectly-designed software; they just want to do their job. Preferably by using an application that's intuitive and familiar so they don't have to re-learn how to do the things they need to do every day.

But the "don't make me think" attitude doesn't jive with being a programmer at all. Our entire field is based upon learning. The technology changes so fast that if we don't learn, we die (or at least our careers do). So we implement new features, and new interfaces, so that we can move the entire web programming industry forward inch-by-inch, and this has to include helping the users learn new and scary interfaces.

But then, how are we supposed to help them confront this new and scary interface if they rebel at the slightest sign of change? One option, one that seems to have worked in this case, was to be compromising and a little subversive.

The compromise was that we offered to keep both the old and new interfaces. The subversive part was that we made the new interface the default, and the old interface an option the user has to click on. So far, both the users and executives like this solution (at least after we enabled the old interface to be the default for certain persons who designated it so).

Programmers tend to be a confident, even arrogant, bunch, and God knows I'm not exempt from that categorization. But this standard of thinking is a trap. We can't assume that the users, who are by-and-large not technically-minded people, will think and behave the same way a technologically-proficient person would. We cannot assume that anything is obvious to a user. We must try to look at our programs through new eyes, through the eyes of a non-programmer, and say, "how can I make this more intuitive and more easy to use?"

Don't fall into the trap of assuming your users will think and behave the same way you do! You are not your users!