Some may not be too familiar with Heathkit, the original DIY Electronics kit maker that can trace its roots back to an aircraft company created in 1911 by Edward Bayard Heath. The aircraft company went bankrupt when Heath died in 1931, but was reborn as an electronics supplier when Howard Anthony bought the Heath company and name.
Heathkit was the dominant electronics kit company for most of the 20th century, creating radio kits during the amateur radio years from the 40s to the 70s, and later other electronics and computer kits during the early computer hobbyist decades of the 70s and 80s.
Heathkit stopped selling kits in the late 1990s and filed for bankruptcy in 2008, but never closed its doors. In 2013, they emerged once again as an electronics kit provider, selling their signature DIY electronics projects.
I hope the new incarnation of Heathkit lives up to the older one, which for me set the bar for how a company invests in making their customers succeed. Their motto has always been “We Won’t Let You Fail”, and in my experience in the 1970s and 1980s with their products, I found it to be true. I built many of their kits and despite my questionable electronics knowledge and soldering skills of the time, never ended up with a brick.
What does this have to do with UX design? Everything, if you consider the broader definition of “user experience” that simply means, making sure your users are successful and satisfied. I eventually ended up working on software user interfaces of various sorts over the years, and I’ve kept in mind some UX lessons I’ve learned from Heathkit.
Throughout the 70s and 80s I built (or helped build) various Heathkit projects, including an alarm system cleverly disguised as a book, a wind-direction/wind-speed weather station, and (helping a neighbor) eventually the ET3400 Computer Trainer, which was an early Heath’s foray into computer kits.
I still remember how exciting it was when we finished the ET3400, and turned it on and saw the LED display reading “CPU UP”. It was always very satisfying to finish any kit and see it come to life after all the effort and care you put into building it.
When I graduated college and started work, one of my early paychecks went to Heathkit, to buy the HERO Jr Robot. My alarmed family gently reminded me that I should also consider actually getting out and meeting other people and not stay in my new apartment building robots, but for nerdy me this was a very high priority, given how long I’d spent ogling things I could not afford in the Heathkit catalog.
I did leave the apartment and meet other people eventually, but not before completing this (as it turns out last) Heathkit project. I named the robot “Shithead” (my elegant way with words obviously goes way back) and assigned it the duty of keeping my cat Donovan in line. The cat was named after the singer of the song Mellow Yellow, because he was both similarly tempered and colored, but he also had the unfortunate habit of sharpening his claws on the drapes.
Shithead was outfitted with a squirt gun powered by an electric motor which was connected to a relay and wired to the only spare channel of the Hero Jr remote. I could pilot the robot into the living room and target the cat remotely when he was getting near the drapes, and eventually, just the sound of it entering the room would deter his bad behavior. All in all, I think the robot ended up more like a Dalek than the vaguely R2-D2 styling Heathkit was going after.
Yeah, a scratching post probably would have been cheaper. But then I would not have had the joy of building this great project and getting it to work! This is where we finally begin to talk about UX design. User experience is frequently associated specifically with user interfaces for hardware or software, but by definition also covers the entire experience a user has when interacting with a product, from start to finish.
Heathkit took user experience seriously. This dedication to customer success manifested itself primarily through Heathkit’s instruction manuals, which were incredibly detailed and well-thought-out. Heath’s manual covered not just how to build their kits, but also how to troubleshoot and fix them if something went wrong.
“Shithead” for instance had issues. In my excitement to get it finished, I rushed through the build and ended up installing some components incorrectly, and the robot did not initially work. Since there wasn’t exactly a robot repairman I could call, the project would have been one expensive end-table if I could not fix it myself. Luckily, Heathkit was there for me.
The documentation for the HERO Jr contained detailed schematics and test measurement points, and information on what voltages and signals should be present on the various boards of the robot. This allowed me to narrow down the problem to a diode installed backward, something easily corrected. When I reinstalled it the right way, the robot sprang to life. I was delighted! Donovan was not.
What UX thing I learned here is something about taking into account the idea that your users make mistakes, and even if those are not your fault when creating a product, doing something to help them is always appreciated.
For various reasons, I did not build many hardware projects for a while after that, (probably because I was getting more than my share of hardware projects at work), and I kind of lost track of Heathkit. They were bought by Zenith and tried to sell computers, with the same results as Radio Shack: eventual bankruptcy.
I continued to think about Heathkit long after they had disappeared as a company, especially later in my career when I was working on things like user interfaces for software we were developing at work. I have zero formal training in user interface design and probably should not have been allowed to make unilateral decisions about how parts of our GUI looked.
The same goes for writing user documentation, I am not a Tech Pubs guy but often find myself doing it. These situations seem to crop up often in my career, when products need to get out, the right people to design interfaces or write docs are not around, and R&D is left to the task.
In these situations, I do my best, and often take inspiration from what Heathkit has taught me. Here are a few of those ideas I try to keep in mind when creating something users will interact with.
Even though the majority of Heathkit’s customers were probably experienced builders, they would always take time to include basic instructions for beginners, such as soldering technique. Experienced builders could just skip right over that page, it was never really annoying to see information you already know in the instructions.
There is an expert-friendly UI design school of thought that goes “you are only a novice once”, suggesting it’s OK to create software that is hard to learn if it makes the experienced users more productive. I don’t buy this. If Heathkit taught me anything, it’s that Novice and Expert friendly do not have to be mutually exclusive. You can have tutorial modes and tool tips and basic versions of a UI for beginners without sacrificing expert productivity, for instance.
And these novice-friendly modes are worth investing in creating for your product, because although your customers may only be a novice once, that once is the first impression that will decide whether they come back again and again to your product, or move on to someone else’s.
This one seems super-obvious. But is it? I’ve gotten into arguments with other developers at work in the past about whether or not we need to make a feature available in more than one way — say on a menu, even though there is a key binding. Or on a toolbar button, even though the feature is also on a context menu.
The idea of streamlining user interfaces and reducing clutter is valid, and it is definitely possible to add too many buttons to something. But typically I see the thinking go the other way when an R&D guy designs a GUI. When coding, redundancy is a no-no, so having redundant ways to do things in a UI is sometimes avoided too much by a developer-turned-UX-designer. But people are all different. There are key-binding people and menu people and toolbar people out there, and providing a range of options for a function is useful, even if they all do the same thing.
Where Heathkit comes in here is again, with their instruction manuals (which are essentially their user interfaces). I was always impressed for instance that they would supply redundant circuit info, such as illustrations of an assembled board, X-Ray views of the traces of the board, schematics of the board, silkscreened information on the board itself to locate components, and written lists of components and test-points.
A subset of these only would be needed just to assemble and test their kits. But by providing more than they needed to, they enabled a wider set of customers to succeed with their products.
Heathkit’s assembly instructions were very extensive, often 50 pages or more, sometimes with small helpful illustrations inlined with the assembly checklist. They always contained some beginner-oriented material as mentioned previously, but also even within the assembly portion of their manuals, the text descriptions were very detailed and comprehensive. (If there was an opposite to an IKEA instruction set, it would be Heathkit)
If you knew what you were doing and had no issues, probably a lot of this material could be considered superfluous. But even an expert builder would run into trouble sometimes, and having a highly detailed set of documents to describe how things should work greatly benefits beginner and expert alike, even if there is redundancy there.
I know for instance I would forgive a lot of repeated or long-worded descriptions of how a product works, if the documentation succeeded in helping me use the product the way I wanted to. As long as the information is not conflicting or confusing, I think what I took from Heathkit was that you really can’t have too much documentation, and I try to keep that in mind when writing user documentation myself, being generous with descriptions, examples, and details.
Finally, I would highlight the Heathkit motto of “We Won’t Let You Fail”, which should in truth be the motto of every company. Heathkit almost always included detailed troubleshooting instructions and test information for their products, and as a last resort even offered a repair service where you could send in your botched project to be fixed.
It wasn’t like Heathkit was the only company to create DIY kits, they had many competitors over the years. But what made them stand out was the mindset they had about what they were selling. It wasn’t just that they just sold DIY kits. They sold the experience of successfully building them.
There is obvious wisdom in that idea of selling the experience of success to customers, and not just a product meant to achieve it. And that philosophy can be applied beyond the world of DIY hardware kits to the software world as well. We could for instance talk a bit about how the troubleshooting part of Heathkit’s manuals has analogs in software having to do with producing better error messages and input checking for user interfaces. (Certainly a good topic, probably worth another article.)
But the customer success experience idea is something that spans beyond just one thing like handling user errors. It is about making things easy to learn, and useable by a wide variety of people with different preferences and levels of experience. About going the extra mile to explain things, and not making assumptions about whether or not someone already knows what you are talking about. It’s about being there for your customers when things go wrong, and providing ways for them to get back on track.
Maybe Heathkit will grow and regain (or even surpass) their former glory, or maybe not. Whatever the case, these lessons we take from their past are valid ones, and worth repeating. Also I do kind of hope Heath gets around to making a new robot. Because I have another cat, with a few bad habits.