[Week 1] Bookclub: The Psychopathology of Everyday Things

Welcome to Week 1 – we’re off!

It’s time to read the first chapter. Below are some questions to think on as you read, and to discuss when you’ve finished. We’ll use this thread for discussion – jump in when you’re ready.


Design isn’t an easy thing to do well, especially when technology is involved. It’s supposed to improve the quality of our lives, but will frequently do the opposite. This is a paradox and a force that we must seek to overcome.

Questions to keep in mind while you’re reading:

  1. Consider past design projects you’ve worked on. How did the end result compare with your original vision and early designs? Was the end product a compromise? Did it mature and improve with changes?

  2. Assessing a product by its affordances does not take into account the context in which the product is used. A product can be used in very different way, some of which may not have been the use intended by the designer. Can you think of any examples of times where your work has been repurposed for a use that you didn’t intend? Could you have communicated your intended use more clearly?

Questions for after you’ve read the chapter:

  1. What were the key points made in this chapter?

  2. What are the implications of these points on your own work?


Ok then, I’ll start.

I’ve just finished the first chapter. It’s an enjoyable book to read. I’m terrible at sticking out non-fiction books but this one is easy to digest. Norman’s explanations and descriptions are fantastic. Examples that spring to mind are his explanation of the place that HCD has in the wider design spectrum and his description of delight.

Some thoughts and ideas.

A Memory

I always like to open with a joke and this book reminded me of an hilarious situation from a few years back. My boyfriend and I were at the supermarket with our young twins (never a good time) when one of them needed to use the bathroom. Mal took them to the closest one – at a McDonalds over the road – while I finished the shopping. I had just pushed the trolley out to the carpark when I get a phone call from him. He sounded pretty… stressed.

He told me that the bathroom door was broken and that the kids were both distraught. They’d been trying to get out for 10 minutes. I had to leave my groceries in the carpark and go in to find “emergency services to break them out” (his words).

Turns out it was one of those doors like the one pictured in Figure 1.3. I walked straight up and slid it. Fair to say, he was embarrassed.

Favourite Quote

While I’m on the subject of humour, my favourite quote is “Attractive doors. Stylish. Probably won a design prize.” It was in reference to the almost unusable double set of glass doors at the museum. I love the dry sarcasm.

Key Points

  • Users shouldn’t have to think hard (or much at all!) before using an everyday device
  • Affordances are properties of a device (what it does or offers by its very nature) but designers often confuse them with signifiers (which provide us with clues on how to operate a device)
  • There are two primary principles when designing for people (1. a good conceptual model and 2. make things visible)
  • Technology is a paradox because it is supposed to make our lives easier when it often makes it more difficult.

Implications on my work

This raises some complicated thinking for me. I work in a space where we deliberately manipulate technology to change behaviour (online community platforms - but not this one!) and some of that means not allowing people to do what they want to do or think they should.

I need to make sure that I can satisfy that brief without frustrating or alienating users. They should still be able to carry out basic actions without hindrance. Occasionally it gets pretty close to the line and I have to push back hard (against stakeholders).

I need to think more on it.


My past project memory of being gobsmacked by people needing a signifier for something I assumed was obvious use was on a WISMO application I designed early on. I’ve always personally hated the ‘if you’re done, simply hang up’ messages that are in the final menus of programs (they always feel kind of condescending to me), and because this was a simple tracking information program where the final menu offered to repeat the information, help you look up another package or connect you to an agent, I felt like I could do away with telling people they could hang up. Alas, we went live and looked at the numbers and that menu was in the red because people timed out of the menu and the error recovery retries, because people presumably didn’t wish to be rude and hang up on the system without permission.

The key points of the chapter for me are:
-that design must make assumptions that people will make errors and focus attention on designing the cases where things go wrong.
-That good design needs to effectively communicate how to interact with something as well as what can be done.
-And that you need to design for the correct mental models in order to communicate successfully.

I feel like this chapter ought to be forced reading for everyone on a product or project. I’d be rich if I had a dollar for every time I’ve heard some stakeholder trying to make a case that they don’t need to do the extra work to make an agent interface intuitive and clear for the user because “that’s a training issue.” I would be rich (I don’t design their systems, but I just want to scream, because, you wouldn’t have to spend so much time training, retraining and coaching every agent when they make a mistake if you had an interface that they didn’t need to memorise a convoluted infrastructure.

For my work it reminds me to take a look at the whole picture and not just the performance of the microinteraction, and to ask myself if I’m assuming that the user has more understanding of what to do than they actually do.


Before I start I just want to say that I was stressed about what to write for a while because my background isn’t in UX. I’d almost decided not to post anything at all because I wasn’t sure that I could contribute anything useful but then I realized that I did have a couple of thoughts rambling about in my head so here you go.

The part I loved the best was when he said that human mistakes and frustration were generally a result of poor design. I can’t find the actual quote on that so if I understood that wrong, please let me know.

That has given me a whole new outlook on things. I’m not just becoming aware of poor design but I’m also making the connection to good design.

For example, a nurse recently asked my mother if she had a non-skid mat in her shower because slipping in the shower is a bad thing (bad thing is a technical term :wink: ). She told him that she didn’t need one because the contractor who installed the shower wouldn’t put in the pretty and smooth stone that she had asked for because she liked the way it looked. He told her that she needed to have tiles no more than two square inches because otherwise the shower floor would be a hazard.

Before the book, I’d have heard that and simply thought it was interesting. After starting to read the book, I am aware of the nuances of the shower design.

I’m also now annoyed by stove tops. The knobs on my stove are different than the ones at my boyfriend’s house. Who’d’ve thunk, eh?

PS - I saw this link posted in the Slack “random” channel this morning. It seems apropos to the book. https://www.designernews.co/stories/84443-redditors-design-worst-volume-sliders-possible (One of the comments says that the reddit one is real. I’ve got no idea but I really hope not.)


I love those, especially the ‘make a noise as loud as you want the volume to be’ one :sweat_smile: (though that seems like the most practical of the bunch)


Affordances and signifiers often are and should be connected though they can conflict, one example used being glass, it appears to be permeable and yet often isn’t.

Designers need to think more about the signifiers than the affordances (I guess that assumes that affordances are already there and that we aren’t also designing the affordances).

People may use your product in ways that you didn’t expect. They will learn it’s afforances in different ways and you as a designer can control that to some extent through signifiers.

The most releavant part to me as a non-designer was the part about too much feedback. Amaazon is a prime example of this. When I place an order for several items, other websites might send me one or two emails, Amazon frequently sends several from order confirmations to delivery notifications then marketplace feedback requests. Most Amazon emails now get binned and I just check the order screen if something hasn’t shown up. Any important emails could very likely get deleted before they are read.


It was an interesting read. The confusing device to operate which came to my mind is the microwave. I use one standard setting in my home one, while I find it almost impossible to operate a different model

Also seems I have been using “Affordance” incorrectly. Some of the phrases we use commonly are “This lacks affordance”, “Is there enough affordance?” , “Need to add a bit more affordance”. The correct one I believe is “The affordance is not perceivable, we need to add a signifier”

Another key point in the chapter for me is the importance to align the product conceptual model to the user’s mental model.

Favourite quotes
"Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible"

“We must design our machines on the assumption that people will make errors”

“The rapid rate of technology change outpaces the advances in design”

Quick question to conclude. At the end, he states that “good communication is the key to good conceptual models”. By “good communication” does he mean a good system image?


My guess is that good communication may mean a good system image, but it isn’t limited to that. Unless I don’t understand what a system image is.

1 Like

Key points for me:

The affordance of materials - the idea that glass is transparent and smashable, or wood is solid and stable, and thereby affects how people interact with it- was fascinating. This is something Ill be observing, especially in animals and children, as they engage with their surroundings, seeking haptic feedback.

Conceptual models, where the workings of a system can be imagined from its interface, were another highlight. For example scissors and tandem bikes signal what you can do, how they work and the affects of ones action. The antithesis of this, the digital watch, features little visual information to signal what buttons do.

Implications for my work:

Both the principles above, and others covered in the first chapter - affordances, visibility, mapping, feedback - will continue to guide prototypes, service and design opportunities I’ll be spotting in future weeks. I agree that this chapter, alone is essential reading for anyone involved in human centred design. It’s written in a refreshingly non-academic way, which is particularly helpful.


Well I was explaining to @HAWK that I didn’t even realise that I had finished the first chapter and had started reading the second one. I am using the Queue app for Safari Books Online and I guess they didn’t think a signifier like ‘Chapter 2’ would be necessary :laughing:. What made me check where I was in the book was the introduction of a new concept and the fact that the chapter felt very long.

When thinking about feedback, I am drawn to the example of ticket validation machines at some train stations in Melbourne. The old ones used to tell you your remaining balance and if you have a low balance. Now, with the new ones you get a green tick or a red cross. I prefer the old ones so I can keep track of what I have been charged and see if it is correct. The skeptic in me says the new ones replaced the old ones so that there would be less overcharging claims from customers. You do have readers where you can check your balance and history to a certain extent but busy commuters aren’t going to find the time to do that.

Ah I had the displeasure of using SAP CRM for a data entry job not long ago. Your points apply to this for sure. They had to hire a group of us because of the influx of orders. While I would have been out of a job for that time, I think they could have reduced the time it took for order entry if everything was streamlined etc. 3 screens just to key in a few things - you could fit everything you needed on to 1 screen. Oh and you had to key in things in a special way to figure out you had a duplicate account at certain times. Really? :confused:

Their web based credit card data entry system was better since everything was on one page. However, I did accidentally press the wrong key but there wasn’t any proper feedback.

I did ask if there were keyboard shortcut keys for the SAP CRM but no one knew anything. The best things I could do to speed up data entry was use TAB & SHIFT + TAB, and organising my paperwork into various marketing campaigns so I would do less keying. Any changes to both systems would require the developers to make them. I don’t know how SAP can be customised in terms of its user interface, but the way that their system is designed is very cumbersome and needs reworking.


Greetings all from Sunny Spain!

I have just finished the first chapter.

I hope I’m replying in the right place, the signifier on my iPhone wasn’t too clear on where to comment on this thread ;-).

For me a few memories popped into my head.

The first being my grandad walking into my dads glass sliding door when I was younger, he knew the door sliding but used to get really angry with my dad asking him to add a sticker (signifier) so he could tell if the door was open or not.

When I read about mapping it made me think of my current house here in Spain, we have three light switches together and the one closest to the door should control the outside light. Annoyingly it’s the one furthest away which does. To this day, I still get it wrong!

Key points

If an afforance is not perceived or signaled it is pretty much useless and no help to the user.

It’s important that a users conceptual model is the same as the design/developers.

Realating to my work place.

We created an app which a user could log in using their finger print. However when I user tested it I found that when the user logged out and then tried to log in again with there finger print, the app asked the user to login with username and password.

When I contacted the developer he said this was because the user was “logging out” to user the finger print id and that they needed to just close the app.

I believe this is an example of the user and developer having different conceptual models.

Let me know you thoughts.


Ha! I’m also bad at this. We have several banks of 4 light switches and I try them all every time, before getting the right one. It drives my bf crazy.

1 Like

I’m enjoying this discussion! Let’s keep it going as we have more thoughts about Chapter 1 topics. Some great personal stories, and I love that we’re collecting favourite quotes—they capture a concept well. We should tweet a couple, eh @HAWK?

I’ve posted some starter info for chapter 2, so head over there when you’re ready.

I was looking around for a copy of those Catalogue d’objets introuvables books by Jacques Carelman that Norman mentioned when he was talking about the coffee pot for masochists, and remembered there was a website that shows a lot of the products: http://impossibleobjects.com/catalogue.html

Have to say the economic faucet, electric hammer and cuckoo watches are my favourites. :slight_smile:


Haha this is amazing!! I really liked the lateral rocking chair, Imagining myself on the chair… :laughing:

1 Like

An example I came across just now.

A shop with double doors and no obvious exterior handles in the middle, my presumption would be that you could push either or both in the middle to gain entry.

Actually no, you have to push the right hand door on the right hand side. It is not a double door but rather two separate doors side-by-side with the hinges inbetween the doors.

When I eventually got in and spoke to the lady behind the counter. She said that lots of people make the same mistake. I’m guessing no one has bothered to report that to head office.


Just finished chapter 1
I was amused by the idea that watches and phones could eventually merge! (2013 edition)

I’m thinking a lot about my clients concept models and how I need to know what they are before we can talk about issues they have.
This would get around the misuse of terms that causes confusion.
“I want a button on the home page” but meaning “I want a button in the menu I can see from every page and will notice when I’m on the home page”

I’m liking the approach to read a chapter a week!


Good call. I’ll line some up.

That’s good feedback. We were wondering about the pace.

I’d love to know what a system image is?

A system image is essentially the information a user can pick up from looking at the object/product/device itself.

This article does quite a good job of explaining the relationships between the different conceptual models.