Five tips for fast and effective mobile travel app development
Cloud-based applications over the past decade have introduced a shift in development processes, moving away from long spec > dev > QA phases, into very short release cycles, or sprints.
Typical release cycles for most web platforms today can go anywhere from one to four weeks, with many folks working on continuous integration and even daily loads.
There is a lot of documentation on fast iterative development processes and it’s not my goal here to repeat all the pros and cons, but there are two aspects I want to highlight:
- Ability to put something very quickly out to customers, measure usage, learn, and take more relevant decisions with more information at hand.
- Ability to A/B test different versions, measure, and decide the best way forward;
Both of these items open the door to one critical input that is missing in classic and longer release cycles: actual customer usage feedback. With actual usage feedback, decision making is made easier.
Enter mobile apps
User expectations with mobile apps are much higher than when using web sites. With all the great apps out there, anything that is not smooth, fast and intuitive will just become part of the 90% of apps never used again after the first download.
It’s very important to launch something of good quality.
Great, but there is a problem:how can you iterate quickly on a mobile app that needs to be installed locally on a remote device and possibly not used again for months? And how can you do so when every new app version can take weeks to be approved before being available in an application store?
Existing analytics software providers have solutions for mobile apps too: Comscore (Nedstat), Omniture (SiteCatalyst), Adobe (appMeasuremement), Webtrends and many others. These work very similarly to their web older brothers: track events, log, send events back to a cloud service, generate reports.
But before getting there, how can we iterate fast on the first release?
Here are some tips, and I encourage everyone to share more in the comments.
1. Use paper mockups
You can start by hand designing options for user flows and layouts on mobile-shaped notepads (search the web to see some examples).
These are simple paper notepads with the exact shape and dimensions of most common smartphones.
You can lay each card in front of users and aks them to tell what they expect to happen, which layout choice they find more intuitive, and swap/replace cards as needed to create the best flow.
Very simple, unexpensive, effective.
2. Iterate very fast on interactive mockups
Some wireframing and mock-up tools provide relatively simple drag and drop solutions generating interactive prototypes in a matter of minutes. Most tools also generate HTML5 output, or even basic native apps.
These are in general good enough to give a good sense of the functionality expected, and can already be used for initial end user testing on both Android and iOS devices.
Tools like Tiggr, Mockflow or Axure can generate interactive prototypes. Even simpler tools like Adobe PDF, Visio/Powerpoint/Keynote, Pencils, Balsamiq or Omnigraffe can generate static mockups by using mobile UI stencils. Static mockups can be linked up to illustrate the screen flows.
3. Test on prototypes with a small set of beta testers
Get a small set of beta testers and give them apps to play with, even if the apps are not 100% complete. The key is to ensure at least some parts of functionality are complete so that users have something tangible to test and won’t be entirely frustrated.
Get daily feedback from users, and make it totally effortless for them to provide feedback at any time. Don’t try the opposite – making it cumbersome for them to fill in complex feedback forms, just to reduce your analysis effort.
For example, ask users to simply write back the top three good and bad things each day to a feedback email address you provide.
4. Android first
This is not a religious choice, simply a smart choice to exploit Android’s easier distribution architecture.
Beta apps can be quickly published under obscure names to be shared only with beta testers, without having random users discovering them.
Apps can be updated at any time “over the air” for bug fixing or feature changes, without waiting for lenghty store approvals. By iterating very fast on Android, creating apps on other mobile OSs becomes more similar to a porting process than a new development.
Apple is getting faster with short two to three-day approvals, and solutions like TestFlight get you very close to over-the-air beta testing on iOS.
But anyone having worked on a software project knows what it means to wait for two days before having something out. Sometimes (especially in travel), the state of world is just different.
5. Launch in a small country first
Another way to get something out quickly is to publish on stores specific to smaller markets.
If anything goes wrong, you’ll have sacrificed a small market, but hopefully you’ll nail the big one. OK I admit, this is politically incorrect, you decide the best for your business.
If you have other experiences and tips to share, please do so in the comments below.
Daniele Beccari is a contributing Node to Tnooz, and head of travel products at Criteo.
As travel technology strategist, he has helped startups and blue-chip corporations define and launch innovative solutions in leisure, corporate, online and mobile sectors. He also served as Vice President, Europe and B2B, at Isango! (now part of TUI), and previously as head of corporate products for the e-travel division of Amadeus.
He started his career at HP, working on what is known today as the Internet of things. An MBA graduate from INSEAD, Daniele can be found somewhere between Paris, London, Turin, San Francisco or Tokyo.
Daniele's views are his alone and not the views of his clients or employers.