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.
See the "Acknowledgements" section of his book -- pp. 299-304. Yes, Norman had written "The Psychology of Everyday Things" prior to joining apple. But in his acknowledgements to this particular book (i.e. "The Design of Everyday Things" p. 301) he very heavily credits his experience at Apple: "I have learned a lot in the years that have passed since the first edition of this book ... The most important experience was at Apple ... I learned about industrial design first from Bob Brunner, then from Jonathan (Joni) Ive. ... Steve Wozniak, by a peculiar quirk, was an Apple employee with me as his boss, ..."
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.
Hum... He clearly says that engineers have ideas that are antagonistic to interaction design. There is an implied message that they can learn not to, but one message is explicit, the other is implicit.
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.
Regardless of what the book says, anyone too close to the product during its development will have difficulty designing it appropriately for the user.
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's correct, and the designer is too close to the product too.
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).
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.