Sometimes a small amount of difference in the data can make all the difference in the end result. Take DNA for example. Humans and chimpanzees may be 99% the same at a DNA level, but you wouldn’t want to invite a chimp over for dinner.
The same can be said about web versus mobile app data. They may be largely the same, but understanding the differences can have a huge impact on the end results.
This is especially true when you consider it’s not a technology problem that your app solves, it’s a customer one. The way people use web versus mobile apps is vastly different.
A helpful way of thinking about this is through the lens of the “jobs” they actually perform in people’s lives (a framework popularized by Clayton Christenson). Just consider your own usage patterns.
Personally, I use Facebook, the world’s most popular app, as a quick cure for boredom while waiting in lines at the bank, airport, or coffee shop. In that sense, its competition isn’t desktop email or photo sharing applications at all, it’s chatting to the stranger in line next to me (sorry, stranger).
I use the Starbuck’s app every day to “order & pay” for my coffee from my apartment a few blocks away. When I arrive I bypass the cashier and go straight to the barista — making the app a convenient alternative to the checkout counter (and to my coffee maker, which now sits idly at home).
And when the kids wake up too early, or get restless in a public place, I will “hire” an iPad or iPhone as a temporary, lightweight babysitter alternative.
From a “jobs” perspective, the difference between mobile and desktop isn’t a difference in degree, it’s a difference in kind. If the underlying data and technology isn’t fit for the purpose of handling that job, I will hire an alternative, which is often not a digital alternative at all.
In turn, the designers of these solutions — mobile app creators — need to apply the same lens when deciding what marketing and analytics tools to put to use in their apps. While every job is different, here are three things to bear in mind to help you “hire well” when it comes to building your own mobile solutions:
1. Mobile jobs are not “temp” jobs. People browse the web and visit web sites. The web is a quick, transaction-oriented relationship. In this sense, too much “remembering” from one session to another may even be considered creepy. By contrast, people install and use apps — establishing more meaningful and long-term relationships. When the expectation is that you’re entering into a long-term employment relationship, it’s frustrating when you have to remind an application of something you’ve already told it or that it could have inferred.
2. Mobile jobs involve the physical. Many mobile apps rely on the device’s hardware to “sense” inputs such as location, direction, speed, touch, and voice. While theoretically possible to enable some of these features through a desktop web browser, the experience is often subpar. For an app such as Uber or Waze to perform the location-dependent jobs they’re hired to do, they need to be implemented natively, which means a browser-based experience simply won’t cut it.
3. Mobile jobs are wherever, whenever. Mobile jobs are not “9 to 5” — they are whenever, wherever. For example, Concur’s expense management app replaces the old routine of giving receipts to an administrative assistant or doing them by hand. However, many business travelers like to do their receipts on the road, or on airplanes, meaning that it needs to perform when Internet connectivity is spotty or none. Most browser-based services completely fall apart when the device is offline (say, the user is on an airplane). With an app like Concur’s that just isn’t an option.
Even when tools seem to be “more or less” the same, remember that it’s the relatively few but critical points of difference that really matter. You need to dig in to really understand not just a solution provider’s credentials in general, but their fitness to perform the mobile jobs required of your app specifically. Don’t be fooled by web solutions passing themselves off as mobile first. As the old saying goes, if it walks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.