I recently submit a bug report about a user interface. The steps shown demonstrated that "deleting" something didn't allow it to be recreated afterwards.

The error on creation was "Another account is already using this unique key." but the user interface shows no such key in use anywhere.

However, the developers response was that it was not a bug. Since the software maintains a unique key throughout its lifetime, that key should not be destroyed. Their suggestion was to access the underlying database and delete the unique key. The problem was that the key in this case was a commonly-used value that would make it hard to avoid. (e.g. the user's email address)

On a software development level, the principle problem is choice of unique key. If that key needs to be unique throughout the lifetime of the product, then it shouldn't be user-chosen.

However, from a user experience level, if I "delete" something, then shouldn't it be properly deleted, warts and all? Thus, there should be no problem if I choose to create it again.

Some other ways to look at this experience might be:

  • If the key affects the user experience, then it should be shown in the interface. So if it's only partially deleted, then I should still find it listed somewhere.

  • If components of the deletion remain, perhaps it should be called "disable" or "hide"?

Is there some kind of subtle line where delete stops meaning delete?

(As a corollary, I note that some online systems have "delete profile" but don't delete everything, either!)

From the discussion, and after some thinking time, there appears to be 2 facets and 3 operations that can be described here:

  1. What is the object of the operation? This could be a reference to data (e.g. a "key") or data itself.
  2. What operation is being performed? In other words, what are we deleting? Are we:
    • changing a link between some data? e.g. unlink
    • deleting a key that acts as a reference? e.g. dereference or remove (maybe)
    • erasing the data itself? e.g. wipe or erase

It could be argued that in all cases something is lost and therefore "deleted". It could also be argued that nothing is ever lost but simply changed. That is a primarily technical difference, however, and we're focusing on what the user perceives is happening and how that can be improved. So this is irrelevant to the question.

From the user's perspective, in all cases here, something is lost and the possibility of finding it again is wide-ranging. As pointed out by @evil-closet-monkey, the concept of "deleting" suggests destruction beyond possible recovery, which is why many common UIs choose not to use that term anymore.

However, the very first part of this question demonstrated that "deleting" didn't actually delete but unlink or remove, and that created an unexpected impediment to another operation (the creation of the new account). I think this hasn't been really fully addressed in any answers so far. Imagine if, after "deleting" a file, you were never able to create that file with the same name again. That would be a bit silly, wouldn't it? Or would it?

Furthermore, there can be an egotistical relationship between the user and the data. I am more concerned with where my email is stored than being counted as a visit to a site, for example. This can have an effect on what I expect will be deleted.

  • 16
    You're working too hard on this problem. Ultimately, this was a relational database design flaw, and has really nothing to do with user experience. The email shouldn't of been used as a natural primary key to define the user account, and they probably should of used a surrogate if anything. If deleted, it should just throw NULL to each natural identifier in the column but leave the primary key in place since it's already been used. In the end, if proper development had been adhered to in the first place you'd never run into this problem.
    – SQLSavant
    Mar 11, 2014 at 6:51
  • 1
    @cloyd800 For a primary key that is not an autoincrementing value and may be reused, why would it not be reasonable to remove such a key if the data associated with it is removed, or for a less destructive method, mark the key as free so that the new account using the same e-mail will simply be granted that primary key? Or is it not a matter of database efficiency and just that you'd have to make sure all data associated with the primary key was removed first (which may not always be reasonable, as mentioned in the forum/etc. examples)?
    – JAB
    Mar 11, 2014 at 12:30
  • 2
    @JAB Once a primary key is set, it should never change - best practices state it should be immutable. This is because it may be a reference to multiple other foreign keys in other tables. Changing the primary key in any way could cause a ripple effect of integrity issues that would usually far exceed that of the problem you'd be experiencing if you didn't delete it. Therefore, once a primary key is set - it should stay set. If the same relational information is needing to be placed into the DB under a different PK then issue a new one and null out as much information as possible in the old
    – SQLSavant
    Mar 11, 2014 at 12:47
  • 2
    @JanHudec You have to be really careful about that, else you introduce a security vulnerability. Mar 11, 2014 at 17:21
  • 1
    @Spike That's an argument to do with ethics rather than user experience. Even though I believe most users expect a system to behave ethically, that's really a lateral step away from this question into a much broader question. Mar 17, 2014 at 0:27

8 Answers 8


From a user's point of view, delete should represent a permanently destructive action on that object.

Example: Place an apple in front of user and ask them to "delete the apple". They might be puzzled at first but they will eventually do something with it. Now, ask them to eat the apple. Chances are they will be very puzzled now because they either (1) already ate ("deleted") the apple, or (2) threw it in the trash and really don't want to eat an apple that was in the trash. Any attempt to take action on the apple require a new apple!

Example: Put a document or drawing in front of a user and ask them to "delete" a particular element from it "with this pencil". They will either scratch it out, draw a line through it, or erase it. In all cases it is a destructive action to the original.

Example: Do you honestly believe these guys don't mean what they say!?

enter image description here

The destructive metaphor of delete was brought over into the computer world as well. Microsoft DOS has the del command and UNIX as the rm command (although short for 'remove', lots of documentation on the command will use the term "delete").

Moving into the UI world, before the days of a "recycle bin" or "trash", to ask to delete a file still meant to destroy it completely. Today we do have those concepts though, and they are used like so:

Mac & GNOME (couldn't find a KDE snapshot) do it correctly! Notice you are moving items to a trash can, just like you would in the physical world. When I throw a piece of paper out, I can always pull it back out of the bin.

enter image description here

enter image description here

Windows does it wrong! You "delete" a file to a "recycle bin"... huh? I've never deleted a soda can before, let along into my recycle bin. How are software files "recycled" anyway? But I digress, this just really irks me!

enter image description here

When done right, you aren't "deleting" files anymore. You move them to a space where they can be recovered. When you "Empty Trash" (on Mac) the files are gone for good, just like on Friday morning when the trash truck comes and takes your weeks worth of trash away.

While the file is still technically on your hard drive, for 99.9% of users the file is effectively gone at this point. It is "deleted."

Looking more specifically at the backend, the SQL delete command is just as destructive. There is no "kind of deleted" about this command. You run it and you better hope your SQL string is correct!

On a software development level, the principle problem is choice of unique key. If that key needs to be unique throughout the lifetime of the product, then it shouldn't be user-chosen.

Exactly correct. So your developer is wrong, this is a bug! As a former developer myself I know what he thinking, and the user experience is not in the mix. The fix might not allowing the user to create that unique key, or changing a label. It isn't necessarily a code fix.

Is there some kind of subtle line where delete stops meaning delete?

The subtle line is created by poor use of words within the user interface. Delete should be just as destructive as it sounds, else you put users into a false sense of security when "delete" here isn't as destructive as the "delete" that is over there!

From your question's description of the product, I would say you are on the correct track that the unique key should not be user defined. If the unique key was being used as (for example) a "name" field, you might need to add a new field to the database to fill that need from the users - but the field does not have to be unique on the system side.

Now, when you "delete" a record it is gone with no trace from the user point of view. If they recreate it exactly the record may have a new unique id but they don't care - they don't see it anyway!

  • 1
    Great answer - I think this sort of goes hand-in-hand with a little principle I think of as 'the identity principle.' A GUI element should A) do what it says, and B) say what it does. A 'delete' button that moves a record into an area where it can be deleted is not actually deleting anything, it is performing a move. This is bad for the user cognitively, too, as now they have to remember that, in this context, delete does not mean destroy, but rather, move to a location that permits actual deletion, which adds a layer of thought that impedes the Flow of the process. Mar 11, 2014 at 18:15
  • 1
    Great answer - and bonus points for incorporating a reference to Cybermen. Lol! I think I'm looking for something more concrete, tho. Is there perhaps some GUI research on the meaning of delete? Mar 11, 2014 at 22:48
  • @Andrew Gray I think you're on the right track, there. Empirical evidence may be nice if, indeed, it's available. Maybe there's some Apple UI research? Mar 11, 2014 at 23:02
  • @tudor - That's a good suggestion, I'll get on that. I want to know if there is a GUI design rule along those lines. I don't remember seeing anything like that in the Android UI research/best practices docs, but I'm thinking I ought to give it another look-over and see what I've missed, now that I've done a little UX of my own. Barring that, a little scholarly research wouldn't hurt, to see if my 'theory' is correct. Mar 11, 2014 at 23:05
  • 1
    It's also important to note that the underlying operation in Unix is not even called "remove", but "unlink"! Mar 11, 2014 at 23:42

There's no hard and fast rule here. In most cases, the end-user no longer sees it, but whether or not it's deleted is a murky concept.

Take a look at your average desktop GUI.

  • Delete a file and...
  • It's still there. In the trash/recycle.
  • Delete it from the trash/recycle and...
  • Well, you don't see it, but it's still there on the hard drive

So if we get into the technical aspects of it all...such as DB GUIDs, it's definitely murky.

Broadly speaking from a user experience standpoint, it really depends on context. But typically you'd want two-form 'validation' of a delete. This could be as simple as the common 'delete moves to trash where it can be recovered or permanently deleted'...sometimes that latter option is in the user's hand, sometimes that requires some form of admin level rights (depending on the application and the data).

  • I agree that it's murky. However, if I delete a file and it's moved to the trash then, as expected, I can still create another one in the space it originally came from. In my question it's not so much that the data still existed, but that it prevents me from doing what I expected to be able to do had the object actually been deleted. Mar 11, 2014 at 5:44
  • @tudor yep, that's true, And a valid argument. That said, in the context of 'records/accounts' I can see reasons to not allow that.
    – DA01
    Mar 11, 2014 at 5:56
  • The question is about a case where the data is deleted but the key/index remains. This answer is about a case where the key/index is deleted and the data remains. In the question, the consequence is that you can't create a "file" with the same "name". In the answer, the consequence is that the data can be recovered. Imo, the answer doesn't really address the question. Different concepts and different user expectations.
    – nitro2k01
    Mar 11, 2014 at 12:19
  • @nitro2k01 the title of the question is rather broad. As I state in another comment, I think perhaps the OP needs to ask a much more specific question if the issue is focused solely on GUID retention in a database of user accounts.
    – DA01
    Mar 11, 2014 at 13:59
  • @nitro2k01 (and DA01) My focus here is on user experience, not technical implementation. What does the user expect to happen when something is deleted? The need to retain identification, key, related objects, and links are all valid points, but you are correct in that this answer only answers for the deletion of key case and makes an argument that "developers know better than the user as they may want it back". Mar 11, 2014 at 22:40

On systems where user actions are recorder and may be linked to more data and other users, it's difficult to completely delete all traces of a deleted user.

For instance, in a forum, after you have written some posts and answers, if you decide to remove your use account, it may happen that the reference to quotes are still there because the table related to quotes is linked by the unique key, which may be the user's email; or the list of most prolific users is also linked to the email or key associated to the user, etc.

So in those situation, removing you account usually means that your personal information is gone, but your linkage to other elements on the system remain; still, those may not be traceable to you directly, at least if the associated key is not the email, but they are there for consistency of the database.

Designing complex systems where data is linked are difficult to completely clean up for the presence of removed items. So I'd say that in that kind of situations, delete means "we remove direct traces of your existence here and kind of transform your past on a ghost"

  • This answer comes to the defense of "profile companies". Deleting a user profile doesn't mean that all your linked data is deleted. You become a "ghost" in the sense that the profile still exists to link it together, but it's no longer marked as you. However, this still does not stop you from creating another account/profile since it just gives you a new key, since all your keys are no longer tied to your identification. Mar 11, 2014 at 5:50
  • @tudor it sounds like your question is actually "should email addresses be used as GUIDs for user accounts?". I would argue that, yes, that's a valid decision as email addresses are unique.
    – DA01
    Mar 11, 2014 at 5:57
  • @tudor: It does prevent you from creating the same user if the key element is a unique, or expected to be unique, element. Of course it doesn't prevent the creation of new account, but prevents the creation/registration of the same key. So, as user, you don't expect that, and usually you will never notice, unless you try tor register again and try to use an element that the system has as unique. Many systems use email as main key in DB, which is a common element that a user would reuse if tries to register again.
    – PatomaS
    Mar 11, 2014 at 5:58
  • 1
    @DA01 I thought that, too. However, if the developer had decided to remove all traces of the email, then it wouldn't have been a problem. It was the combination of maintaining it as a key after the record was "deleted" that seems to be the real issue. Conversely, if it wasn't something the user identifies themself with, then the user would be less likely to expect it to be able to be used again. Mar 11, 2014 at 6:02
  • @tudor I think the issue is bigger than what the developer decided. The use of emails as unique identifiers plays into things like security, data retention policies, data integrity, etc. So, are you wanting the dev to not use emails, or is the issue that the term being used is 'delete'? I think you may have to focus on the latter (keep the behavior, but come up with a more descriptive term for the action).
    – DA01
    Mar 12, 2014 at 0:36

Why delete is not delete

The reason why they don't really delete it from a technical perspective is to keep relations in place. However, that doesn't mean anything to the end-user, and therefor leads to a sub-optimal experience.

How to make it look like delete from a user's perspective

What they can do is reconciling the two: when a user delete an account it stays in the system, but is completely hidden from the user. Then when they user wants to recreate the account, simply revive it (but keep in mind that old data will show up then), or create an alternative account with the same credentials.

Legal caveats

Always keep in mind that there may be applicable legal obligations to totally destroy the (user's) data. When they apply, then make sure delete is really, really delete.

  • This is answering a different question. I'm not asking why but when, and I'm deliberately avoiding the technical argument of underlying implementation and keeping it within the boundaries of user experience. The question points out that the fact that something wasn't truly deleted when that was the requested action meant that expected functionality was impeded at the user level later and created a bad user experience. Mar 17, 2014 at 0:23
  • "The question points out that the fact that something wasn't truly deleted when that was the requested action meant that expected functionality was impeded at the user level later". That point is addressed in the second part of my answer: even though you're technically not deleting, the user doesn't have to experience it like that at all.
    – user12741
    Mar 18, 2014 at 6:48

Not an answer but... use "Remove from list" if an object is just removed from a list but not removed from software/hard drive. Too often, "Delete" is used and that has an ambiguous meaning to it.

As long as the functions has clear names/explanations/icons you are on a good way to a software that's easy to understand and use.


One difficulty that can arise in database design is how to handle record identifiers that may exist in places the database doesn't know about. If some particular string can be used by itself to identify a record in a database, a strong argument can be made that no copy of the string should ever be able to identify any other record in the database. Enforcing that requires one of two things:

  1. Tracking down and destroying all evidence which might exist anywhere in the universe which would indicate the string had ever been used as a database key.

  2. Never allowing that same combination of characters to represent anything other than the original record.

From a user-interface standpoint, the question of how to expose record identifiers thus becomes very important. Exposing only surrogate identifiers will ensure that if a record is deleted and recreated, the new records can be assigned new identifiers, but requiring people to use surrogate identifiers can sometimes be annoying. Using or exposing user-supplied identifiers can make things more convenient for users in most cases, but if identified records are removed, allowing the identifiers to be reused will mean that existing references to the old record will become references to a new record which may or may not really be related to it.


I have worked as a software developer for over a year. During most of that time it was working with web interfaces that connected to databases. During this time I learned there is a difference in "delete". I am not sure it is the proper terms, but there is a hard delete and a soft delete.

Hard delete is where information is completely wiped out. Most programmers avoid this for many reasons when it comes to database programming. For example if you do not have a query string correct when removing a record, it is much easier to switch a "deleted" flag in a DB than it is to restore backups. For this purpose, you can use a soft delete.

A soft delete basically works like your recycling bin does on your Windows desktop. While you can not see the files through your file explorer, the files are still on your hard disk (Even after you empty your recycle bin until the files are overwritten by other files). This allows developers to maintain records and makes auditing as well as researching bugs much easier.

  • I think this is an attempt to create new terms where ones already exist. We already have "erase" or "wipe" for "hard delete" and "unlink" or "remove" (maybe) for "soft delete". Attempting to explain things by using additional adjectives is more likely to confuse than assist. Mar 12, 2014 at 23:00

I believe your submitted bug report was 100% correct.

If an interface has a delete option that removes an object "permanently" -- in the regard that there is no user-facing mechanism to recover it -- then it is, as far as the user is concerned, permanently deleted and able to be recreated.

The developer response might be correct from an architecture standpoint but that simply means the interface and the architecture it's built upon are not representing the same thing. (I do believe, as you mentioned, user-input should not be generating a unique key to avoid situations like this).

If you delete a file in your filesystem, it does not disallow you from creating a new file with that name; if you delete a character from a document, you are not disallowed from typing that character next once again; if you delete a draft in an email client, you can create another one with that same subject. All of these are the correct implementation of delete and handle the user-input differently than the unique key they store it as.

  • Thank you for the confirmation. I am more interested in finding some kind of empirical and clear explanatory response from a UX perspective particularly in the differences between wiping, removal (as in re-move), and unlinking, and "what" is being wiped, removed, or unlinked. These seem, to me, to be the 3 distinguishing operations that are commonly called "delete". Mar 12, 2014 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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