Designers are always advocating simplicity in the user interface and information architecture because too much clutter distracts the user from focusing on the task at hand. However, customers are constantly clamoring for more features and functionality because increased options makes more tasks possible in the absolute sense. Going all the way in one direction, we end up with a plain sheet of paper, which has no technical features whatsoever. Going in the other direction, we end up with a product like Microsoft Word, which has more buttons and hidden menus than one could ever hope to discover. But wouldn’t it be nice to have a balanced tool that performs between these two extremes? Perhaps a better question is actually, how do you achieve this balance?

One possible solution is to build a platform, meaning the core of the application is used as a foundation for other features users might want. This approach entails creating a basic tool that is simple and easy to use, while allowing for the option to expand into more functionality as needed. Recently, using a platform has seen tremendous success in examples such as Firefox’s Plug-ins, iTunes’ App Store, and Evernote’s Trunk. Essentially, since 80% of the users only use 20% of the features anyway, those customers will be completely satisfied with the default experience. And for those power users who want to do more, the product extensions allow them customize their user experience without cluttering the tool for others who don’t need the extra functionality. Furthermore, using a platform approach also solves for the issue that not all power users want the same thing because choosing extensions isn’t a binary decision. You don’t only decide whether or not you want an extension, you also get to choose the one that is right for you.

Going with the platform route is not without its pitfalls though. To start, you run the risk of taking on the worst of both worlds because the app is unable to find the right balance between what should be considered standard versus what should be considered additional. In this case, the default app might be too bare bones, while adding an extension pushes the difficulty of interaction too high, leaving the user with no safe middle ground. Additionally, this method is also risky because it depends on external developers for its success. In regards to this issue, you must figure out how to get enough credible traction in the developer community to reach the minimum threshold for success. You would also need to institute a system of automatically filtering different expansion packages for quality. Being open to all submissions means lowering the overall quality of extensions, but being too stringent means limiting growth. There is also the possibility of manually reviewing each submission, but that process opens up its own set of issues. Finally, building a platform is just plain hard. Rather than just designing a certain subset of features, you must design features that allow for a limitless amount of other features. Developing a system that must incorporate any number of possible futures is simply rife with risk.

In the end, no single direction will be perfect.  When Microsoft first developed MS Word, it probably started out as a very basic tool that had nice upsides compared to a typewriter.  However, bit by bit, links and buttons were added until the product eventually became the feature-bloated monstrosity that people use today. As a result, while Microsoft’s intentions were probably in the right place, not having a predetermined plan for growth leads to unfortunate compromises further down the line.  With the benefit of foresight though, a new product does not have to follow the same fate as it scales.  Therefore, despite the aforementioned drawbacks, going with a platform approach is the right path because it allows us to reach our original vision of creating a tool that is infused with many technological benefits, while still remaining as simple to use as a piece of paper.