When creating a mobile application that has both an internal and external audience, the product owner must make some decisions. Do I build the functionality into single or multiple apps? How do I deploy these to my user base? Product owners need to understand and decide how to best build and deploy the mobile app prior to beginning the design and development. These decisions will have a significant long-term impact on mobile UX, security, and cost of ongoing app maintenance and improvement.

Internal mobile applications can range from precision task-oriented apps that will be used by a handful of employees in a single department, to sales enablement tools that provide value to a broad user base. These may be targeted towards internal staff or external resellers, and potentially, end customers. Each use case requires a diligent evaluation prior to beginning the design and development; examining precisely who will be using the application, as there are multiple decisions that are influenced by these factors.

Let’s talk through an example that shows some of the complexity of this decision process. A company already has a mobile app in the iOS and Android public app stores that is used by both their employees and their customers to access public product information. Now they are looking for a way to provide access to proprietary product information for their employees on-the-go. The two most common solutions would be:

1. Add a login-protected section in the existing public application, leveraging the existing app and infrastructure. The upsides are that employees likely already have the app installed, and would not be faced with juggling multiple apps. Building on the existing app would also create efficiencies in the short-term expediting the time-to-market. The downsides are that a company login mechanism is now exposed in the mobile app, providing an attack vector that previously didn’t exist. As the employee-only section is updated over time, this would require the entire app to be QAed and re-deployed to the app stores. This would ultimately add QA overhead and require new downloads for all users, including customers. Listing the app in the public app stores also puts a piece of the business operations outside of the organization’s control, since the app could be blocked and removed at any point.
   
2. Create a new employee-only application. Since it could create confusion for customers to see multiple apps from the same company in the app stores, this application might be better distributed through a different channel than the public app stores. Submitting a password-protected app could potentially also run into approval issues in the public app stores. Creating a new app would require more work upfront, as it is a new application altogether. On the upside, the code and data separation of internal business functionality vs. external functionality provides better security and maintainability.

Clearly, this is a complex and multifaceted decision. Laid out below are the factors that weigh on this decision making process with recommendations on how to move forward.

The 5 most important factors to determine upfront

In order to determine which factors to weigh in your decision making process, make sure all stakeholders use a common language and are clear on what job your product is trying to solve.

1) Who is your mobile app’s audience and their associated tasks?

First and foremost, it is essential to understand who the users will be that access the functionality of your app. Here are some examples of user groups we’ve seen in our projects:

• On-site employees
• On-site contractors
• Employees across multiple locations / campuses
• Remote employees (e.g. traveling sales staff, field teams, etc)
• Resellers
• Partner companies
• On-site customers
• Remote customers

If you need to further flesh out your audiences, empathy mapping provides a collaborative process to visualize and articulate what an organization knows about a distinctive customer segment.

2) What is the app’s feature set and how much does it overlap between audiences?

There are often cases where the internal and external users require almost the same functionality. In other cases, there may be very little overlap, but there is potential of internal tools evolving to be customer facing as well. For example, we created a sales enablement calculator for a technology-industry client that was initially only being used by their salespeople. The calculator proved to be so user friendly that it was ultimately released as a public tool for their prospective customers. Other examples of features that might overlap between user bases are:

• Product information
• Pricing databases
• Documentation 
• Order forms
• Video libraries
• Calculators

3) Will a bulk of the app functionality be hidden behind a login?

The more app functionality you secure with only a part of your user base accessing it, the less value a combined application has. Security concerns are also a factor when bundling access to proprietary information in a public mobile app. Particularly, if you would typically limit access to specific information through a VPN or other security methods that are not available in a public mobile app.

4) Do you have a Mobile Device Management system and if so, which audience segments use it?

Using a Mobile Device Management (MDM) platform may be the best way to distribute your mobile app to internal employees, but acquiring and rolling out such a system requires time and effort. If your company does not currently have an MDM, implementing it as a solution may not be feasible in the short-term. If you do have an MDM, consider which of your target audiences use it, and how does that overlap with the functionality requirements?

5) What is the application roadmap?

As your application’s functionality grows and evolves, the factors that determine the best solution will likely also shift. Having a clearly defined roadmap is vital to ensuring that your decisions today will still be sound in 12 – 24 months. For example, you might plan on adding features to your app in the future that change who the target audience is. Make sure to take these considerations into account when deciding on how to design and distribute your application.

Managing the mobile UX for multiple audiences

Based on the implemented functionality in the application, designing a cohesive user experience to serve multiple audiences can provide a challenge. If the user experience for one of the user groups is no longer effective within the larger application, it may be advantageous to split the functionality for that group into a separate app.

Will the user experience that is split between public information and proprietary information serve the internal users well? This may require a sales person to access a few different locations in the app to obtain all of the information they require. They might be better served with a dedicated user experience in a separate app that is geared specifically towards their needs as opposed to piggybacking on the public app.

Deployment options: Direct installs, testing suites, MDMs, and App Stores

There are several ways to install a mobile app on devices. The optimal method may vary depending on the use case, and your target audience. Here are the most common options:

• Direct installation: If you are only deploying to a very limited number of Android devices, doing a direct installation is an easy option. The caveats are that the device user needs to manually change a setting in the operating system prior to this being possible, and that app updates need to be manually performed by reinstalling a newer version of the app. We see this option mostly used with installations that focus on very few devices, such as kiosks. Direct installs are also possible on iOS devices, but require the device to be plugged into a developer’s workstation.
• Testing suites: If you are deploying to a limited number of devices (think dozens, not hundreds), employing a testing suite could be a sound option. These software suites will typically allow users to install the app via a link in an email. Bitrise allows deploying apps for review on both iOS and Android devices. Testflight is a feature of the Apple App Store and allows up to 10,000 private users, but the app will need to be approved by Apple prior to being distributed.
• Mobile Device Management (MDM): Most commonly used in the enterprise space, MDMs provide a private app store to internal business users. MDMs, such as AirWatch, come with lots of features and a per-device subscription fee. MDMs can be great for internal business users, but are less than ideal for external users. Installing an MDM typically relinquishes some control over your device.
• App Stores: Deploying your application to Google Play or the Apple App Store provides the easiest way for your users to get access to your application. All other options typically require some user training, but everyone knows how to download an app from an app store.

Conclusion

As you can see, there are a lot of variables to take into consideration when determining your mobile app strategy. Nowadays internal and external users often have the same expectations for ease-of-use when interacting with a mobile app, so it can be tempting to combine the experiences into a single app. Hopefully the information in this article helps you find the best approach for your business’ use case. If you are ready to move into the solutions architecture for your app, you might also be interested in how to build a digital product platform for scale.