Scotch and Code

Consider a user talking about your app saying, “it can do this, it can do that”. Now compare that to them saying that with your creation “I can do this, I can do that”. The difference is syntactically small but incredibly important from an application design and implementation perspective. In the latter case of a user saying that with your app they can do this or they can do that, you have successfully interlocked the users intentions with the features your app possesses. That is, the reason the user picked up the device to run your app and the end result they wanted, was perfectly and intuitively accessible to the user without thought of what the app can do and how that might translate into what they wanted to do. Invisible UI, intuitive user experience, knowing how to use an app the first time, etc, etc; they all require the same thing: for the users intent and the applications features to be one.

Features are things your app can do. On their own they tend to be processes and actions. You implemented them to interact with an underlying web service, modify a data set, produce a particular visual effect on an image, etc. Without them, your app is nothing. Just as important is mapping these features to the users intentions. That’s when you go from a good app to a great app. My favorite example of this is RSS feed reader apps and the like that allow the user to ‘Star’ an article. That’s a feature your app provides. You have written code that gives the user a button which when pressed interacts with the underlying web service such as Google Reader to mark an article with a particular attribute. I guarantee you though, the users intent had nothing to do with stars. The user just wanted to remember that article for later reading. Thus the users intent and your apps feature are mismatched. Sure, the user will work out that they can “star” an article and that classifies it a particular way so that they can find it again later. But what would have worked better is if the user had a simple “Read Later” button that stored the article in an aptly named location for later reading. That you used the Google Reader “starred” attribute to achieve this is your own implementation detail that is irrelevant to the users intention and desired result.

This mismatch can be more generically defined as when we as developers present the user with an ability to perform a discrete action without wrapping it up in a work flow that makes that discrete action both invisible and implied. At a developer level, Apple’s iCloud API is an interesting example of this. The API centers around the concept of ubiquity, not syncing. Cast your mind back to the WWDC 2011 announcement of iCloud… Bloggers and journalists picked up on the fact that not once did Apple speak of iCloud being a sync mechanism. The prevailing interpretation of this was that it spoke to the iCloud implementation of “the cloud as the truth” as opposed to the peer-to-peer sync systems we were used to. Having now worked with the API and continuing this idea of feature and intent, I think it speaks more to Apple’s focus on the users intent. The user doesn’t want or need a sync mechanism. They want their data to be ubiquitous: on all their devices automatically and without thought. Ubiquity is the intent, synchronization is the feature.

The iPhone 4S ad that shows Siri continues this theme. Notice how it is shot such that the users face above thier mouth, and anything below their hand holding the iPhone is out of frame? It’s beautiful. Without saying it, the purpose of Siri is clear — it’s a direct connection between your voice and your phone. Eyes, two-handed typing, and moreover the thought process of translating words into tapping gestures on a virtual keyboard all need not apply. We know from experience that Siri can mine Google, Wolfram Alpha, our own calendars and other sources of information. However, the ad for Siri doesn’t spell out these features because they are technical implementation details that should not get between the user and their intention. She just wants to know whether or not to take an umbrella tonight. That’s the intent. The speech interpretation, network resources, server farm, weather service API etc, etc are all “just” features. Recently we’ve relegated specifications to the realm of the obsolete. I think features, on their own, are next.