The Vanity of an Ancient King

Mirrored from Localtype.

Comments are open over there. Use your LJ ID to reply

While the actual quote eludes my Google fu, Coco Chanel once said something to the effect of “Before you leave the house, take a look in the mirror, and take one thing off.”. People are notorious for wanting more, and yet rarely satisfied when they get it. This is made blindingly obvious in application development, where users often have direct contact with app creators before and after the sale. Wanting more isn’t just a user phenomenon. It starts in the application development process. Developers aren’t immune to the siren call of ‘more’ any more than anyone else. We should however, fight this urge if we want to deliver better apps.

All application development starts with an idea. “It’d be cool if there was an app that did…” is the spark that ignites the development and design process. Along the way, more ‘cool’ ideas come up, and often included. The problem with ideas that start with “It’d be cool if…” is that the answer is always ‘yes’.

In a sense, app development is similar to writing a novel. Functions are like characters. Each is explored, and given life. They develop unique personalities, and often, the characters tell the author what they will do next. This leads to a much more robust, believable character, but it can quickly get out of hand. At some point, you lose the narrative. In a worst-case scenario, you wind up with the Homer Simpson Bubble Car — or iTunes.

Like every good writer, every good app developer needs an editor — someone who can take a look at what your app does, redline the hell out of it into a leaner, more coherant story. Nowhere is this more needed than in mobile app development. The most successful apps on a mobile platform tend toward simplicity. They often do one thing, but do it very well. Apps like Instapaper, and Readability are popular for this reason. The limited space provided on a mobile screen demands a level of simplicity and focus. You want your users to launch your app, do what they need to do quickly, and leave your app so they can get on with their lives. Applications that provide this experience are used more often, as users don’t feel the dread of getting mired in the app’s UI or panoply of choices. People use apps like Flipboard because they are delighted by the content they bring.

As an exercise, start with an idea for an app. Take everything away until you have achieved an application that is so minimal, any additional functionality removed would cause the app to do nothing at all. Build that. Ship that. Observe how your users are using the app. Continuously refine your narrative based on observed evidence. The best apps lead users with intelligent decisions made by the developer. Users don’t have time to weigh the impact of their decisions within the app. If you hand them a diner menu of options, they will opt for a black coffee.

There is a story about an architect who built a university. All the buildings were designed and built, but there were no paths to any of the buildings. People couldn’t understand why no paths were built. The architect answered “The students will show us the best paths to make.” After a few months, the grass on campus had noticable wear where the students beat a path from building to building. Shortly thereafter, cement paths were created based on the natural behavior of the students. If they attempted to solve this problem before the students came to the campus, they would have made wrong assumptions. Now, they had empirical evidence on what should be done.

Building a simple app with limited functionality is also a fantastic way to create a solid, bug-free base on which to build. I am not an advocate for no functionality. I am an advocate for smart functionality. I have a rule of thumb: I will only build in a new feature if I think at least 90% of my users will use it nearly all the time. Your users will tell you what they want in an email, in conversation, or in feedback forums. Don’t be fooled. That is the siren song.

Users will show you what they need by hacking your app to meet their goals. Twitter is a fantastic example of this. When it first started, All it allowed you to do is post a 140 character message, and receive messages from people you follow. It was simple and elegant. People flocked to it in droves. There were no @replies, no RTs, no DMs, no Lists, and of course, no Dickbars. @Replies were born out of a need to respond to tweets. It was a convention that users made up themselves, and eventually incorporated into the application. The same goes for RTs and DMs. The one ‘feature’ that wasn’t originally hacked together by users was the Dickbar, and we all know how much of a miserable failure that was.

I’ve seen (and regrettably created) far too many apps that cram far too much into a user interface. We are reaching an age of transparent computing, where content is the most important, access is easy, and the best UI is no UI at all. Build small, and allow for discoverability, serendipity, and joy.