> Error UIs don't need to be beautiful, they need to be functional
They need to be both. If it can’t be both, there’s as many arguments for it to be either human friendly or actionable.
I think it comes down to it being a human/machine interface, and what the human side does with it. If for more than half of the users the next step from the error UI is to rage phone their IT department, and a sympathic UI might actually stop them from doing it (or at least be considerate), I’d argue a friendly UI should be prioritzed over an overly informational one.
If it can be both, that’s better, but I wouldn’t be surprised if after user testing it appears it’s just damn hard.
Also having an error displayed on screen that can’t be retrieved any other way (logs, diagnostic dump on a console somewhere else, whatever) is a design choice I’d loathe way more than not having the error number on the BSOD.
They need to be both. If it can’t be both, there’s as many arguments for it to be either human friendly or actionable.
I think it comes down to it being a human/machine interface, and what the human side does with it. If for more than half of the users the next step from the error UI is to rage phone their IT department, and a sympathic UI might actually stop them from doing it (or at least be considerate), I’d argue a friendly UI should be prioritzed over an overly informational one.
If it can be both, that’s better, but I wouldn’t be surprised if after user testing it appears it’s just damn hard.
Also having an error displayed on screen that can’t be retrieved any other way (logs, diagnostic dump on a console somewhere else, whatever) is a design choice I’d loathe way more than not having the error number on the BSOD.