Happy users

It’s impossible to please everyone. As a developer, it’s my job to please as many of my users as I can. This means creating web apps that are pleasing to look at, easy to use by both newbies and power-users, and easy to figure out for first-time visitors.

This is an impossibility, a chasing after the wind. It’s easier to play pool with a rope.

I maintain both our public web site and our rather inclusive Intranet, both of which I created from scratch. Public web sites tend to follow a set of fairly straightforward and standardized rules of usability and seldom get much contention from those involved in the design process. I’m more or less allowed to design according to my professional judgment.

Our Intranet is another ball game entirely.

The company I work for is a scientific consultancy and other than two other admin personnel like me, our entire staff is made up of scientists and technicians. They have a very diverse view of what’s good and what isn’t, and trying to please all of them on Intranet projects has been my biggest challenge.

Right now I’m working on adding an expense reporting system to the timesheet section of our Intranet. Employees will enter expenses they incur, including miles driven using a personal or company vehicle, purchases made with a company credit card, reimbursable expenses, travel, and even vendor invoices for large equipment or software purchased to be paid with a company check.

My development process is to interview a representative sample of key users and write down all the functionality needed and requested. I group everything into three categories: must have, need to have, and like to have. The ‘must have’ group is functionality that has to exist right out of the gate, version 1.0. The ‘need to have’ is functionality that will be built but doesn’t necessarily have to exist in the first release. The ‘like to have’ group is exactly that: something that is requested but not required, sort of “We’ll implement it if we can.”

Once that’s done, I create a clickable HTML prototype to let people see and touch the design. Several key users check it out and provide feedback about what works for them and what doesn’t. Feedback tends to fall within three types: Love it, hate it, or doesn’t care. How do I reconcile these disparate opinions about the system I’m building?

I can weigh the feedback based on where the responder exists in the corporate food chain. If a senior scientist likes something but a part-time seasonal technician hates it, who do you think will win out? What if two seniors have completely different opinions about the same functionality or design?

Although I create the designs based on my own experience and personal preferences, I try to leave my own likes and dislikes out of the equation, at least when it comes to aesthetics. When in doubt, I defer to the rules of usability and design. You’d be surprised how many people I’ve met that think hot pink text on a black background is beautiful. I have to rely on that experience and knowledge when settling disputes between users on aesthetic or usability issues as well.

If I have differing opinions about a design, and those opinions are more or less weighted the same, I’ll rely on usability standards to resolve the conflict and choose a design. Sometimes users don’t necessarily know what’s good for them. It sounds cold and almost arrogant, but people have a remarkable ability to forget they dislike something and simply get used to it. There are times, however, when I create a design or development functionality that violates my own judgment of what is ‘good’ for the sake of making the users happy. This sometimes works out okay, where a web site violates several rules of design or functionality but the users are happy with it so who cares in the end? That’s rare, however. Most often, when established rules are violated, things have to get redesigned after a while and we usually end up moving back toward the tried-and-true — where we [arguably] should have been in the first place.

In my position, at least on paper anyway, I have the final say when it comes to web development at my company. However, it’s rarely a good idea to pull rank if enough users don’t like what it would produce. Ultimately, happy users is what matters most.