I'm a designer and my company has a single app that serves two different types of user.

One group is the general public, who uses the app to navigate big events (e.g. annual user group meeting sessions, exhibitors, connect with other attendees).

The second group is staff. They primarily access the profiles created by general users. They can add details, e.g. notes about conversations with them.

We have been asked to provide more 'staff' functionality. The app is getting quite large. I remember hearing that an app shouldn't be too "deep" (I think at an NNG course probably 2 yrs ago)... I think we can avoid a drill-down nightmare, but am worried about how large the footprint is getting.

Is there a rule of thumb for when to create a separate app, vs. wedging a lot of functionality into one? And/or can someone point me to a resource?

  • Awhile back I had heard it was acceptable to create distinct, nimble apps - but in the time that has passed, I wonder if the effort to maintain multiple apps outweighs the benefits?
    – Nancy
    Commented Apr 10, 2013 at 17:52

4 Answers 4


One question to ask yourself (or your personas) is, given 2 distinct apps, how often would a user of (either app) need to switch to the other app?

If the answer is never, then 2 distinct apps is advantageous because each app can be better tailored to its audience. If the answer is infrequently, then you need to consider the cost of the user switching between apps. If the answer is frequently then maybe having a single app is best.

  • Thanks, that is a good way to approach this. In our case, it's infrequently... and the folks switching are staff (rather than general consumers) so they are sort of a captive audience that is willing to put a bit more effort in.
    – Nancy
    Commented Apr 16, 2013 at 13:30

Our company is trying to do the reverse right now... we have multiple apps and we realized we're better off consolidating all of them into one because the same set of users will likely access most of the functionality. There's no sense in them managing several apps.

My suggestion would be to assess usage based on the two user types. How often would the staff need access to the public facing side of the app? Under what context would they need to access it?

If in a single task flow, staff need to access both areas... or if they frequently access both then keeping it together will reduce app switching friction.

If the things staff needs is very distinct and separate then what the public will use, then by all means split them.

  • Thanks for your response! You have a good point. To my knowledge, staff uses this for very different purposes. Initially we kept everything together because we were starting small and learning.
    – Nancy
    Commented Apr 10, 2013 at 17:35

Current thinking where I work is that separate apps are more easily maintained and scale better (in terms of user base and available functionality). If every service we offer would be in a single app, even minor updates would carry major risk. This many-apps approach allows us to update one service, even move it to a different platform, while not touching the others.

Of course there are some requirements. You may need to provide some features from app A in app B. If so, you'll need a framework of some kind so you don't duplicate the functionality, but have it shared between the apps, re-using a single codebase. If they're web apps you need to have something in place that makes switching from one app to another seamless. Eg. you could have a central user-profile/authentication service (like they use here at StackExchange).

When to split is a tough question though, I'm not sure I know the recipe. You may get to the point where, like in your situation, the functionality required for certain use cases deviate to a point that it becomes easy to define the proper split. Some examples: I don't need an RSS reader in my email client or web browser (MS used to think I did though), I don't need markup in my text editor, I don't need multi-page layouts in my Photoshop.

Keep your apps lean, but make sure the workflows you offer can be completed in one application or that you make a logical split and support that with some integration features (eg. 'placing' Photoshop files in an Indesign document).

  • Thank you for another perspective. Making a small change to a mega-app is something we had not considered. We'd rather not re-test our entire footprint each time a tweak is needed. You also added clarity to the "switching apps" concern - it's helpful to think of this in terms of completing a task.
    – Nancy
    Commented Apr 16, 2013 at 13:33

If you can funnel the users into the two groups at the beginning of the app, at launch the user selects "staff"/"non-staff" options, then in essence you are creating two paths rather than a single deep hierarchy.

You can add similar amount of functionalities for both general and staff users and still have only half the depth in hierarchy since those are parallel. For a staff user he does not see the general functionalities which are not useful for him and vice versa.

  • Thanks, I appreciate your idea. One of our concerns is how large the app will be to download, with multiple paths. Awhile back I had heard it was acceptable to create distinct, nimble apps - but in the time that has passed, I wonder if the effort to maintain multiple apps outweighs the benefits?
    – Nancy
    Commented Apr 10, 2013 at 17:36
  • If you want to reduce app size, you can go bold and use a cloud service, wherein all the calculations and functions reside on your server and only the user data is on their device. On a less overhaulin' note, is your app graphics heavy or something? Since, otherwise the app size shouldn't inflate to the point that it is a problem for users to download/install.
    – rk.
    Commented Apr 10, 2013 at 18:17
  • The app we have today is not especially graphics-heavy. The portion that's used by general consumers has more visuals/images but the staff portion is Plain Jane. Thanks for the response!!
    – Nancy
    Commented Apr 16, 2013 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.