This post is part of a series about Designing the Obvious, a book about common sense Web application design. Learn more about this series.
Users like features, or at least that’s what they tell us. Users can also be confused or turned off by options. It’s the paradox of choice.
Designing the Obvious says to build only what is absolutely necessary and lose the nice-to-have features. They’re extra cruft and not essential.
“Simplicity makes the point clear. It lets messages stand out. It offers communication that cuts through the noise.”
It’s easy to identify nice-to-have features by the way they’re introduced:
“You know what would be cool,” “here’s something we could do,” and “it wouldn’t be too hard to do this.”
How many of us have heard these in project meetings? Sure, innovation can also come from these statements, but leave it for the brainstorming sessions. Far too often these are used after the project is midway. Since the ideas often are cool, it’s easy to latch onto those features.
The book gives some guidance on how to find and fix an application filled with nice-to-haves.
Unnecessary Test
“The focus should not be on features, the focus should be on focus… Every feature should support the single activity the application is designed to support.”
Limiting feature creep means for each new feature we question whether the feature is necessary. We’re often biased and can’t be objective. The book recommends answering these questions (or, if you’re brave, have someone else answer them):
- What is the activity my application is meant to support?
- What would an application that performs this core activity look like?
- How long would it take to rebuild my application to do that?
The author is half joking with the last item, though I think it’s a worthwhile thing to consider. Try to forget the baggage of previous versions (or how someone else’s application does something similar) and invision the basic functionality of what you’re building.
But beware actually tearing down walls:
“I’m not suggesting you start ripping functionality out of an existing application. Doing this could have the rather negative side effect of making some of your users extremely upset.. I’m only suggesting you learn from hat you’ve already done so you can create more focused applications in the future.”
Three Rs
Designing the Obvious provides three focal points to help you avoid nice-to-have features.
- Requirements – Always be aware of what is necessary for your project
- Reduction – Like the Laws of Simplicity state, remove those unnecessary features.
- Regularity – Make sure everything seems like it belongs. Strive for consistency.
These are a few ways of avoiding those nice-to-have features, which may be cool, but are also unnecessary. What phrases like “that would be nice to have” get your blood boiling? How do you handle what Designing the Obvious also calls “featuritis?”
Answer below in the comments. At the end of this series, I’ll randomly select three commenters and send each an autographed copy of Designing the Obvious.
This is one really nice thing about Extreme Programming. User stories make sure that at any time, you’re working on something that the customer actually wants. Of course, it’s still easy to get off-task when you’re following the user stories, and so pair programming provides a handy sanity-check. At any time a pair can say, “yes, that’s cool, but does it help us achieve the goal on this card?”