Making changes to addressing problems only when they occur is part of agile development. The problem here is that the change is an extreme one, that generalizes

Making changes to addressing problems only when they occur is part of agile development. The problem here is that the change is an extreme one, that generalizes from one instance to all. But how do you tell how much you should generalize? A starting point is raw statistics: if you have 1000 customers, and 1 has this problem, should you fix it? Then, account for consequences: how serious is that one problem (what is its cost to you, to the person, to the community)? Finally, what are the knock-on effects, looking at the big overall picture: will addressing this problem improve your business overall, or undermine it? (sometimes, that 1 in a 1000 problem is a good excuse to fix something, or a signal to grow in that direction). Then, you can think about the best way to address the problem. Nasty prohibitive signs probably don't help; even nice prohibitive signs probably don't help either. Sometimes, you can reorganize how you do things so that the problem cannot occur (e.g. when training animals to not do something, you can train them to do something that is incompatible with the undesired action; e.g. floppy disks are shaped so that they cannot be inserted in the wrong way). The owner of a prominent software respository site told me that no matter what you write on forms - or how you highlight it - people will simply not read it. BTW: Sometimes the sign has underlining and exclamation marks added in a different colour, apparently upon second and third infractions. Exasperation marks.