If you're a long-time GitHub user, you probably have seen something like this:

This happens every time you do a potentially destructive thing to a repository, like switching its public / private status or archiving / deleting it.

The prompt shows up in a modal after clicking the action button, so this is an extra measure to prevent accidental actions.

But as far as I am concerned, this is either ineffective in "setting another barrier" or too cumbersome as "an extra confirmation". One can simply copy the repository name from the URL or right above the input box (the bold text above), but this is still more complex than just clicking an extra button.

In my opinion, an extra modal with a bright red button that does't respond to keyboard actions (like the Enter key) would suffice. One would have to move their mouse onto the bright red button to click it for an extra layer of caution. This is less cumbersome and the disability to simply hit the Enter key is both simple and effective.

Can anyone explain how this "enter project name" is a good UI design?

  • 183
    I prefer that method. You can throw all the red buttons you want at me, if I'm tired I might just click on it. I may have picked the wrong thing to delete. Forcing me to enter the name definitely makes me think twice. Nov 18, 2019 at 12:23
  • 71
    "In my opinion, an extra modal with a bright red button that does't respond to keyboard actions (like the Enter key) would suffice." Think about accessibility, someone relying on the keyboard won't be able to perform those actions.
    – jazZRo
    Nov 18, 2019 at 14:20
  • 11
    @iBug so... in other words, it responds to keyboard actions in the same way everything else does? Tab navigates, enter ""clicks""
    – Delioth
    Nov 18, 2019 at 19:29
  • 73
    "One can simply copy the repository name from the URL or right above the input box (the bold text above), but this is still more complex than just clicking an extra button." Yes, exactly... Nov 18, 2019 at 19:40
  • 13
    @MetalMikester makes an important point: if you meant to delete a different repo, you won't be able to get past this modal, because you'll type the wrong name. Nov 19, 2019 at 1:21

7 Answers 7


It's not necessarily about "good UI design", but much more about taking all measures to prevent accidental deletion and ensure that the user is fully aware of what they are deleting.

This blog entry here captures it quite well:

Instead of giving users a confirmation button that they could mistakenly press, give them a text field and ask them to type the word “delete” to confirm. When the user types “delete” in the text field, there is no doubt that they want to delete. There is no accidental pressing of the delete button. There is no regret when the user deletes, because the confirmation text field makes them certain about what they’re going to do before they do it.
How to Make Sure Users Don’t Accidentally Delete - UX Movement

Sure, pressing a button is easier, but that always leaves the chance that you misread the name and delete the wrong item.
When you have to type out the name (or even copy paste it), you can be 99% sure that a user won't do that mistakenly. They would realize it at the latest when highlighting the name for copy-paste.

Besides that, this is usually only used for very critical deletion operations. These happen very rarely, so the argument about making it easier or less annoying doesn't really hold there.

Here are some related questions:

  • 6
    "usually only used for very critical deletion operations". True. I've seen this on very few sites. The Azure portal is one, when you're about to delete something big like a database, site our other resource. Not something one would usually do all that often anyway, but the consequences of deleting the wrong item can be disastrous. Nov 18, 2019 at 12:24
  • 10
    If you have the molly-guard package installed on linux it also makes you type type hostname in when trying to reboot, shutdown, etc the machine while connected with SSH
    – GammaGames
    Nov 18, 2019 at 22:15
  • 5
    @Polygnome funny, I was about to use WoW as a counter-example. Because you have to delete so many items as part of everyday behaviour within the game, it becomes completely automatic (yet still a painful manual step) and loses any of its molly-guard properties it was intended for.
    – Coxy
    Nov 19, 2019 at 0:16
  • 41
    Typing the name of the item is much better than "delete". The accident you are trying to avoid is deleting the wrong item. The user knows they want to delete but they might have clicked on the wrong item.
    – Qwertie
    Nov 19, 2019 at 6:25
  • 19
    In Japan, train companies (most notably, but also other industries) have taken this to the extreme. The employees are required to point at what they are planning to do something with, vocally announce what they are going to do, and then do it, even if nobody else is around. It has reduced errors by 85% atlasobscura.com/articles/pointing-and-calling-japan-trains
    – Suppen
    Nov 19, 2019 at 8:35

Just to be clear "good" UI design doesn't mean giving the user what they want. It often means helping the user to be a better version of themselves.

In addition to what's already been mentioned, this pattern (and several like it) allow the UI to reduce speed. In general muscle memory -> speed -> mistakes -> sad path.

Imagine that you're doing work in healthcare. If users build up too much of a "flow" in common tasks they could potentially make a simple mistake that kills someone. While counter intuitive, its often good to pull the user out of their flow by requiring an interaction (more than a simple confirm dialog that always appears in the same place and can be added to muscle memory).

Typing text is just one example of this. I've also seen:

  1. adding a time out to buttons before they become available.
  2. Randomizing placement of process continuation buttons.
  3. Adding a lock (eg run process as administrator with password)

All of these patterns are intended to annoy the user enough that they stop to mentally assess the process before going forward.

  • 46
    "Randomizing placement of process continuation buttons." That's a recipe for disaster when coupled with muscle memory! Nov 18, 2019 at 22:08
  • 1
    I'm not condoning the solution, just saying that I've seen this type of thing done. Also that doesn't mean swapping known positions, but moving to the right or left of a confirm modal for example. Nov 18, 2019 at 22:55
  • 2
    The initial paragraph alone already earned this answer an upvote. Nov 19, 2019 at 8:58
  • 7
    @EmileBergeron Free-to-pay games utilize that one all the time, tricking the player into clicking a "buy now $99.99" button instead of the "next level" button. And because it required user interaction, the app is allowed to automatically charge their Google Play account. .. Nov 19, 2019 at 19:43
  • 7
    I respectfully disagree with the first sentence. Good UI is about giving the user what they want. The sticking point (which you've elaborated on quite nicely in the rest of your answer) is that "what the user wants" and "what the user actually asked the computer to do" are very often not the same thing.
    – jmbpiano
    Nov 20, 2019 at 0:08

This is to ensure that:

  1. You understand the danger of what you're doing.
  2. Most importantly, that you're actually deleting the right repo.

If a user has a lot of repos with long names, it can be easy to get them mixed up. Typing the name is a good way to make sure you don't nuke the wrong one, which would be really really bad.

  • 2
    Glad to see your #2 on this list, people seem to be missing that. It's critical. It doesn't ensure you're deleting the right repo, but it moves the bar further if you have to actually type the name. "Okay, let's get rid of this old repo. Oh! I have to confirm deletion, okay: thing-I-no-longer-want. Huh! It won't let me delete -- OH MY GOD, I just almost deleted my 20 man-year repo!" Nov 20, 2019 at 14:46

I remap an unused keyboard key (via AutoHotKey) for intermittent use as a left-mouse-click to decrease strain from overuse of my mousing wrist, and sometimes (rarely) hit that key in the wrong spot when multitasking. I've also occasionally bumped the mouse itself and unintentionally clicked a button on a dialog.

While "don't make me think" is a very good rule, it makes sense to help the user focus on exactly what executing a infrequent, destructive command will actually do. I'd even consider having the user type a full sentence of the form, "Please delete the iBug/example-repository repository, including its wiki, issues, and comments" verbatim to clarify the user's intention to themselves in that situation, as the user will only do that once on that repository.

Anyone actually writing code has to type full, clear, correctly spelled lines of text very frequently, so one more such line to confirm the most destructive action you can perform on a project is not unreasonable.


In my opinion, an extra modal with a bright red button that does't respond to keyboard actions (like the Enter key) would suffice. One would have to move their mouse onto the bright red button to click it for an extra layer of caution. This is less cumbersome and the disability to simply hit the Enter key is both simple and effective.

(emphasis added)

Are you sure that they'd have to "move their mouse"? Every time? Even if they're on a device with a different resolution, where maybe things don't line up as anticipated? Or if they're zoomed in? What about touch input? What about people who aren't using a mouse (due to difference in ability/etc)? Now you have to make sure it responds to keyboard in a way that doesn't break accessibility, but doesn't allow an accidental deletion.

While there are arguments against indiscriminately following best practices simply due to them being best practices (versus developing an understanding of why they are in place) or at least "what everyone else is doing", particularly when they aren't always actually so great, I'd like to point out that usually they have become a best practice because there are unforeseen issues which will arise, and trying to go against them simply because you don't see the point of them is usually a bad idea. When looking at something that is a widespread/widely adopted best practice, start from the assumption of it being meaningful and significant and likely having strong underlying reasons that have developed over more time (and likely among more people than just one, and certainly having been reviewed by more than just one person) than you alone have probably devoted to the same set of problems (and with only your own perspective guiding you). Not to mention the global consistency issues.

@BigChair's answer alongside @Bryce Howitson's answer both dig into why this is a best practice for unrecoverable actions in general. In UI design, it's important to create friction for critical actions that will be unrecoverable, and these both cover the topic quite well for this context.

Where possible, though, I would advise taking a different path in any case where it would be feasible to implement:

Avoid letting actions be unrecoverable in the first place

With that said, the best way to move forward is to not have user actions result in unrecoverable software states in the first place. Remember, what a UI exposes to the person using software does not have to match what the software does to its state internally, in a 1:1 of related semantics. It's ok for how something is represented to the person using it to not match the technical implementation of what happens when they activate a related action.

Don't delete things in your software representation of them based on user input alone. Mark them deleted in your storage representation of them and provide a means to retrieve them (a recycle bin/etc). Don't allow the creation of situations where a person using your product can back themselves into a corner they can't get themselves back out of. Not only is it better UX to avoid the necessity of these types of confirmations wherever it is possible to do so, it also reduces support requirements and related levels of friction in related support issues (which are also UX aspects). When someone is "deleting" something, make abundantly clear that they will also be able to revert the action they have taken both while engaging in the action and afterwards (so that if they have accidentally "deleted" something without reading screens up to and including taking the action, they can now see where to go to undo it).

  • 1
    Avoiding "unrecoverable" actions is a really good point! I wish more interfaces would take that into account. I suppose its a function of the UI designer, product owner and dev architect/coder not communicating or not having a clear definition of success for the user in most cases. Nov 19, 2019 at 21:04
  • 3
    While it's a great idea, unfortunately, it's not always practical. And as soon as you make it recoverable, there WILL be someone who says they want to permanently remove the recoverable data.
    – barbecue
    Nov 19, 2019 at 22:40
  • @barbecue I absolutely agree that it's not always either practical or even necessarily possible, but part of the point is taking a step back and examining what makes sense, and what the related costs are both in terms of UX concerns and also data loss/support time (particularly if support turns into retrieval from backup). And, yes, sometimes people do want to permanently remove data: but maybe that's something which should occur via other means, then. Or add it in your recovery area (recycle bin/etc): you now have to completely change contexts to perform the permanent action
    – taswyn
    Nov 19, 2019 at 23:08
  • Requiring movement of mouse is not a barrier at all. Modern machines have touchpads right below the keyboard and touchscreens that are easy to accidentally touch anywhere. Nov 20, 2019 at 0:48
  • @R it's definitely a barrier to accessibility, and as an aside, "modern machines" aren't just laptops.
    – moopet
    Nov 21, 2019 at 12:04

I already made what I call accidental mistakes:

  • my hand shifted the second I pressed the button (wanted "Cancel", got "OK"). Alternatively: an ad popped up and shifted the page.
  • the instruction was so confusing that I pressed the wrong button (of course not the less destructive one)
  • I was "oh no no no" and in panic pressed the wrong button
  • I may or may not be Juan Pablo Davila

This is why I really, really prefer to have in such cases a process which makes me act differently from what muscle memory suggests.


What Github are trying to do here is avoid user error, but specifically "slips" as Don Norman refers to them in The design of everyday things.

Slips occur when users intend to perform one action, but end up doing another (often similar) action. For example, typing an “i” instead of an “o” counts as a slip; accidentally putting liquid hand soap on one’s toothbrush instead of toothpaste is also a slip. Slips are typically made when users are on autopilot, and when they do not fully devote their attention resources to the task at hand.

I emphasise the last part of the quote as its especially relevant.

The following article from nngroup talks about how to prevent slips

slip-type mistakes often are made by expert users who are very familiar with the process at hand; unlike new users who are still learning how to use the system


Considering the types of people who would use Github, you would consider them very high on something like the GDS Digital Inclusion Scale which would imply they are expert users more likely to make slips.

Then put the two together and empathise with an expert Github user who's put hundreds of hours into a project, but is tired, forgot which project they were in and and slips to press delete when they didn't mean to. How do they feel?

Many Github users have a high number of repositories and on the delete page there isn't much to tell them apart if you're not paying attention, perhaps you meant to delete the "million pound project - draft" repo, but you were in "million pound project".

This is what they are doing and I would consider it effective UI design for that. Putting helpful constraints in the way of operations which are unrecoverable is good practice.

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.