The goal of software is to get out of the user’s way. Software, and technology in general, is designed for helping the user do their job, and do that without noticing the technology in the progress. Users don’t want to worry about configuring, setting up, or dealing with the overhead of a tool.

“Oh, I can change the color of the text to magenta and make the font Scary Halloween? Terrific!”

“You’re saying I can arrange all of the fields on the page in any order I like? I feel like I’m back in grade school playing hide and seek again. Thank you!”

“I have seven options for how I can message my friends? Lucky me!”

Developers get pumped about new features. They love the idea of solving a new problem in a new way. However, I then usually end up saying something along the lines of, “I know you like the idea of making this piece of software so generic that the user can configure it anyway she likes, so it can do anything she wants, but then she’ll pay for the opportunity to poison your food and kill you as slowly as you’re killing her with your software.” Developers are trained to generalize their code and make smaller gears that do more, but, this generalizing of code tends to make them generalize the users, or the user’s tasks, too much.

Since programmers live inside the code, they put most of their thought into the code, and all the stuff that falls outside of that (user interface and interaction) gets a cursory glance. It’s great that you can produce a report in half the lines of code, and with that same code produce ten more reports, but that’s not so great if the user only needed that one report. If a function that took the user two clicks, now takes them five just so they have the option of doing more things, then you’re not giving the user a win.

It’s not just about simplicity. It’s about getting out of the user’s way. Removing visual objects decreases the choices a user has to make. Those objects might not even do anything like displaying static text, which seems nothing like the choices a button offers, “Should I click this button and perform its action or not?” Visual objects, even ones that don’t require interaction, still require the user to make a decision, “Should I pay attention to this?” The more the user has to ask that question, the less impact your visual cues have. Ever wonder why the users keep missing that one feature or option that they keep asking you about? Important things need to be obvious, which means making them big, bold, and attention whores. However, this task is made that much tougher in a crowd of ten versus a crowd of two.

The more objects there are the harder it is making any single one stand out, especially at the specific crucial moment when user needs it. But that doesn’t mean that the software needs to get in the user’s way by jumping up and down and throwing around blinking fonts. If each piece is fighting for the user’s attention, then the user will mentally tone them down. This process costs the user mental processing power. As a developer, though, you’re job it maximizing user mental power by focusing them on those tasks that only they can do, and not on the things your technology does well. You’re reward is the user forgetting to thank you because they’re caught up on something else other than talking about your software. Users talking about software usually means users bitching about their problems with your software. Make them do that to your competition, not to you.

Let me close with two real examples. The first is a simple one, a web page for a rowing club for signing up members, posting new updates, announcing new tournaments, showing pictures, etc. In doing a redesign, many technical advancements were made. However, navigation went from a sidebar of about 4 sections with 4 sub links each, to a side bar of about 8 sections with 8 sub links each. And, not only were there more links (without any substantial new content), but the sub links had a really “cool” hiding feature that hide the extra links as the user clicked to open another section.

Nothing against hiding extraneous options or content (hiding options is getting out of the user’s way right?), but when one set of links was opened the other hide themselves, and if the user wanted to jump between two sub links, then they’d have to keep opening up the previous section. Not a huge task you’d think, but users are worried about the page they’re looking at, they don’t want to spend time remembering where you hid a sub link. That reduces mental processing power by diverting it into the software, and requiring the user to manage the software’s links instead of managing the task at hand. I would’ve preferred seeing (I wasn’t managing this project) 3 sections with 3 sub links that flowed the user through their tasks instead of leaving steps open to users.

Users want to do stuff, they want to accomplish tasks, not contemplate options. This is exemplified in this last situation. We’re redesigning our flagship application (the other project was a smaller consulting job, which we do from time to time for certain groups). It’s a full blown (web based) application with complex business logic dealing with budgets and financial decisions and such, lots of moving parts. We offer a base vanilla package, but we customize it for the user based on their business practices. There’s only so much you can generalize.

It’s a friendly relationship, we connect with our clients on a personal level and help them do their jobs better, faster, and easier. We see the relationships we build as a selling point when negotiating with new clients along with our ability to customize the software to their specific needs. Most of them come to us specifically because they want to kill their own IT, and we do what we can to make them love us.

However, from a managerial and technical point of view, the more flexible and customizable the software, the less time we spend developing client specific features and fitting it perfectly to each clients. Development time costs more than sales time for us, so in theory, it sounds awesome if we could create an application that we just hand over to the user, and let them configure it 10 different ways for every need, and we move on finding more clients. Everyone’s happy, right?

Except we aren’t hired to give the user options and ways to configure our software. We’re hired to make their processes disappear in the ease of using our software package. There’s this continual fight I have to put up with both management and developers to keep the software from going in this direction of ubiquitous hell. “You can do anything you want,” sounds great, but when we know those two thing they want to do, we need to make sure we do those damn well, and forget everything else.

The engineers say they’re trying to re-engineer the processes, they’re adding more power to the application. Other management thinks we’re saving developer time, cutting costs, and giving us more time to focus on new revenue. In the end, if we were to make the generic putty mold of our dreams, then we’d alienate and frustrate our current clients, and scare away future clients. New features are an easy sell, but bad experiences are turpentine splashed on happily painted walls. Experience is a hard sell, and customers understand the value of good smooth interaction with software they’ve never used less than your salesmen understand the code behind the shit they’re selling. But, it’s the glue the keeps people around and magically attracts more people as well.

Advertisements