Minimizing Complexity In User Interfaces

Alternatively, if adding a feature demands a massive refactor, then it might be a warning signal that you've got some fundamental issues with your UI. In that case, it might be worth it to spend the time re-examining the core design of your app.

You also might refuse to support that feature. Being able to say "no" is an important skill, both as a designer and a developer. Leaving stuff out is often as important as putting it in.

I recall reading on Jensen Harris' Office 2007 new UI blog that they tried their damnedest to remove features, but no one could come up with any reasonable way to pick any features to cut other than a select few which were practically unused by anyone. They had extensive usage data to work with. Meanwhile, the feature-poor Windows Live Writer has taken off like a rocket for bloggers.

That may be true for something like Excel, Word, Linux, etc, but I think that wouldn't be as true for vertical applications. Sometimes, I wonder if would be better off turning the core word processing components into a library and releasing verticals for different types of writers. Professional writers, for instance, probably don't need any formatting tools other than headings. Blog writers should only use things that can be represented well by typical HTML blog engines. Etc.

I think this is a case where the advice that is right for startups (typically verticals) is not right for the big guys. As a little guy, I'm betting on nailing 20% of the features and scoring 18% of what people want :-)

Sure, but to do that the feature must exist in the first place. The author of the original article makes a distinction between eliminating a feature and hiding it. What you suggest is a clever way of hiding a feature.

I'm ambivalent about the idea of hiding a feature based on usage. Microsoft had that idea of hiding menu items that were not frequently used. I don't know anyone who liked that. I always disabled it because I didn't like my UI to change all the time. If I use a feature rarely, I still want it to be where it was last time, not move around until it's seven nested dialog boxes away.

But you can simulate the absence of features by hiding them. In terms of usability, Word defaults to hiding menu items, to remove the clutter of rarely used items. Many people don't like it, and turn it on, just in case they need something, but the fact that MS has chosen to make it the default maybe indicates that it's been favourable in their user trials (though they also choose clippy). The same thing could be done for vertical specialization.

Finally, I agree with you about startup strategy. My reasoning is that you have limited time and resources for implementing and polishing features, so you'd better focus on what's really important. There's that marketing concept that if you really nail it for some specific niche, you'll be successful with them ("a small number of users really love you"). That's much better than making it almost acceptable for a huge number of people.

I think that if you can later add other features that also have some value, you should. 37signals disagrees, saying you should keep the feature set tiny and unbloated (though they have added whole other separate products instead), But maybe there can be a natural life-cycle for vertical applications that grow and generalize into a horizontal application, as capabilities are (sensibly) added, as in "Text editors evolve until they can read mail. Those that can't will be replaced by those that can"