The "one app" approach
A single application delivering a multitude of functions has some immediately compelling benefits. Users searching for applications from your company are not presented with a confusing array of different application choices, and you're able to present one user experience and set of branding. From a technical perspective, you can employ a common set of functionality that can be reused across different application functions and have only one codebase to maintain and update. In short, one "tool" serves a variety of functions, much like the popular Swiss Army knife.
This makes a great deal of sense if your organization provides a relatively cohesive set of services. For a company like an airline, a single application that ties flight searches, bookings, check in, and airline information benefits from a cohesive experience. For companies that have a broader set of products or services, this begins to make less sense, especially as you consider internally-targeted applications. Suppose you want a single internal application for your company. How do you integrate functionality that might be as diverse as displaying financial performance, booking meeting rooms, or entering a new IT support ticket?
The single purpose application
Much like a purpose-built sniper rifle that's designed to hit a narrow target, some companies choose to create purpose-built applications that serve a very narrow function. Your sales force might require a very different user interface and functionality than your supply chain staff, and thus different applications may make perfect sense. For public-facing applications, highlighting specific products might drive a purpose-built application or a desire to get some piece of functionality, however small, to your customers sooner rather than later.
Deciding between the two
To decide between the two broad categories of applications, start with the following questions:
- Who is my audience? Determine the audience for your application, and if they'll have similar expectations for your application and similar requirements for information. While the aforementioned airline app has a very broad audience, they all represent travelers on my airline.
- What are their expectations? While your audience may be in the same demographic — for example, people who work for your company's European office — they may have dramatically different expectations as to what they hope to accomplish with your mobile application. A current customer for your company might expect deep support and troubleshooting capabilities, while a prospect would expect flashy imagery and product information. Internally, someone in the back office might expect internal support functions, while someone in field sales would expect access to customer and product information.
- What's our timeframe? A "Swiss Army knife" may sound like the right approach initially, but sometimes getting some functionality out the door is better than getting complete functionality. Conversely, if the resources are available, shipping an app that offers minimal functionality and low benefit might sour your customers to future apps, steering you toward a more complete solution.
There's really no perfect answer as to whether a highly functional single application trumps optimized, point solutions in every case. Spend the time considering the three questions above and, like most areas of technology, you'll find the solution that best suits your company and its current circumstances.
Which is the best fit for your organization and why? Share your feedback in the discussion thread below.
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at email@example.com, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.