Indefinitely postponing really great feature suggestions is one of the toughest tasks in UX design

This past week I had the occasion to reflect upon the towering list of fantastic feature suggestions people have contributed for Cozi which I’ve had to keep out of the product. I regularly hear good—sometimes brilliant—ideas for Cozi's product, but I’m generally forced to say, “Maybe later”, to nearly all of them.

One core aspect of software’s nature which shapes the user experience design discipline is the inherently iterative and additive nature of the publicly visible output. UX design shares this iterative trait with fields like urban planning and certain types of performance (e.g., stand-up comedy) where the artist is constantly tweaking what people see and hear. Those fields, however, are often zero-sum: a new downtown building replaces what was there before, and a new joke pushes an older joke out of the routine.

In contrast, there's a nearly irresistible tendency for software features to accrete:

• A user who has found something they like will scream bloody murder if that feature is taken away, and it turns out that every feature will always have at least some passionate adherents.
• Removing a feature that affords access to previously-entered user data would effectively maroon it, a nearly unforgivable transgression. You’d have to first create some way of getting that data out, which is extra work, which means time, which you don’t have.
• If you remove a feature, it will almost certainly be perceived as if you’re lowering your value proposition. Even if you hope the increase in usability will eventually allow you to deliver a better experience in the long run, that’s a pretty hard argument to sell to a customer.
• Someone who worked hard to bring the feature into existence may still be around and defend it vigorously (perhaps failing to recognize the market has changed).
• Or, on the other extreme, your team may have forgotten the feature exists.
• Or, your team knows the feature exists, but may have forgotten why it exists. No one wants to pull the plug on something in case it turns out to be critical. Surely someone important needs it, right? Better to be safe and leave it there.
• Given all the above, at any given decision point, the cost to keep an old feature working often seems pretty low compared to the cost of retiring it.

So the number of features tends to monotonically increase, which generally means complexity does as well. This fact is so universal that it’s notable when a product team removes a feature.

The catch is this: not all those features will retain their relevance over time. The world will change, user priorities will evolve, and your business goals will shift. A feature that was deemed vital when introduced may lapse into persistent clutter in your user interface or a persistent drag on your operation.

Here’s a common situation: we’re working hard on a pending release, and there’s a feature just out of reach; it’s not going to make it into the release. It’s painful to defer working on it, because we’re certain it’s very important. Then, when the pending release is finally finished, and we finally have time to do that important thing — no one’s really that excited about it. In the few weeks that have passed, we’ve learned something new that has convinced something else is more important. The earlier idea, which has previously seemed mission-critical, never ships. And—whew—that’s a good thing. We came this close to adding new clutter to our product that we can (obviously, in hindsight) live without.

Some people say you need to say, “No”, to ideas to keep a product clean and simple. But that makes it sound like you can make one decision and be done with it. You just never know; the feature you’re saying “No” to might turn out to be important after all. I think maybe it’s more correct to say, “Maybe later.” A good idea (or a clear user need) will be persistent, and over time will keep knocking at you until, one day, something clicks and you realize how you can address it and three other things at the same time, in a much better way than you could have if you’d plunged in right away. During this long period of consideration, the idea has aged and matured until it’s time has finally come.

This can only happen if one adopts a deliberately slow pace of idea adoption. Ultimately, I think being able to say, “Maybe later”, to a really great idea is a hallmark that distinguishes an experienced UX designer from a novice.