Follow the Recipe

May 25, 2009

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.

Champion Advertisement
Continue Reading…

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:


  • 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


  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.

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.

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.

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. 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. 

User Experience Designer at IBM

Ottawa, Ontario, Canada

Ron GagnierRon Gagnier has been a UX designer for 14 years. He earned a BSc. from Carleton University’s Human Oriented Technology lab and developed his design and research skills both as a consultant and as a team member within numerous technology firms, including Nortel, Macadamian, Halogen Software, and IBM. Over the years, Ron has worked in many roles, including usability specialist, interaction designer, user researcher, and information architect. He is a member of UPA and CapCHI, and involved in the Ottawa Usability Consortium. When he is not working on a challenging design problem, Ron is a guest lecturer at Algonquin College, where he teaches design and usability.  Read More

Other Articles on Design Process

New on UXmatters