You could keep the ability to go down (through) the list, but remove the previous, and allow only back to list.
By scoping navigation moving sequentially, I'm assuming your goal is to allow editing at a fairly brisk pace.
If you remove the
prev and replace it with the
< back to list, items that have been activated will be removed from the list. This reinforces the applications integrity. You give the user a little less flexibility, but the results of their actions are obvious once they: A) Return to the list or B) Cancel their edits
Group similar functions in proximity: navigation
< back to list and
next > are both elements that related to traversing the list, I moved them up to the top.
Since you may abandon your edits, I added a Cancel link. It's a well known pattern and provides a familiar 'escape' back to the list.
One point of potential confusion might be if a user saves two items in a row, then goes to abandon a change. Would they think that
Cancel means the previous two Saves will be undone?
I would test this with users if you feel it's useful to have.
You could just;
- place screens 2 and 3 in tabs, instead of showing next / prev
- "back to list" button more natural postion is top left