The Design of Everything

[bigfield]

A couple of years ago I was gifted some books from my wishlist, recommended by Jeff Atwood, one of the guys who made Stack Overflow, a very effective Q&A website for programmers. At the time, I wanted to learn more about how to make good user interfaces for apps, but the books turned out to be much more interesting than that.

One of the books was Don Norman's the Design of Everyday Things. This is a book that complains about the fact that doors are often poorly designed, but it's also an introduction to the philosophy of Human Centred Design. Norman also provides a primer on some of the theory behind industrial design, such as signifiers and constraints, which are useful for analysing a design problem, but his most profound insight is this: the things that we make are intended to be used by humans, therefore we must design things that are compatible with humans.

That may seem stupidly obvious, and then you think about some of the stupid shit that gets made. Norman has a fixation on doors: doors that appear to open by pulling when they must be pushed; doors that are completely blank and must be opened by trial and error; airlocks with pairs of doors that open in opposite directions. Doors that are labelled "push" and "pull" because it's too hard to tell otherwise. Such a simple, everyday device, but a constant source of frustration. He also takes aim at a variety of other devices.

Why the hell is it so hard to make things that are easy to people to use? Partly it's because good design is sacrificed in order to produce a cheaper product, partly it's because designers and their clients are more interested in satisfying their own creative desires than making a useful thing. But most importantly to me, it's because the people who design and make things just expect people to change to suit their product.

As users of things, we also blame ourselves for being bad at using a thing. This is another of Norman's insights: he doesn't give a fuck about being bad at using a thing, because he knows he's a smart guy. If the thing is hard to use, it's probably the thing's fault. I'm actually living one of Norman's examples: I constantly find myself turning on the wrong lights in my house because the arrangement of the switches on the panel bears no relation to the arrangement of the lights on the ceiling. (That is, there lacks a natural mapping between the inputs and the outputs.) Am I a fucking idiot, or are electricians fucking cheap and lazy? I'm blaming the sparkies who make absolutely zero consideration for the people who are actually using the things they install, and I'm blaming the manufacturer who only sells light switch panels in one configuration. (But then, I'm also a cheapskate because I'm not paying an electrician to install more intuitive light switch panels.)

Norman also offers some more principles that help to identify bad designs
- if your thing requires a lot of trial and error to use properly, you might have a bad design.
- if a user has to learn a bunch of shit in order to use your thing--or worse, read a manual--then your thing isn't doing its job very well.
There are exceptions and degrees and whatnot, but not that many.

For instance, a computer-savvy person might be a highly productive power user, pumping out spreadsheets, code or blog articles, but they have also invested a ton of time learning a specialised set of skills to use a thing that really isn't compatible with humans' natural strengths. Keyboards, (mouse) pointers, password authentication and the modern desktop environment are all half-baked designs. Cars are also a woefully unfinished product: humans should not be driving cars, trucks, or anything, and they prove this constantly by crashing the fucking things - it's a job for an autopilot. Both computers and cars are everyday things that humans have to work very hard to use without difficulty.

Now, this subject matter is very interesting when you apply it to things like gadgets and apps, but it gets really interesting when you apply it to systems. By systems, I mean the way that we do things like business operations or interface with government services. A lot of these systems seem to suffer from a massive failure to design for humans, either on purpose or through sheer incompetence. I have about eleventy such things I've found at my workplace, but then my workplace is like an episode of Gordon Ramsay's Kitchen Nightmares without a kitchen.

One example that sticks in my mind is the emergency room at hospitals. In Australia, the emergency room is free: you don't have to pay to see a doctor there, but the staff will prioritise you based on how sick you seem to be. I've personally been to the emergency room for various reasons: I nearly killed myself at school gymnastics; I went into shock after going on a roller-coaster; I swallowed a large coin; I tore my anterior cruciate ligament. (These are not in chronological order.) Arguably, only the first one required an emergency room visit, and I was delivered there by ambulance. The characteristic example, however, is the complaint that people go to the emergency room when they (or their children) merely have flu symptoms. (I'm talking about during normal times, not during pandemic times.) Some people have looked at this problem and said "the visitors are to blame for using the emergency room for non-emergencies; they should have availed themselves of other services instead". I contend that this is bullshit. The system is to blame for not accommodating real human behaviour, particularly humans under stress. Don't blame the user, blame the design, and make a better one.

This takes to me another point: In a democracy, everyone's a wannabe designer. There are some awful ideas on how to design a better emergency room (e.g. "make people pay a fee so they only go there for actual emergencies"), but that's just one example. Discussions about employment, housing, healthcare, and law enforcement all feature pundits, commentators and politicians offering terrible solutions that seem like they are designed with a totally different species in mind. Good design of anything is a skill that has to be learned and practised, you can't take a shortcut with so-called "common sense".

Here's a heuristic I'm working on: if your idea requires humans to do things that humans are not good at doing, then your idea might just suck.

Here's another: Try blaming the thing before you blame the user. You might actually make something better, for once.

 

[Shadowy Man]

Sounds like a book I would enjoy. People very often hear me say that anyone who designs something should be forced to use that something for quite some time before finalizing the design for manufacture because I’ve found so many things that just seem to work so poorly. Then there are other things that seem to work fine but break after a small number of usages.

 

[rousseau]

A lot of this can be explained by the heuristic: what is the least amount of work I can do and still keep my job

I've worked in four companies as a developer now and have come across very few people who actually care about the human impact their work has, if they even think about impact at all. Most are just trying not to get fired, or to get promoted. And even fewer are aware of the impact of their work on greater systems.

Then, even if you do care you need the knowledge and skill to devise and execute a better system, which doesn't leave us with many people.

On the bright side, if you are one of those people who care, it's very easy to differentiate yourself.

 

[Treedbear]

A lot of this can be explained by the heuristic: what is the least amount of work I can do and still keep my job

I've worked in four companies as a developer now and have come across very few people who actually care about the human impact their work has, if they even think about impact at all. Most are just trying not to get fired, or to get promoted. And even fewer are aware of the impact of their work on greater systems.

Then, even if you do care you need the knowledge and skill to devise and execute a better system, which doesn't leave us with many people.

On the bright side, if you are one of those people who care, it's very easy to differentiate yourself.

My experience with software programmers (as an Engineering Aide and intermediary between engineers and test techs) is they are seriously pressed for time by their work load. And the reason for that is that their management doesn't hire enough programmers so they don't have the time to get involved at the level of the end user. I suspect that's the way it is with the average engineering department and that many junior engineers are put in charge of projects that are well above their competence level. The byword is that if nobody complains it's working.

 

[bilby]

We are in the process of updating our fleet of trucks at work. These are seriously expensive bits of kit, and are an imported generic vehicle with a custom built cargo compartment made locally.

The trucks are great. The cargo compartments, which are made to order and so could presumably be modified to meet any specification that meets some fundamental requirements for capacity, weight, refrigeration capability, etc.

But they're actually built the way the builder has always done it. So the floors have a non-slip coating that makes unloading unnecessarily laborious. There are two rows of fittings for shoring bars to restrain the load, but the lower row is too low to be useful, and the upper row too high to do anything at all. The tail-lifts have a safety rail that must be deployed before folding out the platform; But deploying the safety rails makes folding out the platform awkward, and encourages handling the platform in a way that risks injuries. The side doors are located in such a way as to give access only to a single pallet of stock - where previously you could access half of two different pallets, which has a host of non-obvious benefits that those who unload the vehicles are aware of. This door position also forces a break in the securing system, such that one or two rows of pallets cannot be secured adequately (if the doors were offset half a standard pallet width, half of that problem would vanish instantly).

Not one of these design issues could have survived the builder showing the drivers the intended design, and asking "Is there anything about this you would like to see modified?". But design approvals are handled by managers, not drivers. So we have expensive trucks that are not easy to use, when we could easily have had trucks that were far easier to use for pretty much the exact same price.

And this isn't a problem for my employer, or my industry. This happens everywhere, in every industry, and if you suggest that it might be better to ask the guy actually doing the job what he wants and needs, the managers get defensive and accuse you of trying to undermine them.

 

[James Brown]

Not one of these design issues could have survived the builder showing the drivers the intended design, and asking "Is there anything about this you would like to see modified?". But design approvals are handled by managers, not drivers. So we have expensive trucks that are not easy to use, when we could easily have had trucks that were far easier to use for pretty much the exact same price.

I totally agree with this. And yet on the flip side, Henry T. Ford reportedly said, "If I asked my customers what they wanted, they would have asked for a faster horse."

 

[rousseau]

A lot of this can be explained by the heuristic: what is the least amount of work I can do and still keep my job

I've worked in four companies as a developer now and have come across very few people who actually care about the human impact their work has, if they even think about impact at all. Most are just trying not to get fired, or to get promoted. And even fewer are aware of the impact of their work on greater systems.

Then, even if you do care you need the knowledge and skill to devise and execute a better system, which doesn't leave us with many people.

On the bright side, if you are one of those people who care, it's very easy to differentiate yourself.

My experience with software programmers (as an Engineering Aide and intermediary between engineers and test techs) is they are seriously pressed for time by their work load. And the reason for that is that their management doesn't hire enough programmers so they don't have the time to get involved at the level of the end user. I suspect that's the way it is with the average engineering department and that many junior engineers are put in charge of projects that are well above their competence level. The byword is that if nobody complains it's working.

That's been my experience too, and parcel to my point. Businesses are filled with MBA grads who obsess over quarterly profits and don't think about anything other than how soon something can be released (not the human side). So developers get unrealistic deadlines and frantically try to meet them without pushing back and telling managers that they're being unrealistic. Often, developers don't feel like they have the political ability to push back, so they just don't.

The overall result is that few people are actually thinking about the quality of the final product beyond it existing. Sometimes this approach results in market dominance and overwhelming success despite a shitty product, but other times the project just flat out fails.

 

[Shadowy Man]

Not one of these design issues could have survived the builder showing the drivers the intended design, and asking "Is there anything about this you would like to see modified?". But design approvals are handled by managers, not drivers. So we have expensive trucks that are not easy to use, when we could easily have had trucks that were far easier to use for pretty much the exact same price.

I totally agree with this. And yet on the flip side, Henry T. Ford reportedly said, "If I asked my customers what they wanted, they would have asked for a faster horse."

And for most of them a faster horse would probably have sufficed.

 

[TV and credit cards]

You can't please everyone unless everyone is willing to pay for it. You can use these plans already made and build from it or you can pay for changes or pay to start from scratch. Scratch is wonderful. Draw the plans or build the software, sit down with the customer and discuss changes. Keep doing it until the customer says stop. It's always best to get the experts ideas first. You don't know what you don't know. If all you've ever used for transportation was a horse, you'd have no idea what an automobile is like.

Oftentimes workplace rules will be changed by someone on high to solve a particular problem without recognizing how many people that new rule affects or how it affects them. By and large, I quit my last job for this reason. People were abusing credit cards, making questionable purchases. They solved this problem by getting rid of discretionary funds, to buy what you needed when you needed it. So everyone had to put in a requisition for everything and get it approved by their manager. This process would normally take 2-5 days. Fine if you rarely make purchases. I was the handyman. I ran to the home store on an almost daily basis to buy items normally less than $50. It's not hard to see where this made my job nearly impossible. It meant most of the time I would be sitting on my ass waiting for requisitions to be approved. A two day job could be stretched into weeks. I couldn't do that. I left.
At Yosemite we had a water treatment facility rebuilt. The builder could have made the maintenance man's life miserable had he not pointed out two pieces of equipment were too close together and would have prevented him from getting his wheeled cart through that he used to bring a rather heavy piece over to the workbench for maintenance.
In the navy, one of the guys writing the software for our system showed me the neat graphic he had made to indicate a missile approaching a target. I told him I just watch this number off to the side here. When it says -xxx, I know the missile has acquired the target. Your converging hash marks are nice but not really needed.

The navy was great about asking for feedback so things worked right. But the navy could pay for the changes that would ensue.

 

[bigfield]

I've found that end users, at least in business settings, appreciate being consulted and will help you if you're helping them. But that goodwill only lasts as long as you actually act on their feedback. Ask the user to tell you what their pain points are, engineer a solution, take it back to the user, and repeat if there's still room to improve (or until you run out of time, money or patience).

Norman describes a process called root cause analysis: basically you ask "why?" over and over again until you find the ultimate problem that someone is trying to solve. In the case of the truck driver, "the shoring bars need to be lower" might become "I need to strap these pallets of stock to the side of the cargo container" and then "I need to secure the load from moving". The resulting design may not involve shoring bars at all. You're still giving the user what he wants, but not necessarily in the form he assumed. It's important to involve the end user in the design process so you can actually make something that's fit for purpose, but they won't do your design and engineering job for you. When it comes to most technology, the average user probably has no idea what's even possible.

 

[bigfield]

I've also found that one of the most difficult hurdles is convincing management that this kind of work is worth doing. Managers and business owners are often great at their core business, but they don't know shit about solving problems outside of that domain, which makes it difficult to convince them to trust you to do it for them. They want a sure thing.

 

[Tharmas]

I've found that end users, at least in business settings, appreciate being consulted and will help you if you're helping them...

There’s a name for the process at least in software engineering – UAT (user acceptance testing), which should be a part of every development cycle. I am aware that it often isn’t.

In my career as a tech writer, generally for the end user, UAT was often left up to me. Tech writer’s rule of thumb: the harder it is to explain, the worse the design likely is. It was always very satisfying when I could document software use with a couple of screen shots and a few labeled arrows.

 

[Old Woman in Purple]

I'd expect Keith&Co to have experience & opinions concerning all this. Where is he? I haven't seen him around in over a month!

 

[TSwizzle]

So many times I have found myself yelling "Who the eff designed this piece of shit?!!" Sometimes bad designs are on purpose though, a built in obsolescence I suppose. Do you remember when desktop PCs first started having USB ports. And they put them at the back ?!! WTF ?? I had a dryer that stopped heating the air. After much research I tracked the likely problem to a small single use fuse/breaker. A $2.00 part. But in order to replace the fuse, I had to take the dryer completely apart, remove the controls, the drum and what not, replace the fuse (which I didn't know for certain was the culprit) and put the thing together again, it took three hours and a lot of cussing. If they had put an access panel at the back I could have been done in less than five minutes.

 

[DBT]

My new Lenova has three USB ports on one side, so close together that only two can be used at any given time.

 

[Treedbear]

My new Lenova has three USB ports on one side, so close together that only two can be used at any given time.

If I leave the open USB port on the end a flash drive will just barely fit.

The beauty of the design is that it's modular. Everything except the SSD drive is external, including the power supply. Emits no noticeable noise or heat. Result is a much more versatile and serviceable system than with my previous pc's.

 

[none]

A couple of years ago I was gifted some books from my wishlist, recommended by Jeff Atwood, one of the guys who made Stack Overflow, a very effective Q&A website for programmers. At the time, I wanted to learn more about how to make good user interfaces for apps, but the books turned out to be much more interesting than that.

One of the books was Don Norman's the Design of Everyday Things. This is a book that complains about the fact that doors are often poorly designed, but it's also an introduction to the philosophy of Human Centred Design. Norman also provides a primer on some of the theory behind industrial design, such as signifiers and constraints, which are useful for analysing a design problem, but his most profound insight is this: the things that we make are intended to be used by humans, therefore we must design things that are compatible with humans.

That may seem stupidly obvious, and then you think about some of the stupid shit that gets made. Norman has a fixation on doors: doors that appear to open by pulling when they must be pushed; doors that are completely blank and must be opened by trial and error; airlocks with pairs of doors that open in opposite directions. Doors that are labelled "push" and "pull" because it's too hard to tell otherwise. Such a simple, everyday device, but a constant source of frustration. He also takes aim at a variety of other devices.

Why the hell is it so hard to make things that are easy to people to use? Partly it's because good design is sacrificed in order to produce a cheaper product, partly it's because designers and their clients are more interested in satisfying their own creative desires than making a useful thing. But most importantly to me, it's because the people who design and make things just expect people to change to suit their product.

As users of things, we also blame ourselves for being bad at using a thing. This is another of Norman's insights: he doesn't give a fuck about being bad at using a thing, because he knows he's a smart guy. If the thing is hard to use, it's probably the thing's fault. I'm actually living one of Norman's examples: I constantly find myself turning on the wrong lights in my house because the arrangement of the switches on the panel bears no relation to the arrangement of the lights on the ceiling. (That is, there lacks a natural mapping between the inputs and the outputs.) Am I a fucking idiot, or are electricians fucking cheap and lazy? I'm blaming the sparkies who make absolutely zero consideration for the people who are actually using the things they install, and I'm blaming the manufacturer who only sells light switch panels in one configuration. (But then, I'm also a cheapskate because I'm not paying an electrician to install more intuitive light switch panels.)

Norman also offers some more principles that help to identify bad designs
- if your thing requires a lot of trial and error to use properly, you might have a bad design.
- if a user has to learn a bunch of shit in order to use your thing--or worse, read a manual--then your thing isn't doing its job very well.
There are exceptions and degrees and whatnot, but not that many.

For instance, a computer-savvy person might be a highly productive power user, pumping out spreadsheets, code or blog articles, but they have also invested a ton of time learning a specialised set of skills to use a thing that really isn't compatible with humans' natural strengths. Keyboards, (mouse) pointers, password authentication and the modern desktop environment are all half-baked designs. Cars are also a woefully unfinished product: humans should not be driving cars, trucks, or anything, and they prove this constantly by crashing the fucking things - it's a job for an autopilot. Both computers and cars are everyday things that humans have to work very hard to use without difficulty.

Now, this subject matter is very interesting when you apply it to things like gadgets and apps, but it gets really interesting when you apply it to systems. By systems, I mean the way that we do things like business operations or interface with government services. A lot of these systems seem to suffer from a massive failure to design for humans, either on purpose or through sheer incompetence. I have about eleventy such things I've found at my workplace, but then my workplace is like an episode of Gordon Ramsay's Kitchen Nightmares without a kitchen.

One example that sticks in my mind is the emergency room at hospitals. In Australia, the emergency room is free: you don't have to pay to see a doctor there, but the staff will prioritise you based on how sick you seem to be. I've personally been to the emergency room for various reasons: I nearly killed myself at school gymnastics; I went into shock after going on a roller-coaster; I swallowed a large coin; I tore my anterior cruciate ligament. (These are not in chronological order.) Arguably, only the first one required an emergency room visit, and I was delivered there by ambulance. The characteristic example, however, is the complaint that people go to the emergency room when they (or their children) merely have flu symptoms. (I'm talking about during normal times, not during pandemic times.) Some people have looked at this problem and said "the visitors are to blame for using the emergency room for non-emergencies; they should have availed themselves of other services instead". I contend that this is bullshit. The system is to blame for not accommodating real human behaviour, particularly humans under stress. Don't blame the user, blame the design, and make a better one.

This takes to me another point: In a democracy, everyone's a wannabe designer. There are some awful ideas on how to design a better emergency room (e.g. "make people pay a fee so they only go there for actual emergencies"), but that's just one example. Discussions about employment, housing, healthcare, and law enforcement all feature pundits, commentators and politicians offering terrible solutions that seem like they are designed with a totally different species in mind. Good design of anything is a skill that has to be learned and practised, you can't take a shortcut with so-called "common sense".

Here's a heuristic I'm working on: if your idea requires humans to do things that humans are not good at doing, then your idea might just suck.

Here's another: Try blaming the thing before you blame the user. You might actually make something better, for once.

food.
put the card with the chip in.
eat.

 

[Loren Pechtel]

I've found that end users, at least in business settings, appreciate being consulted and will help you if you're helping them. But that goodwill only lasts as long as you actually act on their feedback. Ask the user to tell you what their pain points are, engineer a solution, take it back to the user, and repeat if there's still room to improve (or until you run out of time, money or patience).

Norman describes a process called root cause analysis: basically you ask "why?" over and over again until you find the ultimate problem that someone is trying to solve. In the case of the truck driver, "the shoring bars need to be lower" might become "I need to strap these pallets of stock to the side of the cargo container" and then "I need to secure the load from moving". The resulting design may not involve shoring bars at all. You're still giving the user what he wants, but not necessarily in the form he assumed. It's important to involve the end user in the design process so you can actually make something that's fit for purpose, but they won't do your design and engineering job for you. When it comes to most technology, the average user probably has no idea what's even possible.

Yup--as the guy who decides what to write as well as writing it I consider that a substantial part of my job. User requests will almost always be improvements on the existing approach, whether or not that's what they really need. The compilers take care of more and more of the scutwork, but it still takes a human to do that analysis, refine it into an airtight scenario (many times I've had to reject requests because they contained hidden internal inconsistencies. I speak computer, I don't speak paradox!) and then translate that to code.

 

[Tigers!]

Not one of these design issues could have survived the builder showing the drivers the intended design, and asking "Is there anything about this you would like to see modified?". But design approvals are handled by managers, not drivers. So we have expensive trucks that are not easy to use, when we could easily have had trucks that were far easier to use for pretty much the exact same price.

I totally agree with this. And yet on the flip side, Henry T. Ford reportedly said, "If I asked my customers what they wanted, they would have asked for a faster horse."

Yes to this.
I have working with 19" racks for 30 years and every single one has some design 'feature' that makes me why did you do that? The new ones at work are close to the best I have every used but a couple of thing make me go argh!!!

If the designers had to actually use the equipment in the beta testing then redesign the gear it would be so much better. Same fro cars.

 

[Loren Pechtel]

If the designers had to actually use the equipment in the beta testing then redesign the gear it would be so much better. Same fro cars.

Yup. You can really tell what systems were dog-fooded and what weren't.