Blogature

Here’s a conversation Jon and I have a lot: What is the incremental cost to the usability of our application if we add a specific new feature?

We think this is a critically important question when designing an interface. Thinkature is intentionally a really simply application. We offer fewer features than some of our competitors. Strategy, MBAs like to quip, is the art of deciding what not to do. Here’s what Thinkature doesn’t do: control line thickness, change fonts, draw hexagons, run filters on images, edit drawings, and draw straight lines. These are just a few of the features we’ve talked about adding and decided not to do so far. Certainly, there are a handful of people who’ve asked for each of those features. If we assume they’re representative we could make some small (but not non-zero) number of people happy by adding them. So why don’t we?

There are lots of reasons why not, but I’d like to focus on the cost of losing simplicity. It’s my basic belief that every feature we add to Thinkature comes with some cost to overall usability. Every added feature makes Thinkature slightly more overwhelming and confusing.

Now, it’s possible to make this cost approach zero. For instance, adding keyboard shortcuts is a nearly zero cost feature add. Adding another menu item to the “workspaces” menu (like export, which has always been destined to end up there eventually) would also be another nearly free feature add because the menu is still really short. But there are plenty of other feature additions that come with some clear cost to overall usability. For instance, if we added another button halo item (say, a copy button) that’s another icon users need to decode. Similarly, if we add a workspace feature like “manage invited users’ permissions,” that interface would need to get more complicated, and people who didn’t need that particular feature might get confused.

Now, I think both of those features are really useful, and both will probably happen, but we always ask ourselves what the incremental cost to the clarity and simplicity of our application will be, and whether the feature is good enough to be worth paying that cost. If you approach new features as not being “free,” you can avoid ending up with an application that looks like Word.

This attitude also changes the way we think about features. When we design new features, we have two jobs: make the feature effective, and make the incremental cost to overall usability as low as possible. Often, doing a good job on one of those questions means you’ve done a good job on the other, but we always try to think about both.