Application Definition Statement
Mobile platforms are very special. By definition, people that uses mobile apps are moving. and thus has no time to spare for an app.
People, real people, uses apps in all kind of contexts, and a wide range of environments, but frequently, the user attention is divided between the app, and the real world. Most users has no time (neither are interested) in immersive processes, but in tomorrow weather forecast while waiting in the queue at the bakery. A few tap has to be enough for the user to get in and out of the app, knowing that tomorrow is going to rain. This calls for visual simplicity, which, as anyone can attest, is not easy to obtain. But then, there is a more deeper level, the real foundation of any good mobile app, that is even harder to grasp, the Application Definition Statement.
Traditional software development cycle allocates no more than five or six percent to design, and usually, that time is spent upfront. With mobile platforms, at least half of the time should be devoted to design, and here design does not means “makes things pretty in Photoshop”, but “makes app valuable carefully thinking how it should work”. The main job here is to scope out the app, figuring out hierarchies, mapping out information flows and how different objects interact with each other. We need to be intentional.
Application Definition Statement
Every single app is born as a long laundry list of nice to have features. Add features to a list is really easy. The problem then is that the application ends up being a container where we shoehorn feature after feature. We keep piling features hoping to satisfy the requirements of the whole world. Truth is that we can’t. So, here’s the real important twist.
Define a Solution, not a collection of features.
The very best applications are those that makes just one thing, but in that one thing, they excels.
And a neat trick to make sure that we are not building a container, but creating a solution, is to writing an Application Definition Statement and then keep repeating it as a mantra.
An Application Definition Statement is composed by three distinct parts
(differentiator) (solution) for (audience)
The differentiator is what takes the app apart from the herd. Is what makes the proposed solution special. Then we found the actual solution, What problem is the application supposed to solve for the customer? And the final component is the intended audience. The intended audience is never “as many as I can get”, because the more precise it is defined, the better the app is going to be. For instance, if the intended audience is formed with people driving (for instance a GPS navigator) then the interface should be almost invisible, with a voice giving directions.
Getting back to the bakery queue, one possible Application Definition Statement for the Weather app of the iPhone would be:
Easy to use weather forecaster for casual users.
Sure enough, the App Store packs a wide range of weather apps. Some of them excellent, but none easier to use than the one develop by Apple. You just tap the icon, almost instantly you’ve got the temperature, and an icon that tells you if it is cloudy. And a table with a 6 days forecast with the same kind of information. You don’t get humidity, nor wind speed. Nothing more than temperature. You need to know more because you are a pilot? Then you are not a casual user. And yes, you will also find an app with more information, which in turn might not be as easy to use as Weather. Just by changing the intended audience, the application might be completely different.
One important thing to note is that the Application Definition Statement is going to drive the design of the human interface. The solution propose by Weather is to forecast the very basic parameters for the next few days, namely, temperature, and overall weather. The overall weather is going to be translated into a set of icons which, at a glance informs a good deal, and a big region for the temperature.
Another important thing that the ADS will help to do is to pick the set of features that should be included in the app:
Pick the few features, most frequently used, by the majority of your users, most appropriate for the mobile context.
You don’t want to bloat your app, you want it to be as agile as possible. Why? Because people use app in quick sprints, wedged between other activities.
