Follow the Recipe

By Ron Gagnier

Published: May 25, 2009

“Following a software design process can offer the same kinds of benefits you gain from following a recipe when cooking: getting reliable results.”

There are many good processes for software design. By process, I mean a prescribed way of performing software design. Every software company I’ve ever worked with has a design process they’ve adopted or created to meet their needs. However, after working on numerous software projects, I have come to realize how few projects actually follow their companies’ intended design processes. Why is it that so many companies don’t follow their existing processes for software design?

Following a software design process can offer the same kinds of benefits you gain from following a recipe when cooking: getting reliable results. For example, if I have a recipe for gingerbread, but I don’t follow the recipe, should I still expect to get gingerbread? It depends, of course, on how much I choose to deviate from the recipe. Could I substitute whole-wheat flour for white flour? Sure. Could I substitute cardamom for ginger? Hardly. Could I substitute honey for molasses? No. Could I cook the gingerbread at 400 degrees instead of 350? Maybe. Would the result be something I can recognize as gingerbread? The answer: It depends.

Examining a recipe closely, we can see it is divided into two distinct types of information: the ingredients and sequential steps. The list of ingredients comprises everything that should go into a dish. The steps document the actions a cook must take to prepare the dish. Both types of information are equally important to achieving the desired outcome. The same is true of a software design process.

One might describe a software design process this way:

Ingredients:

  • users—people who will use the product
  • stakeholders—people who have something at stake in building the product—like purchasers, supervisors, installers, developers, or marketers

Steps:

  1. Obtain requirements from users.
  2. Obtain requirements and constraints from stakeholders.
  3. Measure requirements against constraints.
  4. Mix requirements thoroughly.
  5. Knead requirements into designs.
  6. Let the designs rise with the development team.
  7. Validate the initial designs with stakeholders and users.
  8. Add lately discovered requirements.
  9. Knead the designs again.
  10. Let the designs rise with the development team.
  11. Repeat steps 7–10 until the requirements gel.
  12. Bake the designs with the development team until golden brown.
“In both cooking and software design, reasons to deviate from a recipe include lack of ingredients, lack of resources, time constraints, conscious choice, and lack of experience.”

Every software design process includes users and stakeholders. Steps may vary somewhat from process to process, but generally, an iterative software design process follows the same pattern I’ve just outlined. So, why deviate from the recipe? In both cooking and software design, reasons to deviate from a recipe include lack of ingredients, lack of resources, time constraints, conscious choice, and lack of experience. Let’s discuss each of these in more detail.

  • lack of ingredients—If an ingredient for a recipe is not available, a cook can either substitute something else or omit the ingredient altogether. In software design, a similar situation could occur if users are not readily available for some reason. While it is possible to omit user input from the design process, there would then be little way of knowing whether the product will satisfy users’ needs. Instead of omitting users, it may be possible to substitute surrogate users. Surrogates are people who have direct working knowledge of the tasks real users perform and the goals they want to achieve. You might use support personnel, trainers, or product installers as surrogate users. While using surrogates is a less desirable option than using real users, at least surrogates can provide more information than you would obtain if you omitted the ingredient completely.
  • lack of resources—If you’re missing a needed resource, you can use an alternative technique to complete a step. For example, in cooking, if you don’t have an electric mixer for mixing ingredients, you might be able to use a whisk instead. In software design, if there are no available personnel who are experienced in using a prescribed technique—for example, job shadowing—it is possible to substitute another technique to complete a step—for example, structured interviews.
  • time constraints—Typically, in both cooking and software design, time constraints exist. Dealing with time constraints in the kitchen requires forethought and careful scheduling. This is also true in software design. (I once heard someone refer to the preparation of a catered banquet as a ballet with plates.) As we all know, crises often occur at the least opportune times. In software design, people may not be available when you need them, requirements and priorities can change, or schedules can slip.
“What techniques will save you time? Those techniques you know best, with which your team is familiar, and for which the necessary resources are available.”

When you need to make up time on a project that’s running late, it may be necessary to substitute techniques that are less time-consuming than those you’d originally planned. What techniques will save you time? Those techniques you know best, with which your team is familiar, and for which the necessary resources are available.

Whenever I am pressed for time, I still try to follow the software design process I described earlier, but I choose to do whatever I can remotely. I may do telephone interviews rather than face-to-face interviews or site visits. I may choose to do usability studies using a conferencing service such as WebEx instead of doing them in a lab. With only a small drop in the quality of my results, I can save lots of travel time. Of course, some techniques—like job shadowing—you cannot do remotely.

You can also save a great deal of time by doing low-fidelity prototyping—perhaps paper prototyping or wireframing—because you can do design iterations quickly once user validation has begun.

  • conscious choice—If a cook knows enough about a recipe—both its ingredients and its steps—to know the probable outcome of a substitution, choosing to be creative may work out just fine. The proof is in the pudding, as the old saying goes. This is true for both cooking and software design. Experience with a recipe is the key to knowing the potential outcome of substitutions.
  • lack of experience—Misinterpreting a step, using an inappropriate technique, or, more often, not completing a step adequately might result from a lack of experience. For example, the batter for a cake might not be thoroughly mixed, and a new cook may recognize his error only once the cake is baked. Luckily, most design processes have built-in checks for such problems—called usability validation. The user community validates designs, verifying that they meet their needs and goals. Unfortunately, there is little a team can do to recover if that is the step that gets misinterpreted.
“Experience lets a cook or a designer know how the substitution of an ingredient or technique will affect the outcome.”

There are situations in which we must substitute ingredients and techniques—both in cooking and in software design. What can help us make the right substitution decisions? Experience! Experience lets a cook or a designer know how the substitution of an ingredient or technique will affect the outcome.

Professional cooks make the same dish countless times to perfect a recipe. The software design process does not provide us the luxury of doing numerous trial runs, using the same process on one project. The cost of doing so many design iterations would be prohibitive—in both time and money. Trial runs let a professional cook gain knowledge about which ingredients and steps are fundamental to a recipe and which are less significant. Trial runs give a professional cook the opportunity to make bold substitutions simply to learn from them. It takes experience to recognize where substitutions will work and where they won’t. Sous-chefs often work under a chef for many years, until they gain the skills and experience they need to build artful recipes.

In case you’ve never really given much thought to substituting ingredients in a recipe or substituting techniques in a design process, I offer these brief guidelines:

  • Follow the recipe. Regardless of the design process your team uses, the more closely you follow it, the more likely you will achieve a good outcome. Everyone on your team should be familiar with the process and buy into it. Deviations from the process can lead to misinterpretations and potential confusion. Time and energy went into choosing or adapting a corporate design process. If you anticipate encountering problems on a project that will prevent your following the process—perhaps for one of the reasons I’ve given—discuss this with your project team at the start of the project. If a problem arises mid-project, discuss any deviations you need to make from the process with the project team.
  • Experimentation is not for banquet night. A chef wouldn’t experiment with a soup recipe on the night of a banquet, nor should you try new techniques during an important project. Try developing and practicing new techniques outside your projects—or, if you must try using new techniques during a project, at least use them on less critical areas of the project or use them in parallel with known techniques. Partner with someone who has experience using the technique you would like to learn. Whenever possible, experiment with new techniques in a safe, low-risk environment.
  • Stuck? Ask an expert! If you need to substitute a technique, but you’re not sure how to do it or which technique to use, why not ask an expert? Post a question to UXmatters, attend a local SIGCHI, Usability Professionals’ Association, or IxDA meeting and ask a question. Experts are everywhere and often are very willing to help. If you are desperate to have someone you can learn from, try hiring a UX consultant who has experience using the techniques you want to learn for the duration of a project, then watch and learn.
“Build your own expertise through experience.”

Build your own expertise through experience. Learn by taking courses, attending seminars, joining special interest groups, and talking with other designers. Courses often offer the opportunity to practice new techniques. There is nothing better than hands-on learning in a risk-free environment. You’ll gain both experience and confidence.

I may have taken my analogy of following a recipe too far, but I really do think the comparison is a valid one. Recipes exist to ensure cooks can acquire the right ingredients, follow a sequence of predefined steps, and prepare a dish consistently every time.

The same is true of a software design process: By following a design process, an entire project team can know what steps to perform and what they’ll deliver. When your team must make substitutions, let experience and sound judgment guide you in making the most appropriate choices. Continue to learn and grow in your role as a designer, because this will help you make better substitution decisions. When in doubt, ask an expert for help or guidance. Following the recipe is the way to a consistent outcome that your entire project team will be happy with.

5 Comments

Delicious metaphor. Especially for small teams. Useful if all collaborators fully understand and agree to the recipe—process+ingredients+expected result—entirely. Safe to assume this, though? Not everyone wants a hamburger or chicken tetrazzini. In business, normally, only a unique recipe—that is, strategy—will do. Following a recipe is one thing. Creating one is another.

Preferring theater metaphor, instead, these days, because it involves interplay of scripted and improvisational modes; the expected and unexpected, plus stage and backstage. See?

Really, though, to define the outcome completely before cooking will fare consumers well.

Hi Ron. What a great article. Firstly, reading metaphors can be tiresome—and sometimes, it’s just beating around the bush—but this one works for me. Secondly, I find this to be one of the major challenges or obstacles in UX or usability work. How to get people to know about the recipe and how to follow it. Which is also why it’s often meaningless to talk about methods, because there is an initial lack of understanding of the recipe—whether this means process or goal.

One thing I’d like to add is: Like in cooking, many people are happy with less quality. You can buy and cook cheap pasta in a sloppy way, and to many people, it will still be fine pasta. The fact that the dish could be many times better, only by doing things in a more organized maner, is less relevant to these people. They still had their pasta.

Is that lack of experience? Not entirely. Is it conscious choice? No, it’s more like unconscious.

It’s basically quality, which, both in cooking and in IT, is a wierd, flimsy size.

Very nice analogy of using recipes for chefs and the process of UC design of Web apps.

I think the analogy with gastronomy and culinary arts goes even further for UX designers. Think hospitality, presentation, and memories.

As a pet project, I have collected some Web gems related to this analogy: FoodUX.org. For inspirational purposes only.

Thank you for the comments. I enjoy hearing what others have to say.

First, I�ll address an assumption I made in the article that a recipe or process should be in place that every team member is familiar with and respects. But what if that is not the case? As several of you have pointed out, the issue of familiarity and respect for process is still the biggest challenge to UX design today. How do I get buy-in for the recipe?

I don�t intend to fully answer the question here, as those ideas and opinions would probably spill into a lengthy treatise best left for another time. The analogy I put forth in this article could be a point in a bigger discussion about learning from industries that have had more time to mature. Following a recipe in the food industry does not seem like much of an innovation, but the idea of following the same steps and using the same ingredients to get a consistent outcome has certainly served the food industry well. The recipe analogy is one that can be used to bolster support among team members. While I have not had the opportunity to try using this analogy yet, others have served me well in my efforts to make a case for sound, repeatable processes. While no process or recipe eliminates the need for communication, consistency of output is everything. The proof is in the pudding, as they say.

Second, quality is in the eye of the beholder. As much as the UX community stresses the importance of excellent design practice, business typically responds to what it hears from its customers. I have worked in situations where usability was not the highest priority for customers. While users most certainly could have benefitted from better usability, it was not something they could articulate or perhaps express an opinion about—at the time. Again, business typically responds to what it hears. This should not be taken as bad news. The Internet provides customers the ability to do much more comparison shopping and try before you buy than ever before. I feel, in the years to come, whether or not customers can articulate usability as a factor when choosing software, instinctively they will choose better design. Voting with your feet is a most effective way of getting a point across to business. I continue to be optimistic.

I really like the recipe analogy. I’ve been on software projects where people not only didn’t have the essential ingredient of user input, they didn’t even realize it was missing and didn’t even attempt to substitute something else for it!

Join the Discussion

Asterisks (*) indicate required information.