But herein lies the difference between a program which is possible to use versus a program which is easy to use. Even smart, experienced, advanced users will appreciate things that you do to make it easy for the distracted, inexperienced, beginner users.
It's been a pleasure digging back into the archives of Joel's blog – so many bits and pieces relevant to the work we are still doing today. This particular piece from April, 2000, reinforces one of the core principles of designing great software.
I can't help but be reminded of designing modals – it's quite easy to manipulate the button a person clicks by just moving it to the bottom right corner, where a person expects the primary dialog action to be. So for example if someone is trying to delete their account on your service, the confirmation modal might have two actions: Cancel, Delete. We know that people rarely read text in a UI, so by putting 'cancel' in the bottom-right corner (with louder styling) you could probably reduce dropoff by a trivial amount. Of course, this will inevitably create more frustration for people who have to go through this flow a second time.
But the question you should be asking at that point, when you're splitting hairs over a button position, is: why was that person here in the first place? Why did the person want to delete their account? Instead of manipulating the common behaviors of dialogs, you have an opportunity to initiate a live chat, or suggest a better plan for their particular use case, or just ask what's going on.
You'll not only feel better about your work, because you're not trying to abuse user experience paradigms (which inevitably reduce long-term trust in your product), but you might find that the original intention (in this case, deleting an account) can be transformed into a positive outcome (for both the person and your business) by adding genuine humanity into the product.