| Yes, we should, but my trail of thought tried to address the deeper (or tangential) rationale for humanized error messages. My argument was that if you humanize error messages, you are increasing the service towards your end user. You convey a message that says "I see that something limits the use of the application, how can I help solve this". In general, the hierarchy of error prevention and solving should be this: 0. Treat the end user as a normal human being (obvious? well, I wish it was!) 1. Limit the steps a user has to take to a minimum, but no less then is required to execute the main goal of the application. 2. Focus steps as much as possible on doing something that satisfies a needed input by the user (i.e. minimize program management by the user) 3. Try to stop an error from happening before it occurs or asap. (Example: The stop sign when you drag a file in Windows where it can't be dragged, validation per form step). 3. When an error occurs, show a concise, friendly error-message, with is tells the user how to fix the issue or prevent it (if it can be done by the end user). 4. The level of apology should be linear to effect of the error: if the error makes the user feel disrespected, it stops him from finishing the task or delays him.
(i.e. apologise a lot if you application crashes, but a little if an e-mail address does not validate). |