Hacker News Reader

Comment by yakkomajuri | Hacker News Reader

I'm a dev and recently picked up "The Design of Everyday Things" as an attempt to become more design-oriented. Everyone raves about this being like the bible of design.

So far I'm about 80 pages in and have found it extremely academic and not very practical, sometimes deriving conclusions that are so far from reality that they are a bit concerning, like how a strong password does not matter because once they inevitably leak they can always be cracked via rainbow tables (the author doesn't use this exact term). As we know the exact point of a strong password is that it will not be in a rainbow table.

Of course the original version is pretty old but I picked up the latest revised version. Still some interesting insights and I haven't given up on the book quite yet but it's been a ton of theory and a lot of terminology so far.

View on HN

I've used The Design of Everyday Things in many classes I teach. I would agree that it's not practical, but that's not its goal. Instead, it gives you frameworks for thinking about things as well as vocabulary for talking about those things.

Off the top of my head, some of the key ideas include:

* Affordances, that objects should have (often visual) cues that give hints as to how to use things * Mental models, that every design has three different models, namely system implementation, design model, and user model, and that the design model and user model should try to match each other * Gulf of Evaluation (the gap between the current system state and people's understanding of it) and Gulf of Execution (the gap between what people want the system to do and how to use the system to do it) * Kinds of Errors and how to design to prevent and recover from them, e.g. slips (chose the right action but accidentally did the wrong thing, e.g. fat finger) vs mistakes (chose the wrong action to do)

What's particularly useful about Norman's book is that these key ideas apply for all kinds of user interfaces, from command-line to GUI to voice-only to AR/VR to AI chatbot. I'd encourage you to think about this book in this kind of framing, that it gives you general frameworks for reasoning and talking about UX problems rather than specific practical solutions.

DOET (neé Psychology of Everyday Things) deeply influenced me. Articulated things I had observed, experienced. Expanded my thinking.

I was using, teaching, and developing for AutoCAD at the time. Knew nothing about UI beyond my intuition. Just perplexed by how difficult it was for most to use.

Reflecting back, Norman's treatment of mental models and kinds of errors were the most impactful, evergreen design challenges I faced.

I read the Design of Everyday Things and most of it was painfully obvious examples and was overly philosophical.

Design is solving problems so they're intuitive for the user. Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it. And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.

> Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it.

It’s common to illustrate principles with examples that appear obvious, i.e. that everyone agrees on, so that after having it conceptualized as a principle, you’ll apply it in less obvious circumstances. Many things are obvious only in hindsight.

> And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.

That’s not true, because a lot of flawed design is being promoted and defended in public as the thing to do.

> Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it.

And yet we've all encountered push doors with handles many times.

> And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.

Good design is far cheaper and easier than bad design in the long run. Being able to articulate the benefit of good design such that stakeholders provide the resources for good design is perhaps one of the most important reasons to have such an education.

uh, the fact that this is written down and carefully put in frameworks is a good thing. Otherwise you can say any academic book is intuitive. the fact that it sounds obvious means they're getting the message across. because lord knows it was needed and there's plenty of failed products and ideas because of shitty design.

I was gifted this book my a CIO when in college. She had a dozen copies in her office to hand out to various people.

It took me a few tries to get up the will to actually read it. It was years ago, so I don’t remember a lot of details. My main take away was to make controls logical for the thing being controlled. “Norman doors” are the big one, but I often think about it while I’m in my car trying to do something on a touch screen, when all I want is a knob, button, or switch.

In the modern era of web design I think it would point to these websites (like most of Apple’s product pages), that make users scroll through indulgent animations, just to get to the content. It may be cool the first time, but is very annoying for repeat visits, and it feels like it breaks my scrolling expectations. Not to mention all the horizontal scrolling thrown in there, which becomes a headache for those without the hardware to do it easily, and confusing to change scroll direction all the time.

I love this. Thank you for introducing me to "Norman Doors". I hadn't realized someone else had described this in such detail. I have been complaining about this years.

Ok this will be a tangent, but I also take this one step farther and also talk about "documentation". Just for the record, I don't think documentation is all good or all bad, but it definitely can be used incorrectly and in excess. And Norman Doors and a great way to get this point across.

When someone creates or installs a Norman Door by accident or out of ignorance and then realizes there is a problem, they often think "I know, I will document it!" and they add little placards to the door that says "Push/Pull" or some such. They see that this helps with a small subset of users and thinks "there, I fixed the problem, people just need to read the documentation and now it is their problem if they don't". But if you watch users of the door, a large portion will still use the door incorrectly because... people don't read documentation. If they don't read documentation, is it the users fault the door was designed incorrectly or was it the designers problem?

I use this as an example for my developers on thinking before documenting troublesome code or a confusing interface to first ask "can I design this so it is less confusing?" and if so, that would usually be preferable to adding documentation "to solve the problem". Well designed code (or doors) with no documentation always beats poor designs with documentation.

There's a funny example of even the "documentation" going wrong. At a local mall, there is a set of doors and they have put the word "PULL" (vertically like:

) on the window of the door, so from the wrong/opposite side, you still see the word "PULL" when you should PUSH (even if most of the letters are backward) so you still are tempted to take the wrong action when you see it. (I tried to explain the ridiculousness of it to the person I was with, but I don't think they cared.)

I've long suspected that I have a particular form of...dyslexia?, because I suffer from that Pull/Push thing, but also freeze when confronted with elevator door buttons that look like this: <>/><, and with public bathroom entrances, because in Spanish it's usually H/M (hombres/mujeres), but in English it's M/F (male/female), so the presence of the M throws me for a loop. My read on this is that if I see both options at the same time, my brain stutters for a second.

> but also freeze when confronted with elevator door buttons that look like this: <>/><

Same here! It's especially difficult when you're trying to quickly figure out the button to help someone who is about to miss the elevator.

Which reminds me of another "there, problem solved!" pet peeve of mine. I call it the Default Trap.

In many cases (Norman Doors are an example), there are two or more equally valid ways to do something. By "equally valid", I mean there is no clear standard for whether it should operate one way or the other, and if you ask 100 people which way it should work (which no one ever does), you get something approaching 50%.

So the product manager or perhaps developer simply says "make it a setting", and everyone agrees and declares the problem solved.

But the problem is, you have to choose a default. And 90% of the time, no one is going to change that default, or even discover how to. So you have to be very correct about assuming which value is the best default - and at that point, it probably doesn't matter that you make it an option.

The alternative I've seen to this is to ask the user which way they want it during the setup process. Light vs Dark mode is an example of this. The net result of this user choice is a longer, more complex, and burdensome onboarding process that is rife with decision fatigue. Once the user has chosen, if they don't like their choice, they may not know how to change it, since that initial action was outside of any standard interface.

The other issue with settings for everything is that the settings become bloated. In OS X, and to some extent iOS, I knew where all the settings were for the most part. Browsing them all to see what was available was a consumable thing, and I could largely remember where to go without much trouble. As macOS and iOS have added more settings to try and please everyone, and now redesigned the Settings apps... I've given up. I have no idea where most things are, what is in there, and have to search for everything and hope I use the right words.

There is an old video of Steve Jobs[0] talking about how every product is a series of decisions and trade offs. People pay companies to make all these decisions, and ideally, there is a company that makes decisions to similar enough sensibilities as yourself so that you can buy a product and use it without much fuss. It seems more and more that these decisions are all being pushed to the consumer, which in some ways makes a worse product. If I wanted infinite chose at the expense of complexity, I'd be running Gentoo or Arch. People choose macOS because it's supposed to be easy.

[0] https://www.youtube.com/watch?v=XmRNIGqzuRI

The thing about norman doors is that it's not really a design flaw, not in every case. Like handles on push doors. It's tempting to think of that as a design flaw but more likely it's designed to be mass produced and reversible, the cost of making two (or more) configurations being much higher than the occasional confused user. You could argue this only enhances the metaphor as a lot of design issues occur when things are optimised for the company and not the user.

I still see this as a design flaw, even if it explains why it was done. They save a little in manufacturing, and then thousands of people per day end up using it wrong for decades, in the case of a high traffic door, like at a mall.

Related… this is one of my favorite Far Side comics.

https://fifetli.wordpress.com/wp-content/uploads/2019/01/scr...

Wouldn't the solution to make the door so different handles can fit on both sides and then the installer can simply put the correct handle on each side as needed? Surely that is just as much of a manufacturing efficiency improvement.

My car has a staggeringly bad UI design choice - the cancel active navigation the control to do this only appears when you hold your finger close to the screen. Pretty much every time I want to do this I am flummoxed as to "Where did the button go" - before I eventually remember.

The navigation system is good - I prefer it to using my phone and CarPlay but that design is terrible.

Is it a VW? I had a VW with a proximity sensor like that. I didn’t use the in-car navigation, but it did that for the favorites on the radio. They only showed as I moved my finger close to the screen.

VW Group yes - a Škoda

I also have a Skoda that also has that "feature". I prefer using Maps via Android Auto, but if I am in that interface, and I have to cancel it, the way I cancel it is using a voice command.

Voice commands and Scottish accents are not a great combination.

It tells lots of things but you can takeaway a few things.

One of the key takeaway example for me was that if you make an approachable flat surface, people will put things on it. This is a small example but tells a lot about design of common things.

Another was that I shouldn't be blaming myself for failing to use an everyday thing, I should be blaming its design.

After reading the book I now keep seeing so many design flaws in so many things around. It also made me appreciate good design similarly. I probably think a bit more about users of code etc now, doesn't mean I write better, but it has changed perspective quite a bit.

"Bible of design" might be a bit excessive. It's a good design 101 book. Definitely longer than it should be, and kind of fumbles the explanation of "affordances", which the author had to clarify later. It's representative of "design thinking" as a historically well-situated concept in design, but that's not necessarily a good thing in itself.

It really depends what you're looking for. If you want something deeper, more abstract, I would recommend going straight to something like Notes on the Synthesis of Form by Christopher Alexander, which I think typically appeals to the more abstraction-oriented part of the mind of engineers. If you want to get more actionable, practical day to day recipes, Refactoring UI as suggested somewhere else in the thread is a decent suggestion.

The Norman door was a powerful example for me, as it emphasises that the user is not the problem but the push door with the handle is the problem.

And if you’re designing the door, it is your responsibility to think deeply and observe behaviour, to design an intuitive interface.

I do agree that it’s rather academic, but I did leave with that one takeaway.

For me the real capability unlock from The Design of Everyday Things was that it made me start noticing and thinking deliberately about design decisions, which pushed me to begin evaluating everything through that lens. In general it comes down to looking at something and asking "what is good / effective and what is bad / annoying about this". If you keep doing that enough you develop your own taste and a greater appreciation of the world. Donald Norman isn't handing you a map, he's teaching you how to build your own.

Yes - notice, observe, focus, consider, judge, refine ... repeat ...

- Photography, not to take better photos, but to see the world more continuously and deeply.

- Architecture, not to build anything, but to be more aware of urban context, visual design, practical use and emotional response in the built environment.

- Music, not to read a score or play an instrument, but to really hear the structure of music, appreciate melody, pattern, balance, pace, production, individual virtuosity and harmonious combination.

Yes this I agree with and was my whole goal with the book

For Devs/Engineers and even many designers, things some of us tend to take for granted were amazing to them. So, my first recommendation is to read Refactoring UI end-to-end and keep a copy handy at your desk.

https://www.refactoringui.com

PS. Refactoring UI is from the guys who created TailwindCSS.

May be it's just me, but the very first example (contacts form) looks better (easier to read) on the left than text in empty space on the right (which is supposed to be the good design)...

It's not just you, I didn't even open the link and know exactly which two examples you're talking about because I left this same comment on HN a while ago.

So much of modern design is fashion yet the designers pretend it isn't. Like it's some scientifically provable truth or axiom that faint lines between list items is "bad".

Just judging by eye, I'll bet in both of those designs the "Team/Member" text would fail one of the WCAG grades.

Thin, light grey text on a white background is not really very good design.

$99 for a 218 page PDF which, while it has a Goodreads page which rates it highly:

https://www.goodreads.com/en/book/show/43190966-refactoring-...

doesn't have a working "Purchase on Amazon" link, and searching there for:

"Refactoring UI Adam Wathan , Steve Schoger"

returns no results.

One can get two "free" chapters in exchange for one's e-mail address.

Book deal fall through? Why?

Either you want to support the authors and give them the price they ask or don't. You being on this platform gives me the assumption that you can definitely find pretty much any PDF on the Internet for free, in a way or another.

I would prefer to support the authors by the purchase of a dead tree/printed book.

Still more on the psychological and even philosophical side than being about how to do design, I really enjoyed Jenny Davis, "How artifacts afford" (2020). It takes consideration of 'affordance' to a new level. If that rings bells, you'll love it.

Like you say, it's old and I'm nostalgic for the time that I associate reading it with. I think that explains some of the love folks (or at least me) have for it.

I've never revisited the book and thanks to your comment I might not ever now ha

Tangentially, happens to me with music. Some songs aren't _great_, but I still like listening to them for the associations it has.

That point about rainbow tables seems to ignore how modern hashing works. We use salted hashes (bcrypt, Argon2) specifically to render rainbow tables ineffective. Since the salt is unique per user, pre-computing tables isn't feasible, so a strong password absolutely still matters against brute-forcing the specific hash.

I read it and thought it contained several good ideas, but was excessively wordy and would have benefited from being half as long.

my take on this book is that 1) it contains a lot of foundational knowledge/wisdom about design as interpreted broadly that is very useful across contexts, and 2) it is itself, ironically, an example of poor design. Not in the visual sense, but in that it's structure and writing do a pretty bad job actually conveying that knowledge to the reader and being navigable.

I tried reading it and hated it, then I came back knowing bits and pieces of its contents from elsewhere and was like "yup, this is the only place I've seen all of this together".

i also picked up the book with high hopes and dropped off about where you are at. useful concepts like affordances and signifiers but felt like a lot of filler.

I took a Computer Science class decades ago that used that book as the core of the class material. I don't remember a single thing about that class now except that I hate that book and the professor bragging about designing cockpit instruments or some such. I learned more out of a cognitive psych class.

Reply on news.ycombinator.com