Page 1
Standard

Why product design is like writing a recipe

While reading a cookbook recently I realized the goal of the cookbook author is not entirely different than a product designer. In both roles, the designer and author, there is a need to anticipate the needs and knowledge of the user, and design around those needs within the constraints of their knowledge.

There is also a parallel here between the engineer and the professional chef. Both have much more knowledge than the end user, and rarely understand how their user will be using the product they are creating. If you’ve ever read a cookbook actually written by a professional chef (as opposed to a professional cookbook author), you’ve probably not understood many of the terms or known what many of the ingredients were. If you did understand everything, then either you’re either an experienced chef, or the book was likely co-written with a writer who specializes in cookbooks.

User-Focused Design

It’s not that different with engineers working on a product to be sold to consumers. If you’re a computer programmer selling a product to a computer programmer, maybe you can get away with designing it. If you’re a computer programmer selling to a consumer, you probably need someone to guide the development of the product so it anticipates the needs of the user.

Diagram of the CL-9 CORE remote from a patent filing
Diagram of the CL9 CORE remote from a patent filing

One of the products that sticks out in my mind in this regard is the first product Steve Wozniak worked on after he stopped working for Apple. He left Apple to start CL9, the company that made the first universal programmable remote control (called the CORE). Many of the useful features developed by him back in the mid-to-late 1980s are still hard to find in remote controls today. The remote was built with essentially the same processor that was in the Apple II, also developed by Wozniak. The remote had 16 primary thumb-size buttons that could be programmed to control multiple devices, so a single button could turn on the TV, the VCR, and then start recording. The remote had 16 layers, allowing for 256 possible actions (16 buttons in 16 layers). The remote could even be programmed to activate a specific button’s programming at a specific time (i.e. start that above recording sequence at 6pm).

To keep the settings and time in the remote, there was a coin-battery soldered to the circuit board. If the battery ever died, however, you needed to have it de-soldered and a new one soldered to the board. If the battery ever lost charge, you needed to connect the remote to a computer though a serial cable and re-load the firmware. The keys did not correspond to standard remote functions, but in keeping with its ‘universal’ concept, the keys were labeled in hexadecimal (i.e. 1-9 and A-F). These issues, in addition to it’s cost (over $300 I believe) and the fact there were other simpler ‘universal’ remotes introduced around the same time, drove the company out of business before it ever really got started. I don’t know who decided that hexadecimal was a good user interface, but it seems clear general users were not really considered during the design process.

When writing a recipe to be placed in a cookbook, the author needs to think about who is reading the recipe. It could be the recipe is in a professional cooking textbook geared toward culinary students, but in most cases cookbooks are geared towards the average home chef. That means that the terms used need to be well known, and anything unlikely to be known needs to be explained. If the recipe is for an ethnic dish that uses ingredients not normally found in the supermarket, the recipes needs to explain what the ingredient is, and hopefully explain where it can be found.

Jargon

"Noomi Basra"
“Noomi Basra”

As an example I can use an ingredient found in the cookbook I was just looking at, which the cookbook author refers to as Noomi Basra. She does explain that these are dried limes, and that they can be found in Middle Eastern markets. She also explains how to prepare them. One interesting thing about Noomi Basra, which I know because I’ve looked for them, is that they have a different name depending where you are. If you went to the average Middle Eastern store and asked for Noomi Basra (Lemons from Basra) they probably wouldn’t know what you’re talking about because that’s only the name used in Iraq. In other Arab countries it’s referred to as Limoo Omani (Limes from Oman), and in Oman itself simply as Loomi. In Israel they’re referred to as Limon Parsi (Persian Lemon). In the US they are most likely known as a Black Lime or simply as a Dried Lime (although in a Middle Eastern market they may be known by one of the above names). As an aside, even though some of the names refer to them as lemons, they are always limes. Another thing a cookbook author should do when using hard-to-find ingredients is offer alternative ingredients that may work as substitutes when the reader cannot find the ingredient.

Do you know what Mirepoix is?

Another problem in recipes is the use of terms for other recipes. For example, when an ingredient listed is something like Mirepoix or Demi-Glace. These are not ingredients, as much as other recipes chefs are expected to know and make separately. These terms may be outside the knowledge space of the reader, and should be explained.

In a similar vein, culinary verbs such as julienne (to cut in long thin slices) or brunoise (to julienne and then turn 90 degrees and cut again into small chunks) must be explained, if not in the recipe, then in a glossary. Obviously not every term and ingredient needs to be explained, but finding the cut off of what to define and what not too requires testing the book on readers outside your normal comfort zone. If you’re writing a book on French food and only show it to experienced French chefs, you’re not going to get the feedback you need.

Specialized domain-specific terms are known as jargon, and the world of technology is filled with such terms (just like the culinary world). If these things are not explained, it’s because the author makes assumptions about the knowledge of their reader. Similarly product designers many times make inappropriate assumptions. Product usage assumptions can run the gamut of thinking the usage is obvious when it is not, thinking the user will read the documentation, and assuming your user will use the product in a specific way, when they might assume it is meant to be used a different way.

Making the wrong assumptions

In Israel there have long been only two options for getting lots of TV channels. You could get service from HOT (the country-wide cable company) or from YES (the country-wide Satellite TV company). Recently a third option came into existence, called Cellcom TV, from a cellular phone company. Cellcom’s option operates over existing Internet infrastructure (which ironically is either using the cables of HOT or YES’ largest shareholder Bezeq, the landline phone company). Cellcom can install a cable box that has an okay selection of channels (although no where near as extensive as HOT or YES).

Now imagine this is across the room from you and you need to pick a channel

Once set up (which you can almost guarantee will require multiple visits from Cellcom and your Internet infrastructure provider) you are left with a very advanced cable box with a very simple remote. The box lets you select channels, or review video-on-demand options, or use various Internet applications such as YouTube. Very advanced, however, doesn’t translate into very easy. The remote has no numbers on it, so in order to select a channel you need to press the menu button, select ‘Channels’ and then use the directional buttons to move over a grid of tiny channel logos until you find the channel you want, and then select it. You might have to press a dozen buttons to change the channel. You can’t even keep a few favorite channels in easy reach.

It is possible to use the channel up and down buttons, but how do you know what is up and what is down if there are no numbers? In addition, there is no pause in using the up and down buttons, so you can fly past several channels without even seeing what they were. Someone working at Cellcom was thinking that using numbers is an old method that isn’t necessary with today’s interactive user interfaces, but didn’t think through what removing the use of numbers meant for users.

Making sure to have the correct use cases

Imagine setting up this television service for an elderly person who is used to simply entering the numbers of the channels they want to watch. Now they need to remember which button pops up the menu, which menu item to select, where the channel icon they want is located (possibly off-screen and requiring scrolling down to see), and they need to pick from logos of channels so small even a young person without glasses would be hard pressed to identify them all. An elderly person might also want to look up programming in the TV listings in the newspaper, but without numbers it’s hard to know which channel they are referring to when they say something is on.

The product designers behind the Cellcom TV box were obviously not thinking about the above use case. Perhaps they were focused on young millennials that were more likely to switch from the existing providers, and who would be more appreciative of the Internet features in the box. Evidence of this comes from the fact that for the menu button they use the 3-bar icon (nicknamed the Hamburger) commonly used in mobile apps and web sites to represent a menu.

Aiming for perfection

When designing a product, or writing a recipe, the goal is the largely the same. You want the end-user to be able to user your product, or follow your recipe, with as little help as possible. The ultimate product design is one that is so obvious in its operation that it requires no documentation at all. In a recipe, you want to make sure that there is no confusion over what to do in each step (ever seen an ingredient referenced in a recipe step that wasn’t listed in the ingredient list? or seen an ingredient mentioned in the ingredient list that is never mentioned in the instruction?).

Recently I was working with a software developer on a product I was designing. He was 100% certain that the product would be used a certain way, when in my mind that was only one out several ways it might be used. The product was going to be installed by less-technically-skilled people than we would have liked, so covering all the bases in what might go wrong was critical. He had come up with a usage he thought optimal, and had ignored any other possible use cases. One could argue on how he came to that conclusion. Perhaps the specifications were not detailed enough (my fault), the communications between me and him broke down (with several other people in the mix), or he ignored specifications and communications and did what he thought was right (which could be arrogance like the architect, inexperience, or simply laziness). I believe it was a mix of all of the above.

The end result, however, was a product that in several non-trivial cases simply failed. When these failures were pointed out, the developer answered that if they did things the right way (i.e. the way he decided was best) those would never happen. Needless to say, or perhaps not so needlessly, you should design flexibility into your products so diversions from the intended path don’t cause it to fail. That’s why thinking through use cases and doing sufficient product testing with members of each use case is so important. In this product, those failures were fixed, and the product was made so it would never fail (rather it would try to fix problems that arose automatically).

Designing a product takes some imagination both in how the product should work and who will be using it, needs product testing with multiple user types, and the willingness to change what you originally envisioned to make it usable by the people who will actually be the end users.

The end
The end
Aside

High lights and design

Recently while driving down the highway I noticed a crew changing lightbulbs on a street lamp. This particular street lamp was one of those extra-high poles with the circle of lights around the top that you see only on highways and some industrial or sports complexes. I had occasionally wondered why the transition was made to those poles that were double or triple the hight of standard street lamps. My assumption was that being higher they provided a larger spread of light, and they could be placed in the median so they could provide light to both sides of the highway. However, as I knew street lamps had their lights changed by crews with cherry-pickers, I wondered how these high poles whose heights were clearly beyond the reach of a normal cherry-picker had their lightbulbs changed. The answer to that question was now answered, but more on that in a moment.

Seeing this crew change the lightbulbs reminded me of two homes with the same issue. Both homes had living rooms with high ceilings, which were very nice, but had the same practical issue – changing the light bulbs was difficult.

In the first home, the lightbulbs were standard Edison-screw bulbs, in spotlight style with flat tops. In order to change them, you pulled out a telescoping pole with a suction cup on the end. You extended the pole and attached the suction cup to the bulb. You then rotated the pole until the bulb came out of the receptacle, and lowered the pole to remove the lightbulb. Then you did the reverse, attaching the new bulb to the suction cup, lifting the pole and inserting the lightbulb into the receptacle, and rotating the pole until it screwed in all the way. The process was a bit tricky, but not impossible.

In the second home, which I was involved in renovating, there was a row of lights at the highest point. These light fixtures were embedded into a design element built out of plasterboard. Remembering the first home, I asked the architect how you changed the lightbulbs which were clearly out of reach, even with a ladder. He explained to me that each bulb was held in by a frame that needed a screwdriver to remove, and that the only practical way to change the lightbulbs was to bring in scaffolding and stand up there with a screwdriver to take out the frame, then replace the lightbulb, then add back the frame. You’d then need to move the scaffolding a few times to reach all the lightbulbs.

Form over function? I was in shock. While design is important, how could one install lighting into a home that no homeowner could change on their own? The architect was perhaps a bit arrogant, wanting his design to be perfect and not taking into consideration such practical matters. What happened next truly threw me for a loop. After I had discussed the issue of replacing the bulbs, the design element that the lights were embedded into had to be changed. While the architect clearly was not going to change the lights after they were installed the first time, when the whole area had to be redesigned and reinstalled (I forget the reason, but I seem to recall it having to do with the air conditioning) I thought for sure he would change them to something more practical. Nope, same crazy lights.

So with all that in mind it’s not hard to figure out why this crew changing lightbulbs on the highway reminded me of these two homes.

So how do these road crews change the lightbulbs on a pole so high no cherry-picker can reach it? The crew lowered the lights down from the top on a series of cables. Presumably they simply opened a panel at the bottom of the pole and pressed a button, lowering the lights using a motor built into the pole. When they’re done changing the lightbulbs, they just press a button again and the lights head back up to the top of the pole. Brilliant. Not practical for a home lighting installation, but perfect for highway lighting.

The end
The end