I read the article as "error messages should rather be a beginning than an end" message. Nobody wants a program to fail, that is not why you put effort to confi

I read the article as "error messages should rather be a beginning than an end" message. Nobody wants a program to fail, that is not why you put effort to configure and start it in. An error just describing what happened puts the load to fix or how to "heal" it onto the user. She needs a mental model of why the program failed and what to do to make it succeed. What I interpret "prescriptive" to be is that the message returned to the user on failure should give some hints how to make the program succeed. Because there are more ways to fail than the program author could think of, or more than fit on a screen, it is opinionated which advice to give then (a subset of all known and unknown possible fixes). I always tell my coworkers, an error message is a call for action, not an out-of-jail-I-just-stop-here card. The better you guide the user, the more efficient she can use our software.