Solving Problems Addressed By Your End Users

Anyone who’s been involved in web development for any length of time has likely encountered the Developers VS Users situation. It’s a mistake that can often lead to expensive problems down the road. So what exactly is the problem? And how can you spot it–and solve it–before it derails you project and causes you to make a costly mistake? Here’s how…

Most developers became developers because they want to work on and build cool stuff. Like everyone, they want to build things that gain the respect of their peers. This aspiration is where the problems get started. Unless you happen to develop for an extremely technical audience, users don’t want cool stuff. They just want stuff that works and makes their life easier. For example, let’s say a developer wants to build a weather dashboard with real time satellite video feeds, an AJAX module that show the latest temperature, barometric pressure and wind speed/direction, the sunrise/sunset times, and tidal data. A regular user, on the other hand, just wants to know “is it going to be sunny or cloudy and do I need a jacket or umbrella today?”

We’ve seen several examples of this played out in public in our little tech-bubble-blogosphere in the past year:

• Google Wave: Google wave is cool. It doesn’t solve any problems that any real people have but it does a lot of great things that developers get excited about. It includes embedded video, sound, and chat from multiple users that a user can enable playback from… Yeah, I was saying just last week how I wished I could do that. The only useful thing I’ve ever seen done with Google wave is the Pulp Fiction movie (1000% NSFW).
• iPad: When the IPad first came out, I (like many others) complained that it was an oversized iphone with less functionality. However what we missed was that it really wasn’t for us. The iPad is for regular users, not developers or techno weenies. In other words, people–in fact, most people– want an internet appliance that just works. They don’t want to have to deal with nonsense like registries, print drivers, patches, updates, and so on. Why does everyone have a refrigerator in their house? Because it’s easy to to use! You plug it in and go. Imagine for a minute if you had to play with the evaporator driver or download and install a thermometer patch update every week. Your refrigerator “works” because 99% of the time it just does its job without any fiddling.
• Google Buzz: Google assumed that everyone wanted to share all of the stuff they are doing, reading, and looking at with people they talk to. Because many Googlers have become victims of their own hubris, they assumed everyone is like them, wants to be like them, or should be like them. However when the realities of everyday life entered the equation, in the shape of something like an abusive ex-husband, it was a condition that didn’t exist in the artificial utopia of the Googleplex. Google failed to test the program in the real world and instead relied on the developer’s vision of what the users wanted. The result? Failure.

So how do you recognize when you are in this situation? If you, your developer, or anyone on your team makes these kind of statements, chances are strong that you are on the wrong path:

• Can’t the users open their eyes and just read? The answer is right there in front of them.
• The users need to use a little common sense. We can’t keep dumbing down the world for them or we’ll end up like (insert tv/movie/pop culture reference for stupid people here).
• They use the term UX to mean user experience or UI to mean user interface in common everyday speech and would feel comfortable using it when speaking to the CEO or board of directors.

What can you do to prevent this kind of mistake from ruining your project? Here are some ideas:

• In most cases, developers don’t make good team/project leaders. They carry with them the bias of wanting to be cool, respected developers. If you have or can find a developer who has a proven track record of placing user needs above cool programming features, ignore this recommendation.
• User testing: find someone who is not involved in the project or, even better, get a NIF (non internet friend) to try out your website. Put them on the homepage and ask them to try and do what your primary goal is, whether that’s to create a gift registry, put something in a cart and checkout, find a specific piece of information, or something else. Whatever it is, ask them try and do it. If you can video tape them, that’s great; otherwise, watch without interacting and take notes.
• Test different options. Use services like Crazyegg or Google multi variant testing to try out different options. See where users are and aren’t clicking then make adjustments based on data not on intuition. (disclosure: Crazyegg is an advertiser here)
• Don’t make changes because they are cool, neat, interesting, or stroke the ego of your developers. Make changes that solve problems people have. This is one of the biggest complaints I have with Wordpress as a platform. They coddle developer’s whims instead of addressing real problems like security.

At the end of the day, you and everyone involved needs to understand that, for your project to succeed, it needs to solve a problem users have first and foremost. Stroking the ego of the CEO, making the marketing department look clever, or making a developer feel stimulated are not real goals.

Comments