Whether building an internal mobile or tablet app, or one targeted toward millions of consumers, a fundamental design question that should be addressed early in the process is whether you want to build a multi-purpose "Swiss Army Knife"-style app, or a singularly focused "switchblade" that performs one function, but does it extremely well.
Much like the early days of the web, empirically proven rules around app design have not yet evolved. There are poorly done multi-function apps that feel inconsistent and bloated, just as there are multi-function apps that have everything in the right place and keep users engaged through a broad array of related functions. Avoid anyone who promises "gospel" around how your app should function without understanding your objectives first, and use the guidance below to guide your thinking.
Small may be beautiful
While no universally applicable guidance exists, the current thinking in the app design world points toward apps that perform a single function, and perform it well. Users generally won't open their banking app and be disappointed that it doesn't provide the weather in three countries, or open their Time and Expense app hoping for a game. Apps generally provide a "bite-sized" experience that performs a specific task, and performs it well, lending credence to the wisdom that "small is beautiful."
However, limiting the functional focus of your app doesn't guarantee success. An app with limited functionality needs to have a razor sharp focus on delivering that functionality at the right time, in the right context. If I'm building a navigation app targeted toward someone walking, I might be able to ask several questions about how they want to calculate their route, provide frequent descriptive text about upcoming turns, and might even provide prompts for interesting landmarks. However, if I'm providing the same functionality for someone behind the wheel of their car, prompts, distractions, and routing options are a hassle. Sign-up screens provide another compelling example. If my highly focused and targeted app requires a multi-step signup process, multiple prompts for information, and email verification before I can even use it, users will likely abandon the app before they even experience your well-designed single function. In short, a single function app requires even more care and focus to ensure the user can deploy that function with just the right level of information and interaction.
While there's truth in the general advice to focus on a single function and deliver it well, disparate yet related functions can prove highly beneficial when packaged in a logical manner. A travel app that provides the weather at the destination makes a good deal of sense, just as a Time and Expense app that includes an integrated currency converter and calculator would prove useful. As a less conventional example, a popular app for ski resorts provides links to live traffic cameras, allowing you to view traffic on the way to popular skiing destinations before you embark on your trip, allowing for a comprehensive planning tool for your ski vacation.
Just as the popular Swiss Army Knife provides a variety of related tools for the outdoorsman or handyman, your app should group its functions in a logical and sensible manner. Avoid the app equivalent of putting the delicate tweezers too close to a sharp blade, risking cuts or difficulties when deploying a tool. At their best, multi-function apps only make additional functionality available when needed, having carefully considered how the user will interact with the app and when they'll need that tool, rather than immediately providing access to everything the app has to offer and overwhelming the user. This can create a far more compelling and useful app than taking the related shortcut of creating dozens of single-purpose apps, and forcing users to find, download, and manage the equivalent of a bag full of tools versus an elegantly integrated multi-tool.
One benefit of most modern mobile devices is that they already include a raft of tools that you can exploit to build your experience, whether it's a single function app or massive multi-tool. Geolocation and mapping capabilities are included with every major mobile OS, just as various notification systems and communication methods can be easily accessed. There's no need to develop a complex navigation tool as part of your app when you can exploit the native mapping capabilities, just as it makes little sense to build an app-specific notification system when OS-native and third party solutions abound. As with any multi-tool discussion, don't tack on a native tool just because it's there. Make sure the function is delivered at the right time, and otherwise kept out of the way.
Before writing a single line of code, or producing a single wireframe, consider what the ultimate objective and experience of your app should be. Does this experience require a single function to complete, or are multiple tools required to get the job done? If you can successfully deliver the experience with a single tool, make sure it's focused and built to deliver in the context where your users are most likely to use the functionality. If multiple tools are required, carefully consider how they'll be integrated, and presented to the user right when they're needed rather than overwhelming the user with choices.
Agreeing on a direction early in your app creation process will guide your discussions later on, and avoid the frequent urge to add functionality just because it's interesting or available as part of the OS. In all cases, consider the user and how they'll access the functions you're delivering first and foremost. Functionality should enable the user, rather than drive the discussion.
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 firstname.lastname@example.org, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.