Handling multiple applications behind one login
UX community -
This question concerns handling user choice of destination during/after login.
Let's say we have one account that can serve multiple apps, A, B, and C. Users of one app are not necessarily users of the others. However, there may be some overlap between app A and app C, and app A and app B.
There is no global navigation for these apps once logged in, no main dashboard, and the UIs of A are quite different from B and C (A is a legacy service). So, currently, a user would log in to A and have to hunt for a folder to access C, which is a new offering.
How would you approach directing users to the correct destination upon login? Ideally, App C users would never need to access App A (though there are many knobs admins could turn in A that could alter app C)
The way I see it now, there are a couple of approaches.
Each service has its own dedicated login page, and they never touch each other. Users of multiple apps would need to use two different login pages, or traverse the (possibly) deep folder structure of A to get to app C.
A user choice is offered upon login (if they have multiple apps access) to which destination they'd like to go. It's almost like choosing a role for their work, but of course, we also have the designation of in app roles as well. The two wireframes below show some options for this.
Our ideal solution would scale to other potential apps in the future, with little needed in the way of design change. The services should end up feeling connected as part of a suite. Little in the way of hard requirements have been enumerated yet, so I'm using this as an opportunity to have some conversations around better understanding of our goals as a group.
My research has mostly turned up offering multiple login methods (single sign on, etc) but not multiple login destinations or app choices. Are there good examples of this type of login pattern? Other considerations I may be missing? Am I overthinking this?
