We all make things. Sometimes we make things for ourselves, sometimes for the broader hacker community, and sometimes we make things for normal folks. It’s this last category where it gets tricky, and critical. I was reminded of all of this watching Chris Combs’ excellent Supercon 2022 talk on how to make it as an artist.
“But I’m not making art!” I hear you say? About half of Chris’ talk is about how he makes his tech art worry-free for galleries to install, and that essentially means making it normie-proof – making sure it runs as soon as the power is turned on, day in, day out, without hacker intervention, because venues hate having you on site to debug. As Tom joked in the podcast, it’s a little bit like designing for space: it’s a strange environment, you can’t send out repair teams, and it has to have failsafes that make sure it works.
What is striking about the talk is that there is a common core of practices that make our hardware projects more reliable, whatever their destination. Things like having a watchdog that’ll reboot if it goes wrong, designing for modularity whenever possible, building in hanging or mounting options if that’s relevant, and writing up at least a simple, single-page info sheet with everything that you need to know to keep it running. Of course with art, aesthetics matters more than usual. Or does it?
So suppose you’re making a thing for a normal person, that must run without your babysitting. What is the common core of precautionary design steps you take?
Label things! the buttons! What it even is…!
Make sure that every wire is secure – give it a good shake and drop it a few times to see UFM anything is loose.
Seconded! Also because the police think anything with wires is a bomb.
Have empathy for the people who will be interacting with whatever you’re making. Put yourself in their shoes – what are the things they’re going to be doing every time they interact with your device? What do they do today, and why? How, specifically, do they do these things, and how do the interactions you’re asking your user to execute fit into their existing context & workflow? Often, the salient goals of whatever process they’re using today are red herrings – things they’re doing because they’re forced to, or are making do with the tools they have today. So, what are they _actually_ trying to achieve? What do they do if something goes wrong? Questions like this abound, but the important thing is that the end user’s goal is not to use your doodad to do a thing: it’s to do the thing as efficiently as they can for whatever definition of “efficient” applies within their context.
Obviously the importance of this kind of understanding and one’s ability to achieve or act upon it depends quite a bit on one’s particular organization & role, but where possible this means three things:
* Talk to these people early, and keep talking to them as you iterate. Go to them and learn from them if possible.
* Codify your understanding as detailed engineering requirements with specific criteria.
* Be willing to change (or fight for changing) those requirements as your understanding changes.
*Don’t go changing established practices and processes simply because you want to; sometimes it has knock-off effects elsewhere that you can’t see.
+1
Some people aren’t simple minded, they just use a weird logic/thinking pattern.
Cultural differences may also the culprit why they approach situations in a certain way.
I believe that a certain group also has trouble with something, because the group is thinking in too great complexity.
It’s not the first time that test subjects failed a test because they were too smart/creative/conscientious.
Too often bright children fail in school because they’re underchallenged.
It’s as if you’re a 4th grader that has to attend kindergarten or something, I suppose.
Anyway, I suppose people know what I meant to say. Some users/customers spend too much thinking about something and fail, because the manual was written for the simple minded and doesn’t provide the information they’re looking for.
I’m reminded of the photograph of a brass door handle from a museum, worn down to a thin stub, because apparently children’s hands are made out of acid.
Interesting read and a number of very good practices indeed.
Another interesting target audience to design for is children. Would love to read about other people’s experience with that. :-D
One subtle thing I noticed recently, a drill battery charger with keyhole mounting slots in the base, and they molded the hole spacing right into the plastic as “4” (102mm)”. Very simple thing so you don’t have to guess if it’s actually supposed to be 100mm, or track down the instruction book or a paper template. Overkill in that instance (only two holes and the 2mm wouldn’t matter) but the idea could be very useful with a more complicated pattern, or oddball spacing. And trivial to implement on projects that are 3D-printed/CNC carved/laser cut.
Or, you could put a piece of painter’s tape over the holes, poke holes in the tape, and then transfer the tape to the wall you’re about to drill. Another version is a post-it note, or just a piece of paper.
The print matters only if you’re trying to match sets of ready-made parts that may or may not be compatible by standard, one metric and the other in inches. If you can freely drill the holes as needed, the information is superfluous, since it is simpler to not even measure it.
And that is why I said it was overkill in that instance. The point was that you can provide information to the user about how to interface with the object directly on the object itself, rather than making them figure it out. It’s trivial to find the value of a resistor with a meter, but we still have the color stripes.
I’ve learned the color stripes at least four separate times, and I can honestly say I still can’t read them because I keep forgetting the details. I just recognize certain values by how they look – but that’s not reliable because the base color can vary, and the same colors are used for the “same” value in different magnitudes…
Besides, these days the interior lighting is so appalling thanks to LEDs, that certain colors are difficult to tell apart. We tried to teach the color system to a class, but they couldn’t tell gold, orange, and brown apart from each other. Violet, blue, black… they just blend into each other.
I would say, if the information provided requires you to look up other information to decipher it, then it’s being anti-informative. It raises more questions than it answers.
This is most error codes, or technical explanations using task-specific jargon, or referring to other documentation, such as “This part conforms to the ISO 12345 standard”. Great, now I have to go find that standard.
Besides, you don’t have to guess; if you want to measure the distance, measure it between the same side walls of the slots. Assuming the slots are equally wide, the edge-to-edge distance is exactly the same as the center-to-center distance.
It may also be that the information is not correct: that the part is supposed to be 102 mm but actually it is 100 mm because the manufacturing process was off.
Strain reliefs on the wires and cables and make sure the connectors cannot be cross installed with the wrong cable
Oh yeah! Helped out with a project (artificial incubator), where electronics designer had grouped all positive voltages leaving the paper ribbon cable to look like: (24, 5., 0, ground/earth, signal A-G).
The client called complaining: nothing worked. So, supporter flies to South American (they have better laws regarding incubators) and sees, that during transport the ribbon cable had moved and shorted the 24 and 5 volt lines.. thus providing 24 for all electronics supply…
Maybe not truly on topic but, ¯\_(ツ)_/¯.
If you make a manual for something, update that thing every once in while. Because some will hold to it like gospel, and the fact that a setting has moved to hamburger menu, will cause confusion, panic, chaos and frustration for you and them.
Also is something a a standard training guide, include how the finished result should be. Don’t just give instructions without a point of reference.
Exactly. Don’t give a detailled description of the way to go, but a detailled description of how to notice all the ways not to go and the actions and adjustments necessary to get back on track depending on the observed errors and derivations.
Anyone trying to make something completely idiot-proof will underestimate the capabilities of a complete idiot.
Well said
I second this.
Though I am in favour of trying to educate the user, still.
Create proper manuals that explain things, provide background information *why* things are the way they are.
Mention specifications, include schematics. In essence, go bacl to the 70s/80s practice in which detailed manuals were still common.
Even if the majority won’t read them, a few surely will and they will be grateful.
Also, if you’re adding valuable information, you’re on the safe side. Better than the other way round.
Xkcd had that funny strip about tools. Ones that don’t require manual solve problems and those that have manual with first chapter title: “how to read this manual” creates problems. Accessibility might sometimes depend one tiny detail done right during design process.
Interesting.. I was think of something like this: You have gitten a piece of furniture or shelf to be assembled by yourself.
The enclosed “manual” has nice, stylistic step-by-step illustrations included, for the simple minded. So far so good. However, it doesn’t have any textual description. Nothing to write home about, at least. No instructions for assembly.
To people like you and me, this is a problem. Especially if we’re the more of electronic guys and not the handymen. In case of the shelf, were to exactly mount the boards? How many mounting holes do lay between these boards? Or how many screws are included in the package, which type goes installed where? The illustration alone is too vague.
That’s essentially what I meant to express. Oversimplification. The average literature of the 70s/80s wast dumbed down. Manuals had schematics or construction plans on the last pages included. Not a “how to read” introduction on page #1.
*wasn’t dumbed down
You’ve got to remember the average flat pack is designed for a market with 20+ languages.
Pictures with no text are rhe best comprimise
Lego manages to do it, most flat pack furniture manufacturers can’t.
This is the hardest part of my job as a museum curator who often incorporates tech into my exhibits. I now avoid batteries, because even with rechargeable ones, you still need to rely on people remembering to charge and replace them when they wear down. I automate startup and shutdown for electronic devices whenever possible, so no one needs to remember to turn them on or off. I use bold and repetitive instructions for interactive exhibits, to the point that I feel I’m being patronizing, but I remind myself that it really does need to be that explicit. I test and retest and try to break my own apps to find pain points and limitations, even hacking other apps when necessary, and it’s often maddening and takes hours upon hours, and I’m STILL worried something will pop up that I didn’t encounter in my tests. If I find a problem that I can’t fix directly, I compensate for it with additional solutions… often resulting in layers of complexity to deal with new problems that said solutions bring. It’s all rather… well, hacky, I suppose. But that’s the price you pay for innovation.
Fine. But maybe better write down what you did, too. A few notes may already do. In case a successor or temporal replacement must do the job. Losing the overview over something is one of the reasons things can come to a halt. It’s similar to writing code, I suppose. The little comments in source code are often an underestimated value. Anyway, I’m just thinking out loud here, no offense.
“Throw the bone!”
Donald Norman’s Psychology of Everyday Things is a useful guide.
The book title has been changed to “The Design of Everyday Things” for the newer editions.
From the 2002 edition preface:
“As each new technology emerges, the companies forget the lessons of the past and let engineers build their fanciful creations, driven by marketing insistence on a proliferation of features. As a result, confusion and distractions increase.
Remote control of the home is a popular fantasy among technologists. Why not, they muse, call your home while you are driving and turn on the heat or air conditioner, start filling the bathtub, or make a pot of coffee? Some companies offer products that make it possible to do these things.
Why do we need them? Think of how much difficulty the average automobile radio presents to the driver. Now imagine trying to control the various appliances in the home while driving. Ah, the wonders yet before us.”
The philosophy of that book is good, but IMHO the author overdoes things. For example, he criticizes AA batteries because they can be inserted “backwards.” No, that’s the point. It allows the same form factor of cell to be banked in series or parallel. He also seems like a bit of an Apple fanboy at times.
I try to write an operation manual for the devices I make, and that seems to help tease out the bugs in usability for normies. If I reach a point where it’s hard for me, its designer, to describe what’s going on, or what to do, that’s definitely going to be an insurmountable problem for the person using it.
Helpful error messages are good, for both the end user and myself when bench-testing. I try to avoid error codes, because while they’re compact, they are also quite archaic, and remind me of automotive OBD from the 80s and 90s. Error codes also require the user to have documentation about the codes, which they’re sure to lose. The message only needs to be long enough to convey the basics of what’s gone wrong.
Helpful error messages, yes please! None of this “Oops, something went wrong” nonsense that I see from Google.
As for automotive error lights, some cars used to flash their “check engine” light to blink out error codes. While a proper description of the error would be nice, when all you have is an LED, an error code is much better than nothing.
test,new phone,browser update
If it can’t be figured out by a grandmother in 5 minutes and withstand a toddler for 5 days go back to the drawing board.
How very true.
Remember, Mr. Murphy is watching…
Remember O’Toole’s comment to Mr Murphys Law: “Murphy was an optimist”
Didn’t Einstein say that you haven’t really understood something yourself if you can’t explain it to a 6 year old? 🙂
There’s a reason why, some companies test e.g. tablet for military use in Kindergartens. If they can survive people’s offspring, they can survive on the battlefield..
There was a story I heard long ago, so this is from memory, the British Army has a display for kids, and an Armoured Car was open for the kids to crawl all over, after the display finished they discovered that the Armoured Car was wrecked, and in such a way it had to be written off.
As far as aesthetics go, picasso said it best, “When you make a thing, a thing that is new, it is so complicated making it that it is bound to be ugly. But those that make it after you, they don’t have to worry about making it. And they can make it pretty, and so everybody can like it when others make it after you”
During High School electronics my teacher taught us: Always design your stuff for the dumbest person, you can think of. And write your instructions, so the receptionist can operate it: if she can use the instructions, then the trained technician can use them while standing neck deep in mud at 4 in the morning.
The unseen consequence: your receptionist becomes very adept at reading obtuse manuals.
The teacher wasn’t very bright then, I think. Or he associated “the dumb person” with his students, perhaps.
If you encourage that kind of thinking, you lower the mental standard of all of us. It’s a loss/loss situation, I think. Literature should rather encourage people to use their brains. Simple, but clear and detailed speech is one thing, assuming that your reader is dumb is no respect to the reader. Better expect the reader to be smart and let him/her fail. Then he/she must mentally upgrade. This method worked in the 1980s, I think, when computer users were forced to develop a basic understanding (pun intended) of the technology in order to use it.
And this is how people die in avoidable accidents
So, instead of giving clear, precise instructions in the manual, people should write it, so the reader needs to figure it out? Good luck.
I guess, you haven’t worked with expensive machines. Or medical equipment: “I interpreted the manual in such a way, that I Connery 230V directly to the patient..”
I hope, you don’t work with anything more advanced than crayons…
And that is why computer users in the 80’s were considered to be absolute dweebs – nobody else had the OCD to learn the system.
We had a talk by an anesthesiologist from a developing nation. He showed lots of photos of a seemingly primitive OR with about four-deep broken and unserviceable anestheisa machines. Click wheels, touch screens and microprocessor based devices fail in the field and are unrepairable, relegated to boat anchor status. The machine from the 50’s with simple mechanical flow controls and and evaporator is both bullet proof and it’s function is self-evident and repairable with maybe a screwdriver or simply duct tape. I find this design mentality highly instructive.
Human factors designers now directing TV remote software programmers?
Recent purchase of Best Buy $250 then ~$229 now Insignia 50 inch p2160 monitor/tv appears to us ONGOSUS/ONGOTO vectored execution technology.
Adios c/c++ command line user interfaces?
64-bit Intel MCS BASIC-52 gcc transparent portable [x86, arm m and a series, risc-v, …] c uses vectored software executing too.
Fields NamesData Offset
0 Module size: 16 Decimal
1 Smudge field: 40
2 Name length: 64
3 Name: 88
4 Arg stack: 168
5 Arg offset: 184
6 Return stack: 208
7 Return offset: 232
8 code address: 256 Contains physical address of offset 264
0123456789ABCDEF
Rev Sym Reason Date
0 Initial release 5/4/23
Author: William Payne
Checked by: William Payne
8080 fig-Forth VM software technology.
Put the Iron Down: Those cheap little modules from Amazon are your friend. Anyone vaguely technical can replace it with some information, including anyone who’s ever done a car stereo.
Don’t even think about PCBs: Whatever custom PCB you have in mind is probably a bad idea. Unless dozens or hundreds of something will be made, or it simply can’t be done without it, modules all the way.
Power handling stuff hates you: Don’t let any meaningful amount of power run through anything hard to replace. USB-C is great. Definitely don’t do something really silly like using a hardwired 120v power supply nobody can swap because they’re afraid to touch it. Off the shelf class D amps, motor drivers, etc.
Arduino is Good: When you get it working, it usually keeps working. That applies to basically all the Arduinolike platforms.
Raspberry Pi is Mostly Good: You need a read only or otherwise protected root to stop SD wear, and to be sure logfiles don’t fill it till it crashes.
Switches are Bad(Unless they’re Cherry MX): I’ve seen switches fail so often. Especially those cheap Amazon lighted panel buttons. Unless its name brand(Cherry knockoffs seem OK though) and has cycle life ratings, I’d trust Chrome/React/HTML5/Touchscreen, capacitive, radar, or just about any sensing tech besides buttons and knobs users will touch.
New Standards are Bad: Your modular system, brand new web framework, etc, is really cool. Unfortunately nobody else wants to learn it, making it a liability until you convince others to do so. Even then, it’s probably a liability, if you could have just used the existing thing.
If it works once, that doesn’t mean it’s good: Whenever specs say one thing and tests say another, trust the specs. If you can’t trust the specs you have a bad product.
I don’t care if putting 5v into a 3.3v circuit seems fine, it could fail at any time. Fix it. Make sure you don’t have LC input transients when you switch it on. Check all those odd edge cases.
Any idiot can design using specs, only someone with real understanding of exactly how devices work can guess when it’s OK to bend the rules. I’m not that someone and if you are, it’s very hard to prove, only similar geniuses will be equipped to review your work.
Assume failure at every step of assembly and use:
Once at a wedding I had built a custom lighting device for a special effect and put the battery in wrong. It was fine because I had reverse protection for exactly that reason.
Most engineers like to think in terms of beauty, simplicity, and excellence. I think in terms of failure. My goal is to make it so that even my failures in the design stage don’t translate to notable real world effects. For every step, look at how it could be done wrong. Look at it like a hacker. How would you sabotage the assembly process? How would you sabotage it once installed? Better make sure you can’t break it by plugging -9v from a guitar pedal supply into it when the band plays and leaves it behind. Maybe it even needs waterproofing.
Even when designing for yourself, it’s worth remembering that after a year of not using the item you may not remember much about how the item works. So unless you’re going to be using the item regularly, some user friendliness makes sense even for your own sake.