Follow the Recipe

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.