Friday I’m speaking at the Mobile 2.0 conference in Mountain View.   The topic is “iPhone for Business”, which, if I took the topic literally, raises many issues about distribution and maintenance of smartphones in the enterprise. But I’m really just going to focus on the narrower issue of “iPhone apps for business”: how do you build compelling and useful smartphone apps for enterprise information?

This is informed primarily by my experience helping companies build smartphone apps for internal use using the Rhodes framework.  Most of these smartphone apps are internal company apps for areas such as: helpdesk service requests, home healthcare patient service delivery, and CRM customer and product management.  A few are on the App Store such as VDG Group’s Issues To Go for bug tracking and Koombea’s TrackR for Pivotal Tracker.  To be clear, not all of the apps I’ve seen use all these guidelines (in particular one I’ve seen violated often even with Rhodes apps is “context sensitivity” below).

From these experiences helping our ISV and internal enterprise customers (and using their apps), I believe there are a number of areas that smartphone app developers for business should pay particular attention to.

Context Sensitivity

Don’t just a put a laundry list of activities (i.e. a “top menu”) at the top of your app.   There should be a natural page that you can take your user to which has functionality.  Typically this is a list of records. It might be a list of customers, a list of “stuff” (assets, products), a group of “issues” (tasks, bugs).  Whatever it is that the app does.   There can be other tabs at the bottom of the app that describe what the app does.   Ideally the objects exposed on those tabs modify what you do with the original list of objects on the “home page” (or first tab).   There should also be a tab for settings that controls the overall behavior of the app.  If you find that you’re doing more than five tabs, the app is too diffuse.  Write another app to handle the widening set of objects.    Which raises the next point…

Start With A Single Task or Object

Indeed, in the early days of your app, just start with the ability to do a single task or work with a single set of data objects.   It will take your users, not initially used to using apps for business on their smartphones right now, a while to absorb this capability.

Device Capabilities

Smartphones aren’t just “pocket-size PCs” (despite names like PocketPC and Windows Mobile).  They have an amazing array of senses that are really an extension of their owner: sight (camera and video capture), hearing (audio capture), touch (the touchscreen), sociability (PIM contacts), direction (magnetometer), location-awareness (GPS).   People generally don’t have or use these senses on their laptops.

Almost all apps I’ve seen can benefit from GPS and image capture.  But most of them didn’t include such capabilities in their first envisioning.   Even something as simple as a customer list can usually benefit from a proximity based sort when in the mobile sales guy’s hands.  Consumer apps are usually thinking from the start to use these capabilities.   Always think of how the unique capabilities of the smartphone device can enhance the application usage experience.

Local Data

Study after study has shown that mobile professionals aren’t willing to rely on the mobile device to do their job if they are concerned that they will lose their work.   If you want your enterprise app to be actually used and interacted with remotely (not just used for reference) you have to give users the ability to use their information even when offline.

Consistent Branding

Early web apps attempted to look as much as possible like Windows apps.   Eventually companies realized that it was better to maintain their own branding on those web apps rather than make them seem like desktop apps.   The same thing is happening with early iPhone apps done by businesses today.  The iPhone user experience for its own built-in apps is so compelling that many apps choose to make their apps like like Apple-shipped iPhone apps.    For example, a company will show its customer list on the iPhone as an “extended contact form”.    Typically its a bit of a force fit: the names aren’t quite the same and usually a company has more data than is present on the iPhone. The “make it look like the existing native apps” approach doesn’t scale out that well to a wide variety of business objects.  It also loses an opportunity to create a consistent branding and user experience across multiple devices.

Regular Small Feature Delivery

The best smartphone apps do one thing and do it well.  As you enhance your app you’ll want to beware of feature creep.   Do small releases with one or a few features.  Gauge what your users truly need next before launching on large groups of features.   Ideally work with some toolset that allows very rapid iteration on the appearance of those features (Objective C for example may not meet the bar for this).