2-Step Removal - Emulating a Rubbish Bin in your App in order to Reduce your Users' Cognitive Load
Last updated:Software developers program to a machine, but we must be reminded that the actual end-users for systems we build are always humans.
With that in mind, and taking into account what we know about how humans interact with Computer Applications, we can derive a few ways in which we can enhance our applications using insights from neuroscience and psychology.
Cognitive Load
Broadly speaking, the term cognitive load refers to the amount of information you can keep in your head (short-term memory, actually) at the same time.
One of the things that demand more of our attention when working with information systems, for instance, would be dealing with irreversible actions.
Deleting or otherwise making permanent changes to data requires that users think very carefully over all possible outcomes such actions could lead to.
Irreversible actions put a strain on users' minds. All possible scenarios have to be considered before action is taken.
Cognitive load can also contribute to stress in the workplace. It also affects the impression users will have of your systems. Systems which don't overburden users' cognitive load (with irreversible actions and otherwise requiring them to have large amounts of data in their minds (as opposed to in the screen)) will seem easier and more pleasant to work with.
An example of How 2-step Removals can Lessen your Users' Cognitive Load
A simple way you can help users feel more at ease when using an information system you have designed (and help reduce errors as well) is to implement some form of 2-step removal of domain objects.
Deferring actual removal until the day after (like a rubbish bin) can help reduce users' tension and cognitive load.
Most information systems deal with objects - in fact, the core of information systems is actually concerned with managing these objects (creating, reading, updating and deleting them - the old CRUD acronym). So you can bet that a significant percentage of your users' time will be spent on destructive actions (not necessarily destroying objects, but changing system state, such as updating, creating and deleting).
A significant percentage of the actions carried out by users in software systems will cause some sort of state change.
If you have a simple safeguard in place to "let objects sit in the rubbish bin until they are actually removed" for instance, it could help users interact with your system in a more relaxed manner; they don't have to think very hard before deleting an object, because changes won't be actually put into effect until a day after - plenty of time to change one's mind should there be any need.
Implementation
As to the actual implementation of such safeguards, one relatively simple way to do it is to use database flags (could be a BOOLEAN or INT column on the table that represents that record) where your objects are actually persisted.
Rather than actually removing a record from the database when a user clicks Delete, just set this flag to true to signal that this item is marked for deletion.
In addition to that, you need a script that runs regularly (maybe at the end of each day) and searches the database for records which have been marked for deletion - only then are such records actually deleted.
References