Im working on a mobile flow that allows a user to deeplink to separate jobs within the same app via toast messages and/or notifications from a notification centre.

Im struggling with getting back to the original start location.

Example (see diagram):

  1. User drills in to Job 1 and lands at Stuff 1.1 from homepage
  2. Gets a toast notification of things happening in Stuff 2.1 in Job 2.
  3. Taps toast and goes to visit Stuff 2.1
  4. Note: User is leaving Job 1, and now going into Job 2
  5. User is now in the Job 2 > Stuff 2.1 flow
  6. How does the user get back to the origin, Stuff 1.1?



When going from stuff 1.1 to stuff 2.1. If hit the back arrow on stuff 2.1, it should take me to Job 2. This seems correct from an IA, flow point of view because I have now plopped my user in a page of the flow.

I am perplexed with how to get back the the original screen from a different part of the app after selecting to go view that data.

The 2 options I have thought of so far are:

  • Hijack the Stuff 2.1 back button and have that be back to Stuff 1.1 and not the Job 2 page.
  • Design a floating back button to get you back to the original location, leaves user free to view job 2 pages and does not hijack or disrupt regular page flow
  • 1
    Maybe an interesting read from the Android navigation principles: developer.android.com/guide/navigation/navigation-principles
    – Big_Chair
    Jan 23, 2020 at 15:49
  • Thanks for the link. The Android "hardware" button is really a good back anchor. I will think of utilizing that for the android side of the native app.
    – Destructo
    Jan 23, 2020 at 20:15
  • 1
    Toast isn't a clickable mechanism, unless "hacking" it to be...but then who would expect a Toast to be clickable? You would have a problem there. I believe you should be using the Snackbar mechanism in place of Toast here.
    – straya
    Jan 24, 2020 at 2:06

1 Answer 1


On Android, the arrow at the top left (or right if in RTL mode) of the screen is not a back button, rather it is an Up button (typically known as the Up affordance). It should work differently to the Back button (which should always be available either as a hardware button or software button provided by the OS).

To achieve your desired effect while obeying the navigational principles of Android, simply leverage the Back button to take the User back to the previous screen they were on. Meanwhile, the Up button/affordance should always take the User back to the top-level of the section they are currently in. So, as per your scenario, upon landing deep in Job 2, the User can:

  • Press Back button to go back to the last screen they were on (i.e. deep in Job 1).
  • Press the Up button/affordance to go to the top-level of Job 2.

When deep-linking into an app from outside, it is best practice to have the Back button exit the app (taking the User back to the app that they navigated into yours from). Apps that disobey that are effectively hijacking some other app's session, and suck for doing that (e.g. Twitter). The Up button/affordance, however, provides a means for the User to intentionally stay within the deep-linked-to app.

iOS doesn't have such depth in UI/UX navigation patterns, the only means of going back is the top-left arrow and that should obey the backstack (i.e. in this scenario taking User back to deep in Job 1.1, doing otherwise would be hijacking the backstack). So your idea to provide an extra means of navigating could work well, but I suggest it takes the User to the top-level of Job 2 rather than the last screen on the backstack.

  • Thank you for your comments. On the android side, it makes alot of sense to leverage the up button. Now to figure it out for iOS. Thanks!
    – Destructo
    Jan 27, 2020 at 14:42

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.