Making of a Web App: Choose a Small Feature List for V1.0

How to Choose Features

So far, we have:

• Identified the single activity (sales team collaboration) the application is designed to support.
• Described the users’ roles, responsibilities, and needs.
• Helped set expectations and focus
  by describing a related activity it will not support

Now we’ll build our version 1.0 feature list.

First, Include The Kitchen Sink

I’m a fan of brainstorming. All ideas in brainstorming sessions are captured. Assessment of ideas happens after the brainstorming sessions. This process brings about useful ideas because it keeps thoughts flowing. Instead of stopping a creative impulse because of a “bad” idea along the way, brainstorming sessions allow the best ideas to evolve.

Use the brainstorming approach for the first take at a feature list. Ask “what features would someone like to have in this type of software?” After a short while you will have easily captured pages full of nice-to-have features. Yet most will never see the light of code. At least not in the first version of the application.

Even though you will tuck it away somewhere, it is important to keep a record of the entire feature list in order to

• Boost creative thinking, and
• Provide a platform for the first step toward simplification: reduction.

Then, Reduce

Reduce
is John Maeda’s first law of simplicity.

”The simplest way to achieve simplicity is through thoughtful reduction.”, he says.

“Thoughtful” is the key word there. It’s easy to throw features off the list. It is difficult to thoughtfully determine what to through off the list. Determining what to reduce is as much art as science. This is where domain experience becomes valuable. This is another reason to build what you know or to “scratch your own itch”.

It’s probably a misnomer to entitle this article “How to Decide What Features to Include”. Every situation is different. What makes sense in one app, would not be a good decision in another. The actual decisions have to be made by those with domain knowledge in the app.This article provides a framework within which to make those decisions.

Start With the Big List

Pick up a copy of Designing the Obvious, A Common Sense Approach to Web Application Design and jump to Chapter 3:Build only what is absolutely necessary. That is the approach we’re taking here and this is what it looks like.

Let’s call the brainstormed list of features the big old everything we could think of list – or the big list for short.

Here’s the Big List

Here is a readable “big list”.

This is actually a short big list. These lists grow by the minute. Yet the most essential features probably found their way onto the big list early. So don’t spend forever on this thing. It should be relatively quick.

Reduce to Essentials

Now, go through each item one by one asking:

• If this feature were not in the application, would the application still function and still support the single activity it is meant to support?

If the answer is “yes – without this feature the app would still function and still support the activity”, then strike it off the list. Here is where we need to be ruthless. Remember that additional features can, and will, be added later. Remember that “simplicity” is a key feature of this application and one of the easiest ways to simplicity is by thoughtful reduction. Remember that too many options thrown at new users at one time makes for a frustrated user and a poor user experience. Continue removing items until the list is down to at most half its original size and ideally 25% of its original size.

There are other questions you might ask to qualify a feature for the short list:

• Is this feature self-evident or is it difficult to explain? If it takes an explanation, it probably is not a good feature for version 1.0. You’ll be busy enough rolling out the app to keep you from promptly and adequately answering questions about advanced features. Also, the first time the world sees your application, it is more important that the application meets the expectations of those that use it than it is that you have thousands of users attracted to a long feature list. Said another way, it’s important that the first impression leaves no head scratching.

• Does this feature give the app the personality we want it to have? We’ll talk about an application’s personality in a later article.

The Big List with Non Essential Struck Out

What you are left with is the feature list for version 1 of the application.

The Essential List

Here is our sales team collaboration software “essential” list.

Everyone Loves Upgrades!

It’s literally human nature – to want more, not less. So looking at our short little list, it’s easy to become discouraged at this point and say “that’s all?”. Yet remember that by constraining ourselves to less initially, we get a quality product, released earlier, and are more likely to offer a good customer experience. We also create an opportunity to over deliver by following up with enhancements.

Items on the big list that did not make the essential list become instant candidates for enhancements. In determining the release 1.0 feature list, you have also started to build an enhancement path. Shortly after launch, go ahead and add in that one feature that was most difficult for users to let go of. With a successful initial launch followed by a surprise improvement, you’ll instantly be a hero.

Additional Criteria

Don’t implement the feature set of your competition is good advice from Ian Landsman. The big list should be built from your understanding of the users’ needs, not from your competitor’s feature list. Just because a competitor has a feature does not mean it provides value – in fact users may not like or even use the feature – you have no way to know so just avoid it all together.

Other criteria for feature selection might include:

• What are your strengths?
• What can you most quickly deliver?

I like the “essential” test and it has gotten us to this point. We now have our version 1.0 shortlist.

Next

As we move forward let’s give our app some personality and an identity by giving it a name. That’s just what we’ll do in the next entry.

Click here to read the next Making of a Web App entry.