2

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?

Combined login option 1

enter image description here

2
  • What software have you used to create the wireframe?
    – Adriano
    Nov 14, 2019 at 4:57
  • 1
    Hi @Adriano, this was made in Balsamiq and uploaded here....even though there's an embedded Balsamiq option on UXSE ha
    – jukesyukes
    Nov 14, 2019 at 17:29

2 Answers 2

1

Consider these statements about all web logins, not just your case:

  1. Any app must handle the case where a session has expired (or never existed) and redirect the user to a login page.
  2. It is desirable to, after login, redirect the user back to the page they were trying to reach.

If you implement these, then you do not need a special user interface for multiple applications. Every login can be in the context of trying to access one of your apps, and can then redirect to (whichever page of) that app.

This does impose the requirement that you do not have a “generic” login URL that is linked anywhere. But, in my opinion, this is good user interface design — since you say the apps are independent without any common pages, it makes sense that each one, if it has an explicit "login" link at all, it is "login to this app".

And if your login handler somehow gets a successful login without a redirect URL, it can just say "You're logged in, but we didn't have a destination." That page can, if it seems worthwhile, have a list of links to the apps they might want — but you don't need to expect that seeing this list is the normal workflow.

1
  • After some more discussion with our devs about future login server plans, this is generally going to be the case for most of ours users, given lack of a centralized login service. So, it will be rare that our users may be in a situation where they've a chance to choose their destination - though it may occur as an edge case.
    – jukesyukes
    Nov 20, 2019 at 17:38
1

The second proposal (a single sign in screen with a dropdown selection for application) is one that I've seen in a couple of places, including my own workplace. We have an SSO (single sign-on) web page, on which there is a dropdown of various internal applications and systems. It's easy to scale to accommodate more applications in future. The 'set as default' option is a nice addition.

1
  • Thanks, Matt. Is there a generalizable name for this pattern that you're aware of? Our TPM had a similar system at his previous place of employment, so it's familiar enough it may get traction. We are lucky in that users do not switch roles after logging in, because the permissions are additive. So we don't need to worry about a second context switch.
    – jukesyukes
    Nov 14, 2019 at 17:47

Your Answer

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

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