Good design is as much about knowing what not to include, as it is knowing what you should put into your product. Understanding why not to include some feature or element is critical to creating stellar product experiences, and it’s this type of thinking that can prevent a lot of headache for your customers down the road.

On a recent project involving a major insurance company, we were designing a tool for advisors to manage their clients’ portfolios. In the initial spec and designs, we had a simple feature: a lightweight inbox for managing communication with clients through the application, so that these advisors had a centralized location to manage these relationships.

As we started designing, something didn’t feel right. On its face, the feature seemed to make sense, and inside the context of the application, it was a natural extension of the functionality. The problem was, this feature didn’t consider what was happening in the entire experience ecosystem. In the end, we decided having this inbox functionality was going to create some big problems down the road, and we removed this large chunk of otherwise helpful functionality.

So – what happened? Why did we decide to remove a feature that seemed, on its face, to be a great addition to the product experience?

We looked outside the application and considered the entire experience.

The revelation came as we started to talk through what kind of messages would be sent through the app. A team member innocuously asked: “What is this, an email?”. Bingo – lightbulbs.

That question was pivotal, and led to an avalanche of logic. If these messages were basically the same as an email, what would happen if the client and advisor started communicating through traditional email, outside the app? What if one of them just opened Outlook and fired an email to the other? Where would it be?

The answer, naturally, is that it’d be in the email inbox, not the application inbox, meaning both parties are now managing two disparate communication channels with one another. Ouch. For either party to gain a holistic view of the total conversation, they’d have to manually (read: in their head) aggregate the two streams to piece together the whole picture. (Imagine, for a moment, a picture of a user printing all the communications out and putting them in a binder, just to have them all in one location. Not exactly the experience we had in mind…)

As you can imagine, that’s a problem, and one we didn’t want to create for the users. So, we completely dropped the entire piece, removing all inbox/messaging functionality from the app, intentionally restricting the features available to the users.

The interesting thing about this isn’t that we didn’t include a feature – any good design should demonstrate restraint. What’s interesting is that the feature-set of the product wasn’t informed by the product itself, but on the effect that the feature would have on the entire communication ecosystem that users were managing. Like a good chess player, being a good designer is often about thinking about what effect your moves will have, several steps down the line.

So, next time you’re designing something, and advocating for MOAR FEATURES!, remember to step back and look at how they affect the big picture. What seems logical and desired on its face may end up creating a mess for your users in another area of their life. Look at how your product fits into the entire ecosystem of their life, and make sure you’re respecting the entire picture.