DonnaM » Blog Archive » To save or not to save

To save or not to save

I’ve been having a dilemma this week.

A few weeks ago I advised a developer of a browser-based application to remove all of the ‘save’ buttons from it. After all, the computer was completely capable of saving all by itself, so why should we force the users to do this unneccessary step (and they would have to do it frequently).

At a demo/play with the system (at which I wasn’t present, so I don’t completely trust the analysis) the feedback was that the users weren’t sure what to do next, and whether their info was being saved.

So, the dillemma is – should we make users press irrelevant buttons simply because they have been doing it for years, or should we try something that will actually make life easier in the long run (and do you think I could write a more loaded question than that)…

11 Responses to “To save or not to save”

  1. Gunnar Langemark Says:

    When dealing with a web based system, my experience is that users will want some sort of indication of “state” in the system. That is provided by user actions – and/or by system feedback.
    So I would say: Stick with the unnescessary submit buttons. They make users feel comfortable that what they are doing is actually the right thing.
    Eventually you may be able to remove the buttons – as new generations of users get used to other devices and to more stable and responsive systems.
    Right now we are dealing with systems and users not really up to the task. This means: make every step clear to the user!

    Just my opinion

  2. Joshua Kaufman Says:

    I agree with Gunnar’s opinion. Users like to know where their data went. Even if the system saves information all by itself, I don’t know of any other web-based app that does that. I’m sure I would also be uncomfortable with system like that. When I post this comment, I hit POST and know that it’s saved. When I send email, I hit SEND and know that it’s saved. That’s just how 99% of web-based apps work.

    Your question aside for the moment, I’m curious how it works if it doesn’t have save buttons. What’s going on in the background that saves the information? Maybe if the system could communicate to users that their information is actively being saved, then there wouldn’t be a need for the save buttons after all.

  3. andrew hedges Says:

    I agree with Gunnar’s observation that users feel more comfortable knowing the state of the system, but not with his conclusion that you should keep the submit buttons.

    I would have to see how the app works to say for sure, but my guess is that it is sufficient to display state information in a visible place above the fold (e.g., “Your information has been saved.”) without making them take unnecessary steps.

    In the long run your users will thank you.

    The experience to which I relate this is when I first started using the Palm OS. At first, it was a little disconcerting to me that I didn’t have to hit a save button. But, now that I’m used to it, I don’t miss it at all!

  4. James Robertson Says:

    As per others, I’ve implemented software that has a Save button that is completely needless. The system automatically saves the data in a sensible way, but the Save button was added to make the users feel more comfortable…

  5. Donna Says:

    Thanks for the interesting comments.

    As always, it needs a bit more detail…

    The app is a thought-inducing one where users indicate their skills & preferences for something. The part in question involves reading sentences, ticking boxes and rating from a drop down. The data doesn’t need to be sent anywhere – mostly it is used for personal reflection.

    Now there are heaps (maybe 2000) sentences to read, tick and rate. They are broken up into little categorised chunks, with 5-15 sentences per page. Info is saved when they move to the next page. Including a save button would mean they had to press it at the end of every page (so that’s heaps of saving…). Users can do as little or as much as they like in a sitting and can change the info at any time.

    So I’m still happy with the solution, but am thinking about how I can make it a little bit clearer that it saves as they go…

  6. Anonymous Says:

    I agree with Andrew Hedges: Give proper feedback. Do not add unnecessary interaction. (Sounds like interaction design 101 to me, but I guess education is indeed getting worse over the years.)

    If you as a designer are not comfortable with that, then go with the web standard of the extra interaction. When you don’t know how to better than the standards, stick with the standards. (Also from interaction design 101.)

  7. Ron Zeno Says:

    (Doh! That last comment was from me. Guess the “Remember info?” checkbox didn’t.)

  8. Chad Lundgren Says:

    I did some usability on a project with a similar multi-screen data entry. My take was that there should be two buttons: Save and Continue (or perhaps “Next>” ) and Save for Later. The only difference between the two was that the Save for Later went to another page: either the main page, or a page that said, your data has been saved, you may come back later or continue.

  9. PeterV Says:

    How about a “SAVE & CONTINUE =>” button? (If I understand your problem correctly)

    Oh, I just read Chad’s advice now. Even better! Add the “Save for later” button as well. :)

  10. NicS Says:

    Neilsen is big on using the conventions that people have already imbedded in them. And this currently includes a ‘please take a snapshot of what I have done now’ feature; normally put in as save.

    It will be interesting to see how this changes over time.

    As always, its best not to fight the users on this one. Even if it makes them feel more at ease and they never touch the dang thing. Its gives them a metaphorical foothold.

    – slightly off topic
    I must admit my personal (not to have an entire HCI theory based on it) experience is that I disklike even having my menu bar stripped away in a browser window; which has been described as good design as there is more ‘content realestate’ and less to confuse. BUT I am a creature of habit and have been using graphical browsers since Mosaic. So I have had the borwser metaphor firmly implanted for 9 years and don;t like anyone ‘taking my lolly away’.

    Similarly I expect (personal user feeling)anything substantial to be savable when browsing or using. Be this required or not.

    Enough rant. Would be interested to hear how this conundrum goes with further analysis and testing.

  11. Donna Maurer Says:

    There is a slight difference here – everything is saved. It is just that the user doesn’t have to take an explicit action to do so.

    I’ve been thinking about it this week, and think that the problem is not that users can’t save, but that I haven’t made the interface communicate the status and give good feedback. There’s the trick…