I'm trying to make an area where users view/edit the info for their customers less confusing.

The current arrangement (which I've inherited) is below. The user clicks an "edit" button and the fields across the 3 different settings tabs then become editable. The user must use the "save" button which saves the changes made in all 3 tabs.

The main problem is users forgetting to click "save" because of the button's position at the top right - but I think moving it within the tabs will only add to the confusion.

The question is, should I get rid of having "edit" mode enabled across multiple tabs in the first place? Is it in any way a standard practice? I'm struggling to really see its advantages.

enter image description here


4 Answers 4


If you have buttons outside of the tabs then it infers that the changes being made are global to that screen rather than to the content of the tabs. If selecting 'Edit' puts the whole page (tabs and all) into Edit mode then that makes sense from a logical point of view, but it does mean you need to provide feedback to the user that they are editing the whole thing rather than using it.

Changing the text on the Edit button to be Save probably isn't enough feedback to the user that they are in a different state. It's the same length word in the same place on the screen so people aren't going to notice it - particularly as they've just pressed the Edit button so have no need to look at that button again because they've already used it.

I suggest keeping a similar layout to the one you have currently but adding a new Save Changes button elsewhere on the screen. Perhaps next to the Edit one. I'd also add an Save Changes button to each of the tab panels themselves so that the user can save the state of each tab as they go. (Especially because once they change tab they can't see the changes that they've made on the previous screen).

Finally, I'd add a prompt in when the user tries to leave the screen reminding them that they've not saved and if they move on then their changes will be lost. That should help people should they want to save their changes.

Either that, or you could just implement Live Save functionality - so that as soon as the user selects Edit then any changes to fields they make will be automatically saved once they tab out of the field, or that changes are saved periodically (every 30 seconds or so) which would negate the need for a separate save button anyway. (However you then have the issue of what to do if the user has chosen to edit by mistake and doesn't want to save the edits they've made.(

  • Sorry, pressed enter without meaning to...some bad UX right here. Thanks for the suggestions. We definitely need to add a prompt as well. Live save was my first proposal but is unfortunately unfeasible atm. Yeah, in the current design there are no cues that the button has changed. Your idea about adding "save changes" buttons - if I introduce the idea that each tab is saved separately, won't that confuse users when they move from one tab to another and see that their changes are still in place, even though they haven't yet saved?
    – djeli
    Feb 28, 2014 at 14:48
  • @djeli: This is some of the issues you have when you have when you can set the user properties to a global edit state. My main concern was that because they are tabs the user isn't going to be able to see the changes they've recently made when they switch tabs so you'd need to give them the ability to 'store' the changes they've made as they switch tabs. This can either be a button on the tab itself, and / or as a prompt when they choose to switch tabs 'do you want to save these entries' for instance.
    – JonW
    Feb 28, 2014 at 15:16

I'd think about how frequently users will be editing information across multiple tabs in one session. Will a bunch of information change at once for a given customer? If it will, then the edit button should be outside the tabs.

But if the common use case is just one or two fields changes - a person's last name changes, or an address changes maybe - then put the edit button inside the tab. Or, even consider switching to an inline editing pattern so users can just change one field at a time. Then you don't need to worry about having a mass context switch at all.

You can make any of these work - editing all the tabs, one tab, or just one field. But you should pick which one to use based on what your users need!

  • Imo, in-line editing would be fine here but unfortunately not currently feasible for this project. In this case, I don't think mass editing across tabs is that valuable to our users and definitely not worth the confusion it's causing! Thanks for the tips :)
    – djeli
    Feb 28, 2014 at 14:51
  • I like this suggestion. Editing individual fields removes the issues that are present with setting the whole screen to Edit mode.
    – JonW
    Feb 28, 2014 at 15:13
  • So do I, but unfortunately the engineers have another view!
    – djeli
    Feb 28, 2014 at 15:20

Mark D's suggestion to "think about how frequently users will be editing information across multiple tabs" is a really good one.

However, having worked in a place where my ability to actually push appropriate changes was limited, I can empathize with poor inherited decisions.

Not sure what all your constraints are. Provided a couple potential options to get you thinking of alternatives.


download bmml source – Wireframes created with Balsamiq Mockups


I assume only admins will get to see this screen.

Yes, having the edit button at the top level will lead the users think that you can also edit the history, which probably is something that should be auto-generated.

An interface like this should have Details, Edit, Contacts, and History tabs.

Details Tab. Shows all the information. Will have an edit button which will switch to the edit tab. This tab should be the left-most and the first one open on page/window load.

Edit Tab. Shows all the input elements where you can change info. This will have a save button labeled "Update".

Technically, the screen is always in edit mode, but don't tell the user this. If they want to edit, they'll just click the edit tab.

When the page first loads when you're about to create a record, disable the Details Tab. Programmatically open the "Edit" tab, which should be labeled "Create" at this point. The commit button should be labeled "Save". When the user clicks the Save button, enable all the tabs and relabel that "Create" tab to Edit, and that Save button to Update.

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.