Our product enables our (mostly non computer-savvy) users to gather data in a number of ways. They can they set all kinds of automatic behaviour based on this data.

This data is stored in our database and users can create views on this database. They can choose which columns a certain view has and filter the rows.

Lets say our db looks like this:

name | age | gender | occupation
john | 28  | M      | Cook
mary | 30  | F      | Lawyer
bob  | 70  | M      | Retired
alice| 68  | F      | Teacher

Now a user could create for instance these views:

- all columns and all rows (the complete db)
- all columns for all males (exclude certains rows)
- name and age for all rows (exclude certain columns)
- name and occupation for all people over 60 whose occupation is not "retired" (exclude some columns and some rows)

Since all these are views on the same data changing or deleting data in one view also changes the others.

We have a problem where a large subset of users doesn't come to this conclusion on their own without being told or reading it in the manual. They think of the views more like tabs in an excel file. Which can obviously cause large problems.

We dont want to put lots of text in the UI explaining this. But do need our users to understand how this works. Furthermore a small subset of users can't seem to get their heads around this at all. Even after we explain it to them multiple times. Some will even tell us they understand but their behaviour confirms they dont.

  • Dove till with pigeon holes or house with many windows metaphor? Cookie jar with two openings? Anything to show them that manipulating the "stuff" through (one of) their view(s) actually changes the contents and would thus also change the data in another of their own views. Show them a video with two views on the data, change some data through one of the views, ask them to predict what they will see through the other view... Congrats when they get it right, gently correction when they don't. May 9, 2014 at 10:51
  • If that doesn't work, give them their own copies when they start changing stuff. Sort of a "copy on write" feature, making the original data safe and allowing your users to play at will with "their stuff". May 9, 2014 at 10:53
  • A common strategy is to have buttons at the top of the table that act as 'toggles' to switch between views. This is a common strategy used in applications like the File Explorer in Windows.
    – Michael Lai
    Sep 7, 2014 at 22:42

4 Answers 4


Having had this problem before, the only solution we found to "educate" our user base (mostly non-technical, 40+ users) was to soft delete the rows then add a global filter to "show recently deleted" items in a special color.

So, for example: Jim would delete contact Rebecca from the global list. He'd then go to his "contact list" view and be like "where's Rebecca?" With soft deletes and the "show recently deleted" filter on, he'd immediately see that Rebecca highlighted in a subtle red was recently deleted and be like "oh, ok", I get it. (We later added an option for "permenant delete" and "undelete".)

Our support calls dropped 90% on this after implementing soft delete.


To summarize, you have users who don't understand that the copy of data they are viewing is not a personal copy, but rather it belongs to everyone? If that is your problem, you need to add some constraints to your application restricting who can change or delete data. If that is not possible, then you need to provide an intermediate confirmation step to inform the users of the potential impacts of their changes. A system of change control and notifications about changes will also ensure that users understand the structure of the system.

  • Not nessesarily between multiple users. Even if there is one user they can still create multiple views into the same table (very much like sql views). Often they create a view "people i should still contact about their registration". And then delete people after they have had contact. But this doesnt delete the person from that view but from the entire database. We have a system in place so users without the required permissions cant edit or delete the data. This mistake is still being made by people with the required permissions.
    – martijnve
    May 9, 2014 at 8:48
  • We also give a warning when people do something like this but users tend not to read warnings. Especially if they are somewhat long.
    – martijnve
    May 9, 2014 at 8:50
  • You could also try changing the warning to require some thought. For example, "Delete this data globally by typing the name of the person you are deleting and click OK." May 9, 2014 at 14:16
  • If your users can create a view "people I should still contact about their registration", then why would there be a delete action on that view at all? Shouldn't there rather be an action like "hide from view because it doesn't apply to this person" or "set as already contacted". It seems that a general delete action is not appropriate for what the users want to express or annotate. But as you give it to them and as there is only this action available that seems to fit the bill, they use it. It might be necessary to look at what the required views are and the related user actions.
    – Stefan
    Oct 5, 2014 at 16:03

I think that in this case you have some work ahead of you. Since you've tried changing user behavior but have been unsuccessful you might consider changing the application behavior.

If making these views is a common use case and data being deleted is happening often then here are some suggestions :

  1. Divide administrative privileges even further to percent deletion by users that might not understand the mechanic. Basically, create a role specifically for deletions and only sign it to some. Modification might not be as troublesome so you can assign it to more people.

  2. Go with the flow of user behavior and make these views private to the user so they can edit/delete them without affecting the base data. You can offer a "refresh" option to let users recreate the same view with fresh data. This is harder than 1. Then, if necessary, create a special "base data area" where admins can go for the sole purpose of deleting/creating/modifying the base data. This will probably require less training for users that never got the original concept but users that understood originally will have to be retained.

  3. Spend more time to train users that don't understand the concept and add heavy warnings in the application during delete operations or any other destructive operations.

  4. Let users blame each other. Eventually someone will get mad that someone else deleted "their" record. Then they won't do it again. Make sure to log who deletes what when users come asking about their data so you can pass the hook. Haha.

I prefer 2 given time. 3 and 4 with not so much time. 4 is some fun too just to watch users have a go at each other. Haha. :-)


When the user goes in to edit an entry in a view, I would suggest displaying that entry within the entire database while editing. This way, the user knows that they are somewhere else, editing something that is not particular to the view they used to get there. If not the database, maybe just show that entry with all its details including the ones not found in that particular view. This sends a message to the user that they are now editing the data for that person, not just the text within the view.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.