> “You need a color for errors, and a color for successes, and a color for warnings.” is not necessarily the only way to design errors, warnings, and successes.
It's not the only way, but it is the best way. Straying too far from semantic meanings of colors can create confusion for users that expect a certain thing. Can you imagine if your bank had a two buttons - "delete account" and "cancel", where the delete button was green and inviting and the cancel was red? Danger should be semantic if your app has any sort of high risk actions involved in it.
It's fine if a game or a rss reader uses their own funky palette that shows off their brand, but any time you start handling money you should really stray away from that.
It's not the only way, but it is the best way. Straying too far from semantic meanings of colors can create confusion for users that expect a certain thing. Can you imagine if your bank had a two buttons - "delete account" and "cancel", where the delete button was green and inviting and the cancel was red? Danger should be semantic if your app has any sort of high risk actions involved in it.
It's fine if a game or a rss reader uses their own funky palette that shows off their brand, but any time you start handling money you should really stray away from that.