Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 530

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h02/mnt/52932/domains/ on line 623 » Designing Against The Fear of Losing Assets

nerd nouveau

Designing Against The Fear of Losing Assets

Recently, after watching this excellent Scandinavian comedy skit on YouTube, I’ve been discussing about one of the references in it with a friend: The novice user’s fear of losing data.

In fact, we’re all afraid of losing our data. After all, that’s why we back up our data religiously (you do backup your data, right?). But what we were addressing in our discussion is not the fear of losing data through a hard drive failure or another technical issue, but the fear of losing it through one’s own inexperience or maybe even stupidity. It’s the fear of clicking the wrong button at the wrong time. But from our perspective as software designers, how can we alleviate this fear?

First, we need to understand where this fear is coming from. Way too often, we’re tempted to dismiss it as being rooted in the inexperience with a certain piece of software, like your stereotypical mom being afraid that her perfectly crafted Word document is lost as soon as the window closes. On a closer look, however, we come to the realization that this fear is neither constrained to software usage alone, nor solely caused by inexperience.

  • There’s a general fear of loss due to “usage” errors: For example, much like some of my friends were initially afraid to lose their precious holiday snapshots after an iPhoto import because they are not specifically prompted to save them, I was afraid to lose money during my first stock purchase (through hidden fees, buying the wrong stock due to a wrong ticker symbol, accidentally sending a market order instead of a limit order, etc…). Similarly, we’re afraid to ditch our potentially safe day-jobs for an entrepreneurial venture because we’re afraid to lose money in the long run. Or we’re afraid to “lose” a beloved gadget due to a wrong button pressed (for example, bricking it during a firmware upgrade).
  • The fear does not come from inexperience, but from the mental model of the process: While a novice user has a black-box mental model of a piece of software and thusly doesn’t have a concept of how said software is protecting their data, an experienced user might suffer from the same fear just because they know how the software is handling the data: For example, a novice iPhoto user might be afraid to lose their photo descriptions because they have absolutely no idea of how iPhoto stores and protects them, whereas an experienced/geeky user might have exactly the same fear because they know that iPhoto uses a flat file for the archive information that could easily get corrupted, hence wiping out all meta-data.
  • Users are more afraid of losing data the more important it is: Sounds like a no-brainer: We’re more afraid to lose our almost-finished PhD thesis than the 5-line joke email we want to send to a buddy.
  • Data has different personal value for different people: It’s hard to quantify the “importance” of a piece of data from a particular user’s point of view. For example, while some people religiously save their old email, just for reference, but also for personal value (sometimes, it’s nice to revisit a long thread of emails that led to a beautiful relationship), other people couldn’t care less about their old email and are possibly even deleting it manually from time to time. This concept can be extended to any type of data.
  • Users are afraid to lose data because of their own mistakes, but will ultimately blame it on the software:
  • This is important to developers. While we initially fear to lose data due to our own mistakes, we blame it on the software as soon as it actually happens. Example: Tiger’s Safari 2 browser has the annoying “feature” of closing a window immediately when the red “close” button is clicked, no matter how many tabs are open in that window. Consequently, I’m afraid to accidentally click this button at the wrong time (my fault), but when it actually happens, my mood swings from “my fault” to “Safari’s fault” (why did it not warn me before closing the window!).

  • The more we trust the software system, the less we are afraid to lose data: Consequently, let’s abandon the notion of “experience” for “trust”. I’m not afraid to lose my photos when using iPhoto because I trust this particular piece of software: I have never had any trouble with it before, it comes from a reputable developer, it’s known to be well-tested, etc… Conversely, I do not trust MS Word (and thusly don’t use it). I’ve had gazillions of issues with it that have destroyed my trust.

But, considering that we are generally prone to be afraid of loss, how can we design software to minimize the fear of losing our data? The point is, we can’t. There are too many potential risks to our data, those that we are aware of (depending on our level of expertise) and those we are not. Then, there’s also the uncertainty of not knowing about a potential reason for data loss. We just can’t remove all the risks and build trust into data safety that does away with the fear of data loss: Everybody loses data once in a while, and that experience can be traumatizing, even if backups are readily available (we’re prone to getting tangled up in a “what-if” scenario about not having had those, or them being corrupted).

What we can do, however, is acknowledging this fear and trying to assure the user that we (as the provider of the software) are doing everything in our range of possibilities to keep their data safe, giving them the warm feeling that even if they or their computer mess up, we’re there to protect their data as well as we can. The point being that we’re aiming to reduce the fear, even though we cannot guarantee absolute safety for the data.

  • Take the fear seriously: At least some users are afraid to lose data, so it’s a good idea to acknowledge this. Mention various backup and redundancy strategies employed by your software in the help file or on the accompanying website. Don’t dismiss the fear in a patronizing way (”Your assets in our software are as safe as every other file on your computer”). At least make sure that you have thought about the problem during the software creation process and convey that to your users. Sometimes, users just wonder if the developer has thought about a certain usage scenario. If they know you have, they feel safer.
  • Don’t treat your data as being unimportant: Even if you’re just saving a command history or other data that you would personally consider to be ephemeral, it might be important to some users. Thusly, treat such data as being “important”, too.
  • Build trust: Even a simple cosmetic bug in your application reduces the level of trust a user has in your software, and ultimately in its data safety. For example, if your Mac application suffers from the “spinning beachball” often, this reduces trust. Even something as simple as a typo in a dialog window reduces the trust, as your software appears to be written with little diligence.
  • Don’t describe horror scenarios: It is not your concern to teach your users about hard disk crashes or exploding laptops. If you educate your users about the importance of backing up their data, do so by informing them of the positive effects of backups, rather than threatening them with horror scenarios: Say “A backup is useful to restore a previous copy of your data if you want to go back to an earlier state or in the case of a computer malfunction” rather than “Computers often suffer from dying hard disks, exploding batteries and other disastrous malfunctions. Make sure you have a backup ready or you will be screwed”.
  • If your software doesn’t have an explicit “Save” function, tell your users: For example, a user not familiar with the iTunes-esque “Library” concept may wonder how to save their photos after an import into iPhoto. They will be afraid to close the window until they’ve made sure that their photos are really saved. The thing is: There is no “Save” button in iPhoto. However, what it could do is informing the user about the “Library” concept, after the first import, for example, and that their data is automatically saved. Without such information, novice users might be scared to lose their photos when they close the application.
  • Make sure that there is a clear indication that data is saved: On the Mac, most Cocoa apps indicate a “dirty” document (i.e. a document with unsaved changes) by displaying a dot in the red “close” button. This enables a user to see at a glance wether their data is saved to disk and it’s ok to terminate the application, even through a Force-Quit a.k.a. kill -9. Employ a similar tactic. The goal is to never leave the user in the unclear wether their data is saved or not.
  • Be honest about the dangers: If you continually ensure your users that their data is perfectly safe with your application, they will only become suspicious. They know that this is not true. They are aware of the dangers of hardware failures or accidentally deleting important data. Thusly, rather than neglecting the problem, be open about it. Tell them that your software is doing everything to protect their data, but it’s still a good idea to make backups. Make it clear how to save data and how to restore it later. Don’t bother them with technical details, just tell them what they can do to keep their data as safe as possible. Sometimes, acknowledging that a fear is real, but offering tips on how to alleviate it, is way better than arguing against the fear itself.
  • Be extra-careful when modifying another application’s data: It can often be observed that users are especially afraid about data loss in this scenario. For example, while they might feel pretty calm about iTunes not messing up their library, they might feel a lot less calm about your program (about which they know little) modifying their carefully-crafed music library. Make backups of the original data before accessing it and explain the process of restoring this backup before making the changes. If the users are aware that they can undo the changes, they are more likely to click the “Do it” button. Remember, in this case, your software is competing in terms of trust against another software that the user is much more familiar with. Kick-start the trust in your software by ensuring that the modifications do not need to be permanent! Messing up another software’s data is, from a user’s perspective, a much bigger faux-pas than messing up your own data. Compare it to this: If you buy a DVD player and it breaks, that sucks, but if it blows up your brand-new HD LCD TV-set, that’s a whole new dimension of suck.
  • Lastly, acknowledge user feedback concerning data loss: Especially do so if it’s public feedback. Contact the given user, apologize (don’t blame it on them, as they will not only be more afraid of using your software again since they’re apparently not capable of doing so, but they might get angry, too) and inquire about how they experienced the problem and during which action(s) it happened. At the same time, inform other users that you are working on the problem, too. This increases trust in your software. Of course, don’t just babble, actually do look into the problem! Remember, one feedback item about data loss may instill fear into a whole slew of other potential users!

Most importantly, you need to acknowledge that most applications aren’t about the application, but about the data your users create, process and store with them. All your cool features don’t matter if their data is lost. The software is just the tool, but the data is the asset.


Hi, how are you? My name is Georg Kaindl, and I'm a twenty-something from Vienna, Austria. During the day, I'm a CS student at the Vienna University of Technology, but at night, I turn into an independent software developer for the Macintosh platform, social nerd, lazy entrepreneur and intuitive researcher.

I like to write about everything that matters to considerate technology enthusiasts, but humbly retain the right to go off-topic from time to time.

My posts are licensed under a Creative Commons Attribution 3.0 License.


You can reach me by email if you have something to say that's not related to a blog post or that you don't want to have publicly available as a comment to a post.

However, you'll have to prove that you are human! Even though I personally like robots very much, I'm less of fan of SPAM. It's just a simple riddle to solve, but a SPAM bot won't cut it!

To get my email address, take the word before the .com in my domain name first (Hint: The word you are looking for starts with a "g" and ends with an "l"). Next, simply attach to this word.

Boom, there's my email address. Simple, isn't it?

Powered by WordPress

Comments RSS

Entries RSS