I was having a Mexican shrimp dish the other day with some friends in Austin, Texas when a thought hit me…

[Question for next episode: The source of epiphanies is:

A.     Mexican shrimp dishes

B.     Spending time with friends

C.     Austin, Texas]

The thought was that there is a major methodological flaw in the way most companies (including NetworkStreaming at times) approach developing a software product.

Logic says that the means by which you create really great products is to focus on your customer’s needs and requests. This is why NetworkStreaming has made the conscious choice to stick to our IT roots and ignore other potential markets in order to make sure that we are meeting the needs of the remote support industry.

However, logic also says that the means by which you meet the needs of your customers is to meet the needs of your most demanding customer and let the other customers piggy-back on the demanding customer’s features. This is the age-old David and Goliath argument, tried and true through the ages. If David can beat Goliath, then the normal-sized Philistines had better run for their lives. If Michael Jordan wears Nikes, then surely they are good enough for a hack like me. If every new Dodge Viper rolls off the assembly line with an oil pan full of Mobil 1 pure synthetic, then surely it is good enough for my Toyota. If a Land Rover can handle all the stuff it does in the commercials, then surely it can handle taking the kids to soccer practice. If this is the jacket worn for Everest expeditions, then surely it will keep me dry on a day hike.

The argument seems good. You would think that the only potential problem would be that the product might be overkill for some applications, but at least the problem would still be dead.

However, often catering a product toward the needs of the power user actually reduces its effectiveness for the majority of users. Consider Microsoft Excel, for instance. I wonder if any single human has ever used all of the features of Excel. That person is not much of a conversationalist. The problem is that beyond a certain point, functionality is hard to scale in a way that still allows the average user to access the basics. Creating a simple product is immensely complex, even more complex than creating a complex product (Examples: iPod, Google).

In theory, one simply needs to segment which features the average user will use regularly and then add features for the power user in a separate layout or menu. In practice, the problem is that the way a power user works within the application is going to be far different from the way an average user works. These workflow differences make a huge difference in the way you build the application.

Consider Macromedia Flash, for instance. It is a phenomenal tool that I have had the chance to tinker with from both the drag and drop and the scripting layouts. The problem is that it is extraordinarily difficult to master upon initial use. The personal home page junior webmaster doesn’t care what the easing is on his motion tweened scrolling welcome text, but the interface suggests that he probably needs to. Maybe Flash can be excused since many of its users are pretty hardcore, but I have seen a lot of Flash on the web that was not produced by a professional, and I wonder how long it took them to figure out what they needed to do.

Maybe later, I will go into what I think is a really good methodology for creating applications that cater to the majority user and not the Kung Fu application warrior, but in the meantime, let me suggest two simple steps:

1. Assemble a sampling of possible product users
2. Weight the application’s features toward the group or groups within the sampling that represents the majority of the application’s users

The first step is nearly always done well, but the second is missed time and time again in favor of weighting the application’s features toward the power user.

Bookmark/Search this post with:
| | | | | | | |