Brandon Mechtley

If all else fails, users need recourse for unwanted use and distribution of their information. Along with this, users always need accces to their information and how it was used.

In situations of security breaches, for example, there should be some recourse someone can take that is specific to security breaches to clean up any unwanted damages. Low level design decisions such as keeping detailed records of changes to a user’s information (analogous to version history) can help designers and support staff build these mechanisms into a tool’s framework. Although issues of notice prevent a user from knowing whether or not his recourse is actually effectual, Facebook provides the ability to selectively remove listings from the mini-feed as recourse for mistakenly publicising actions. In some cases, recourse and notice could even be implemented in such a way as to allow user to undo unwanted communications by notifying them if the recipients of their messages have received anything and allowing users to “unsend” messages if the recipients have not (a feature common to many groupware solutions.)

Although access and recourse do work well as fail-safes, they should be integrated into any design regardless of whether or not they are deemed necessary by failure in any of the other principles of privacy awareness. Simply giving users the ability to correct potential misuse of their information can be key to gaining their trust and allowing them to have a richer, more comfortable experience.

So that’s the last principle I’ll mention. Next, I’ll talk about templates, which can be a great way of abstracting away many of the scope and practicality issues involved in the last few posts.