I have a mobile app that employs both "multi-page" template and "single page" template. Specifically there is a “My Profile” functionality that is split across multiple pages. The rest of the application is using "single page" template.


“My Profile” is set up to give users a list of categories of settings.

My profile, main page

Then when user taps one of those, it takes user to a subsection with details for that category.

My profile, account page


Now an interesting question is when to save the changes for each subsection of My Profile. We do not want to make users to navigate back up to the top-level screen and click Submit. We also do not want a Submit or Save button on every page.

The approach I am contemplating:

No "Submit" button. "Save" happens automatically when end user completely leaves this multipage set. Specifically, it composes of 2 facets:

  1. When user navigates within the subscreens, browser manages the data as the user navigates and makes changes.

  2. Now we detect when user leaves “My Profile” completely, then user edits would be saved automatically (without end user clicking a “Submit” button anywhere)

Does this sound reasonable? Is there a better way to accomplish these same goals?

  • Welcome to UX.SE! At the core of this question, there is a UX issue, but you should know that, as it is currently written, it will likely be closed as asking about implementation. Indeed, there are many implementation details that distract from the UX issue at hand. If you are able to edit out much of the detail concerning your specific implementation, the question can likely be made appropriate for this site. Commented Apr 3, 2018 at 18:41
  • Great edit! I've made just a couple more tweaks for you. Feel free to fix anything I might have clarified incorrectly. Commented Apr 3, 2018 at 19:02
  • Your tweaks are awesome. Thanks so much for your help!
    – riceball
    Commented Apr 3, 2018 at 19:03

1 Answer 1


Do NOT link your users' save function to such an unconventional trigger, such as navigating away from a page. This betrays the principle of visibility—the idea of letting the user know what the system is doing. If your save feature is "hidden" like this, a user will never know when the page saves—or worse yet, she will have made changes that weren't actually saved because she never left the page.

If you would like to avoid having a Save button on every page (which should be fine), you can implement an autosave feature that notifies the user when changes are saved. This can be done subtly, such as a transient notification next to the field the user has modified.

  • Thanks for the quick replay, maxathousand. What you said makes a lot of sense. Does your approach imply that UI would send each change to the server when the change is made -- for example, if there are 5 fields, and user edits one by one, then 5 server round trip would be made?
    – riceball
    Commented Apr 3, 2018 at 18:51
  • The most "eager" of implementations would do it that way, yes. If you'd like to try and debounce your calls, you might be able to catch a few updates in the same call, so you could reduce the total number. However, I think a fitting optimization at this point would be to try and reduce the size of your save packets so that multiple round trip calls wouldn't be as burdensome. For example, instead of sending an entire "My Profile object" whenever a user makes a change, perhaps you could just send updates on the field(s) that have actually been updated. More frequent calls, but much smaller. Commented Apr 3, 2018 at 19:06
  • Thanks for engaging in the discussion. Much appreciated. What you said does make sense for a brand new project. In our case, it happens to be a mature web product with backend in place which take an entire “My Profile” packet. Having a “save” button on each page maybe is not that bad. I have only 4 pages. My concern was navigation slowness. From UX perspective, would you have any concerns on “save” button in each page?
    – riceball
    Commented Apr 3, 2018 at 19:15
  • My pleasure! Ah, yeah, existing architecture can often limit your choices. I'd just go ahead and add a "Save" or "Done" button in your subsections. That way, you'd only have a few calls to your server, while at the same time exposing to the user that there is an explicit action to be taken to submit their changes. There is often an explicit action to save changes to one's settings, so I wouldn't think there'd be any issues with that design, but as always, you should try and run the design by a couple people to ensure you're not the only one who thinks it's great! Commented Apr 3, 2018 at 19:25
  • Thanks so much, maxathousand. Everything you said makes sense. One more note --volunteers like you make this community so much nicer.
    – riceball
    Commented Apr 3, 2018 at 19:31

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.