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.
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
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.
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).
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 use 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 instructions?).
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.
