It's a book actually: The Design of Everyday Things
The reasons it's the worst design guidance out there is that it teaches: 1) that engineers should NOT be entrusted/involved with user design. 2) to conceptualize users as blissful idiots. 3) that obscuring errors in a system is actually a good thing.
All of these are things that I see the lasting effects of in products I use in every day. Don't get me wrong, I bought this with the best of intentions. It was the highest rated design book on Amazon on the topic. Reading through was an extremely painful exercise in essentially coming to realize that everything I see broken in the engineering teams I work with and products I use is actually codified in words.
Take this excerpt as an example -- p. 65: "Eliminate all error messages from electronic and computer systems. Instead, provide help and insight."
Are you f'ing kidding me? You cannot seriously think this is right. For the longest of time I wondered why I hated using Apple products. It turns out Norman was schooled at Apple and they absolutely practice this teaching. I bought an early-day iPod touch circa 2007 and proceeded on to loading all my music on it. A few upgrades later, some albums disappeared without any error. I searched and searched and searched, trying to describe my problem in a number of different ways on Google to see what I could find. And all I could find were semi-answers. But you know what? If it had actually displayed "error 0xFHJAD1234" when failing during the upgrade, I could've actually google that. And I'll spare you the story of what I had to do when the family Mac's HDD failed ...
So this is what we actually get, devices that SILENTLY fail, designed for people who are assumed not to know what they're doing and who likely do NOT have any technically-literate person around them that could assist them if they could in fact identify the problem.
Worse, this philosophy probably hints at a level of intellectual ignorance/arrogance that is quite fascinating. You see, in my line of work I have to be able to walk engineers I work with from the gate-level silicon all the way up to cloud and AI. Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both. But since you've eliminated engineers from the design loop (see #1 above), no one will tell you you're full of it.
So yeah, no. Do read Norman's book. But look at it as everything you should NOT be doing.
It sounds like your complaint isn't with the advice from the book, but rather that Apple didn't follow it. They did hide away the error messages, but they didn't provide help and insight.
If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234".
Thus I think it's fairly good advice, as long as you read the "instead" as a critical instruction. You should eliminate opaque error messages so long as you can provide help and insight for those cases you have removed.
So not only are systems increasingly complex, but those maintaining them at any given point in time likely don't understand them nearly enough to accomplish what you suggest: understand all potential outcomes and provide useful error recovery. Therefore, the "provide help and guidance" advice provided by Norman effectively becomes "silent failure" for those cases not anticipated by the current-day release team. And since anticipating all outcomes is by definition impossible, Norman's advice is awful.
Yes, that's why I said that I read the advice as saying it should only be followed when you can provide help and insight. You don't have to do it in an all-or-nothing way.
You can have common problems with a helpful flow that tells the user how to fix them. You can have less-common problems which just show an error code. Removing the error without providing help is the problem here, and is the thing that I feel goes against the book's advice.
The best you could do is report it to Apple (or whoever). But, the error alone doesn't achieve anything. You would have been better off with "Something broke, click here to send log to Apple." (which is roughly what the book recommends - replace the error with something actionable).
It turns out that if you actually do take the time to report the error, no matter how obscure it is, someone in a dark corner of the internet will spend enough time on it that they'll even see fit to document it for others to help their own selves out. And given that, per my initial post, nobody is smart enough to understand how the computer system/software they're creating is going to work under all circumstances, providing error verbosity is sometimes the most empowering thing you can give to your users.
However, I suspect this has also made it easier to write and (kinda sorta) maintain larger and more complex systems. Like the phenomenon where you widen a road to ease traffic congestion and it works for a while but then encourages more traffic. The reduced cost of creating and maintaining complexity may have encouraged it overall.
- - - -
As an aside, can I quote you, like, on my blog?
> in my line of work I have to be able to walk engineers I work with from the gate-level silicon all the way up to cloud and AI. Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both.
I don't mind the quoting, but, just in terms of mental hygiene, I generally dislike posting unequivocal opinions on the internet ... because it's often come back to bite me ;) I'm especially skeptical of my own writing when I use labels such as "ignorant" or "arrogant". So long as you understand that I don't take myself very seriously, I mostly stand by that quote you mention.
Giving a user an error ID gives them a partially-if-not-completely unique identifier that they can then use to find other people struggling with the same error and possible solutions.
This is infinitely better than having no error message and having to try to type different permutations of your symptoms into Google in order to try to win search engine bingo.
Sure, if Apple quickly and responsively fixed issues, then you wouldn't need the error code. But, they don't! The problem is that "hide the error message and replace with actionable advice" only works in the idealistic case where the vendor will quickly fix the issue and/or the advice consistently fixes the problem. But, they don't, and it doesn't - the advice doesn't work unless implemented flawlessly - it's not robust.
The robust approach that will actually survive contact with the real world is "include an error message and ID code - even if you have to hide it behind a "more details" button".
Bonus points to the mythical developer that includes a google-this button on the error display.
In my experience sending crash data to software companies has never resulted in my satisfaction, nor has using some 'wizard' to diagnose an error. As alluded to above these systems are just not smart enough to actually know what's wrong. If the original programmers could create a fully automated flow to repair all error conditions then why bother notifying the user at all?
Sending them to large software companies does not have the same outcome. But then, that's certainly not a flaw with the format.
If they're not tech-savvy (and you would never talk to Apple store employees besides at the checkout counter if you were), they likely won't be able to reproduce the error anyway. They'd fumble around trying to explain what went wrong, and the employee would run through multiple scenarios trying to reproduce it.
> If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234".
The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error.
>> Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both. But since you've eliminated engineers from the design loop (see #1 above), no one will tell you you're full of it.
Yes, that's what I said as well. It's why I said the problem was that Apple didn't follow the book's advice, insofar as they removed error messages without providing help for them... and so it's unfair for the grandparent-comment to blame the book when its rule wasn't followed.
If it's not possible to always give help and advice, sometimes you have to give an error message and unless the book mentions that then it is definitely fair to blame the book.
Since it says to hide error messages and instead provide help, anyone who hides error messages and doesn't provide help can't really be said to be following the book's advice. It feels wrong to me to blame the book for not, in every bit of advice it offers, saying "don't half-ass this incorrectly". That seems inherent to me.
That way, when the help and insight inevitably fails to solve the problem at some point, the user can still dump the error code into Google to see if other people have run into/solved the problem.
First off, Norman wasn't schooled at Apple, he basically created the HCI guidelines with Nielsen. Apple's design guidelines have long been based o years what Norman worked on so you have it the other way around.
In no part of the book does it say that engineers shouldn't be part of the design process. What the book advocates is that if engineers are entrusted with design, they should at least understand the users and design their products based on their needs and for the users. Anyone can be a designer, anyone can apply design thinking. No one is excluded.
And your comment about error codes, I would always say that an error message is more useful than an error code. You say that you would Google the code, wouldn't it be more useful if you could just read the actual error code and figure out what went wrong without habing to look it up first somewhere else?
What Norman advocates for is to help the users help themselves, show the state of the application and don't hide things behind error codes.
Again, silently failing is definitely not recommended by the book or anyone really so if thats been your experience with Apple, it's not because they follow the teachings of Norman's book, it's because they _don't_ follow it.
So while Norman wasn't a neophyte when joining Apple, he clearly credits his experience at Apple for having heavily influenced the specific book we are discussing.
Norman certainly doesn't recommend silent failure verbatim. But what I'm saying is that this is the net effect of his recommendations.
And it gets much worse in "The Inmates are Running the Asylum", that says engineers shouldn't do design right in the title, on the most sensationalist way possible.
Later he toned down that message a lot. Nothing from his group will say that anymore, and you will get a clear message that making your engineers think about design is better than nobody thinking about it. It still carries a message that you should leave design to experts, but you won't find anything there saying that engineers can't be UX experts anymore.
If you know how the product works then you already have a mental model of interacting with it. That mental model is NOT the same as the user will have, and thus an engineer will think that something is obvious even though it is not obvious to the user.
The same goes with anyone else who is close to it during the development.
You need outside users to make it clear how people new to a product can understand and interact with it.
Unless you're an engineer who can forget everything they know about their own product, you shouldn't try to design everything yourself with no outside feedback.
That is the correct message, and the one every article about design should push. Neither the engineers nor the designers can design a product in a vacuum.
Those are both old books that do not deny this message, but focus on less relevant subjects, and have less than clear advice. We shouldn't recommend those books for people without previous knowledge on UX design, because they will be harmful.
Besides, given that Nielsen was himself a very important voice on the creation of the modern user-focused design, there is very likely a newer book from him to recommend instead (I stopped reading his books and started reading his papers at the time of the change, so I don't know one).
I don't think you read the book. I read the book in 2000/2001. The emphasis was on helping the user.
Not a single line in that entire book, IIRC, advocates silently failing. I have no idea how you came up with that interpretation, when almost every single example in that book highlights "silent failure" as something to avoid.
https://www.youtube.com/watch?v=5GCPQxJttf0
Don Hopkins and Donald Norman at IBM Almaden's "New Paradigms for Using Computers" workshop
Talks by Don Hopkins and Donald Norman at IBM Almaden's "New Paradigms for Using Computers" workshop. Organized and introduced by Ted Selker. Talks and demonstrations by Don Hopkins and Don Norman.
Norman: "And then when we saw SimCity, we saw how the pop-up menu that they were doing used pie menus, made it very easy to quickly select the various tools we needed to add to the streets and bulldoze out fires, and change the voting laws, etc. Somehow I thought this was a brilliant solution to the wrong problems. Yes it was much easier to now to plug in little segments of city or put wires in or bulldoze out the fires. But why were fires there in the first place? Along the way, we had a nuclear meltdown. He said "Oops! Nuclear meltdown!" and went merrily on his way."
Hopkins: "Linear menus caused the meltdown. But the round menus put the fires out."
Norman: "What caused the meltdown?"
Hopkins: "It was the linear menus."
Norman: "The linear menus?"
Hopkins: "The traditional pull down menus caused the meltdown."
Norman: "Don't you think a major cause of the meltdown was having a nuclear power plant in the middle of the city?"
(laughter)
Hopkins: "The good thing about the pie menus is that they make it really easy to build a city really fast without thinking about it."
(laughter)
Hopkins: "Don't laugh! I've been living in Northern Virginia!"
Normal: "Ok. Isn't the whole point of SimCity how you think? The whole point of SimCity is that you learn the various complexities of controlling a city."
One solution I try is to redesign the cause of the error out of the system. For example, compilers often have maximum quantities of language constructs that are supported, like the maximum length of a string literal. Then, when the length is exceeded, an error message is concocted and generated, then error recovery has to be done, then the compiler has to not generate an object file, etc.
I don't know what other compilers do, but one day I realized that it was less work in the compiler to not have a limit, but to keep enlarging the string literal buffer. There was only one limit left on all these things, that was globally running out of memory. Globally running out of memory is a fatal error for compilers, and so error recovery isn't necessary. Just print a message and exit.
This works great. Large numbers of errors just go away, like "line length too long", "string literal too long", "too many cases in switch statement", "too many symbols", etc.
There are, of course, still some limits, like the object file formats often have hard limits, and of course you don't want to overflow the program stack.
30 years ago I had to live with problematic memory limits and made some design decisions that over time I would come to hate because I had to shoehorn data into EMS memory banks. Data objects ended up sliced and diced into separate arrays, never did they point to the relevant things because such pointers would always have been into a different bank and the only possible allocation was the whole bank.