Features Suck

Tuesday 28 February 2006 - Filed under Internet + Software

There, I said it. You don’t like that? How about this then: Simplicity rules.

One golden rule in software development is that there will be at least one fight about features. Why? Because of all the things you can control, time is the one thing that just keeps marching on. Throwing more hackers at a problem doesn’t always speed it up, and in reality, you are always making do with the resources you have.

And like all limited resources, they get fought over. Should we add another “wizard”, or focus on making the UI more clean? Should we be drawing more cool pictures, or getting the database to be more scalable? All ideas start with good intention, but again, resources are limited.

So, the question is, how do you focus your efforts? The answer? Let the users decide.

Simply put, roll out your main feature set and make sure it works well. Let people use it, hack it, and generally abuse it. Make a comment box or a feature request box and just sit back and kill bugs for a while.

Eventually, you will get a thousand requests for Feature X. Likely, that feature will be just some simple twist on what already exists, and the request will be something like, “It’s hard to do this [common thing] on your site. Right now it takes ten clicks. Can you make it easier?”

Oh sure you can. A few keystrokes later and blammo! Instant 1,000 satisfied users. They get the feature and they love you for listening. Like stealing candy from a baby.

Other requests will be more out of left field. But if a thousand folks want it, likely it’s something cool that you weren’t smart enough to figure out in the first place. Do it, and again, a thousand happy customers. No need to think ahead too far. Be agile.

Let’s take a look at the darling of the new internet era, Google, for a more concrete example. In particular, let’s focus on Google Maps.

When they rolled it out, it was just that — maps. They were instantly recognizable because of their unique, clean graphics, and the simplicity of entering addresses. No more tabbing between street, city, state fields, and no awful pulldown menus.

But where it really differed was in the experience. One of the first huge AJAX-y applications out there, the community was stunned with the smooth scrolling maps, the keyboard shortcuts, and the seamless zooming and flagging of locations. It was just plain cool. They clearly focused on the experience.

Was it better mapping technology than already existed? Not at all. Did it give you better directions? Actually, it consistently gives me bad directions (to this day), when compared to MapQuest. Is it my main mapping solution? Of course. It just works better from an experience standpoint.

Now, there weren’t a whole lot of features at the time. Sure, there was probably the point-to-point driving directions and other things, but from the main interface, it was just a mapping solution. And it was beautiful and easy to use. Big feature done? Check.

Then what happened? People hacked the piss out of it. Google did not initially release an API to their engine (which most of their competitors had, like Y! and MapQuest). But that didn’t stop people from making hacks and mash ups like they were going out of style.

So what did they do? They sat back, waited, and watched. People came up with all sorts of cool ideas that proved to Google that an API would be widely used, and they made it pretty clear which API elements needed to be exposed. Google releases a sanctioned API that duplicates the functionality already present in the hacks and everyone is happy.

Did anyone get thanked for the design effort? Nope. And you felt good about Google for responding to your needs. Candy. Baby.

Then, over time, Google rolls out cool new features (and some long-awaited ones). Satellite view. Hybrid view. A scale bar. With every new feature, the blog world wrote it up and ooh-ed and aahh-ed. The cynical wrote about how these features existed in their competitors since day one. The rest of the world just lapped it up.

So the lesson learned? Build only what you need to get your product functional and out the door. Focus on the experience, not the feature set. Never assume a feature is useful unless you have the data to back it up.

Be agile. React to your users. They will reward you for it.

2006-02-28  »  mark