Steering User Cognition Through the Design of

Interface
A New Design for Recipe Selection
 Table of Contents

Executive Summary Page 3

Section 1: Definition of Setting & Project Scope Page 5

Section 2: Fieldwork activity and data collected Page 6

Section 3: Sequential Work Activity Model Page 7

Section 4: Requirements & Goals Page 9

Section 5: Conceptual Design Page 10

Section 6: Page Design & Prototypes Page 16

Section 7: User Feedback Page 30

Discussion Page 34

2
 Figures

Figure 1 Page 8

Figure 2 Page 8

Figure 3 Page 9

Figure 4 Page 9

Figure 5 Page 16

Figure 6 Page 17

Figure 7 Page 18

Figure 8 Page 19

Figure 9 Page 20

Figure 10 Page 21

Figure 11 Page 22

Figure 12 Page 23

Figure 13 Page 23

Figure 14 Page 24

Figure 15 Page 25

Figure 16 Page 26

Figure 17 Page 27

Figure 18 Page 28

Figure19 Page 29

Figure 20a Page 30

Figure 20b Page 31

Executive Summary

This project began with a specific aim of developing an improved interface with which to
select and prepare recipes, but with no specific format in mind. We collected data from
seven different users through interviews and observations. . Users studied primarily
ranged from 18 to 24 years old and were at the novice level in terms of cooking
experience. Interviews were given to three subjects and audio recordings were made in
each instance. We performed three observations following our interviews and compiled
qualitative data from the observations (see Appendix B). Two observations followed
users through the search process in obtaining a satisfactory recipe while one
observation followed the user through a preparation process. In each observation the
observer remained as unobtrusive as possible asking necessary questions through the
process and providing no direction. We found through data collection our users followed
a 4-stage process in the selection and preparation of a recipe. The four stages are:
Recipe selection, recipe preparation, recipe making and recipe finish. In each stage, we
were able to model the user’s cognitive and physical processes through our interviews
and observations. A conceptual design was then created to group the gathered user
data into a logical flow of use. Starting with the homepage, the use case of a user
finding, choosing, preparing for, and executing a recipe was used. We then moved
through a process of creating initial and secondary prototypes using both Balsmiq
Mockups software and Axure. We used Axure for our final set of prototypes for the
usability studies. We used these prototypes with two separate users as a usability
testing procedure. The users were given a series of salient scenarios with which to
provide feedback. We used two users under the age of 21 and put them through a
number of chosen scenarios. Each user provided us with detailed feedback on both
positive and negative aspects of the product. Positive aspects included the use of a
timeline to indicate the time it would take to make the recipe from the beginning to end,
the idea of instruction for the recipes, the concept of the design, the illustrations and the
idea of adding multimedia to the site. The users did not like a number of aspects of the
interface, did not understand the concept of a prototype, and did not care for some
aspects of the design to include a “grocery list.” We began with a simple idea of
developing an improved method of recipe selection and preparation to take shape in the
form of a web page or mobile application. Based on our data, we moved forward with
more than a simple web page, but a product designed to steer the cognition of our user
through the interface. We ended with a prototype that is a step in the right direction, but
a work we feel would require further investigation and study as well as more collection of
data from users.
Section 1: Definition of Setting & Project Scope

The project essentially began with a very simple idea of improving the process of
selecting and preparing a meal. Specifically, we wanted to help the end-user move from
the initial idea to the end product and develop a tool that would enable this process to be
completed in an easier fashion. As we moved through the brainstorming phase of this
idea, we began to target those users who might not have as much experience cooking or
in the kitchen. Last, our product was specified as a mobile application or a web page in
the beginning phases. In later phases, we realized a web site would serve our needs
best. This web site was theorized to be interactive (e.g. video demonstrations) and
provide a faceted system of search to ease in selection. Thus our project scope became:

Develop an interactive web site that will facilitate recipe selection and support the
preparation process.

The setting for the project became a source of difficulty. The selection process involved
in food preparation can occur in a number of places/locations while the actual
preparation process normally occurs in one place and one place only – the kitchen. This
meant our solution must be able to facilitate a process that moves. In many standard
HCI projects the setting remains the same (e.g. a stationary computer, use of a mobile
device, etc.) and the tool is used in that single setting. However, in this instance we had
a user who might select a recipe online and then move from, perhaps, a stationary
computer to the kitchen. Thus the setting posed a specific challenge for us and one that
had to be addressed in order to build an improved interface.
Section 2: Fieldwork activity and data collected

Interviews and direct observation were used to obtain data and model our users. Users
studied primarily ranged from 18 to 24 years old and were at the novice level in terms of
cooking experience. Their desire to cook was not initiated by need or survival, but rather
simple desire or convenience. That is, in rare instances these individuals were forced to
cook due to caring for younger siblings or children. Their primary cooking activities were
driven by convenience though.

Interviews

Interviews were given to three subjects and audio recordings were made in each
instance. From those audio recordings notes were then taken and the comments
compiled (see Appendix A). Questions asked of the subjects followed the general
transcript listed below:

1. On a scale from 1 to 10 with 10 being the most experienced, how much

experience would you say you have in finding a preparing recipes?
2. Where do your ideas from recipes normally come from?
3. What tools do you use to find a recipe? (e.g. cookbook, web, etc.)
4. What is it that you like about the tool you use?
5. What do you find to be the most difficult part of preparing a recipe?
6. What are the essential elements that make you reject or choose a recipe?

Questions beyond this were asked based on the given responses to the above
questions. For example, a subject that chose the web as their primary search tool was
asked what website they use, what they liked about that site, what they didn’t like about
that site etc.

Once our comments were compiled from each interview, we used this information as
part of the process in defining our Sequential Work Activity Model (see Figure 3) and in
construction of the Affinity Diagram (see Figure 4). However, the primary benefit to
compiling and evaluating our interview data was the ability to construct problem/solution
matrices (see Figures 1 & 2). The compilation of data allowed for two primary
categorizations. First, we were able to ascertain the top barriers to selection with our
interview subjects. Second, we were to fit those barriers into design solution categories
or technological solution categories. Though we did not initiate some of these solutions,
they would have been points of consideration in latter phases of the project.

Figure 1

Top Barriers to
Recipe Selection

Complexity
Ingredients
Familiarity
Quality/Rating of
Dish

Observations

We performed three observations following our interviews and compiled qualitative data
from the observations (see Appendix B). Two observations followed users through the
search process in obtaining a satisfactory recipe while one observation followed the user
through a preparation process. In each observation the observer remained as
unobtrusive as possible asking necessary questions through the process and providing
no direction. One primary focal point herein was to determine what, if any, link there
might be between the selection process and the preparation process. A Secondary goal
was to understand design flaws in the selection process. This data was then used to
compile our Affinity Diagram (Figure 4) and Sequential Work Activity models (Figure 3).
Figure 3: Sequential Work Activity Model

Figure 4: Affinity Diagram

Tools
Tools to
to choose
choose Recipe
Recipe Changes
Changes Users
Users Search
Search
Recipe
Recipe rejection
rejection Problems
Problems
recipe
recipe Selection
Selection Want
Want observations
observations
Google Foreign Pictures Terminology Stepped Staggered
Cookbook ingredients Brand name should be clear directions & faceted system
Food Network Complexity products Precision of order would be ideal
Product Labels Temporal Authority in directions No prep Force faceted
Authoritative Does not like cooking Easy & Fast instructions over free-text
sites such as ingredients reccomends Quality recipe Ordering & Pictures &
Kraft, Nestle Don't have all Rating system organization of rating
Family ingredients online recipe Numerous tools
members Familiarity Family member Inexperienced used
w/dish, process, rec. cooks need
etc. structure
Do not have
right tools
These observations essentially confirmed much of the data we acquired in the interview
phase and supplemented our development process. Moreover, this was a formal method
of presenting the data as it was acquired and the work activity model allowed us to
sequentially walk through the selection and preparation process with the user.

Section 3: Sequential Work Activity Model

This model outlines a 4-stage process in the selection and preparation of a recipe. The
four stages are: Recipe selection, recipe preparation, recipe making and recipe finish. In
each stage, we were able to model the user’s cognitive and physical processes through
our interviews and observations.

Recipe selection: Users had to determine some primary elements prior to setting forth
any coherent plan in the preparation process such as the occasion, whether they had
the ingredients, how difficult was the recipe, did they have the tools and did the recipe
sound good. These items and questions were, in many cases, a matter of personal
preference suggesting further observation would be necessary in order to determine
those recipe that were truly considered desirable. This was beyond the constraints of
this project though.

Recipe Preparation: User had to gather the ingredients, the tools and prepare the food
(e.g. chopping, dicing, etc.). In some cases this might involve a trip to the grocer.
However, that was entirely dependant on numerous factors to include the desirability of
the food, the motivation of the user and the number and price of tools/ingredients
needed. In this stage, users were also prone to re-reading the recipe several times
ensuring they had a good understanding of the process.

Recipe Making: This aspect of the process essentially relied on the organization of the
instruction and the experience of the cook. Some observations noted the lack of proper
preparation – primarily because this was not a step emphasized in the recipe
instructions. This would leave a cook flustered and having problems in organization as
well as proper timing of the recipe. The workflow here involves adding ingredients,
moving between the instructions and the task, timing, ordering and mistake recovery.
Recipe Finish: Involves mistake recovery, adjustments, serving and assessment. These
latter two stages are seemingly unrelated. However, we theorized the first two stages
could have a definite impact on the work process.

Section 4: Requirements & Goals

At this stage of the project, the requirements were becoming clear, but the goals we
would set could in no way hope to encompass all of the requirements and shortcomings
evident through our data collection process. In summation, we had requirements ranging
from the simplicity of the recipe, to the instructions, to the interface and finally the ability
to find a particular recipe. The primary aspect in the data we began focusing on were
two-count – education/instruction and the interface.

We set the following goals:

 Develop a clean user interface that steers the user through the selection process
and simplifies selection
 Provide clear instructions to the end-user through educational materials
(multimedia)
 Add interface capabilities such as rating systems, timelines for preparation, etc.
 Enable the design to facilitate the entire process by providing support through all
phases of the workflow (e.g. printable grocery lists)

The end product was still a web page, but the goals had shifted slightly from our initial
set of goals based on the data collected. Moreover, the richness of our data would not
allow for addressing every component of needed improvement.

Section 5: Conceptual Design

The conceptual design was created to group the gathered user data into a logical flow of
use. Starting with the homepage, the use case of a user finding, choosing, preparing
for, and executing a recipe was used. The conceptual design is shown in Figure 5.
I. Homepage
The homepage would offer an entry point into the recipe browser.

a. Recipe Browser
The recipe browser would offer entry points into four categories of recipe
browsing. Each category of browsing would allow an entry interactively
as a criterion for the recipes desired. The recipe browser would offer
three random results fitting the criteria. Based on the interviews, users
did not have the knowledge to search for a specific recipe but instead
needed to be presented with options. The recipe browser would be built
to encourage the user to find a recipe through exposure to recipes rather
than knowledge of a specific recipe name.

i. Choosing a Recipe by Guests

Options to select the number of guests being served or clear a
previously selected option.

ii. Choosing a Recipe by Time

Options to select the amount of time willing to be spent on the
recipe or clear a previously selected option.

iii. Choosing a Recipe by Cuisine

Options to select the cuisine of the recipe or clear a previously
selected option.

iv. Choosing a Recipe by Mealtime

Options to select the mealtime being served (breakfast, lunch,
dinner, etc.) or clear a previously selected option.

b. Recipe Browser Results

Recipe browser results would present simplified information on a recipe to
help guide a user’s selection process. The result would offer an entry
point into the recipe detail.
 i. Recipe Picture
A representative picture of the recipe.

ii. Ingredients
A list of ingredients necessary to complete the recipe.

iii. Description
A brief description of the recipe.

iv. Author
The author of the recipe.

c. Recipe Detail
The recipe detail would provide more detailed information on a recipe to
assist with a user’s recipe exclusion process by offering information on
ingredients, tools, time, etc. that might make the recipe difficult for the
user to complete. The recipe detail would offer an entry point into recipe
preparation. This would be the point of commitment for the user.

i. Recipe Picture
A representative picture of the recipe.

ii. Ingredients
A list of ingredients necessary to complete the recipe.

iii. Description
A brief description of the recipe.

iv. Author
The author of the recipe.

v. Tools
A list of tools necessary to complete the recipe.
 vi. Time
The amount of time necessary to complete the recipe.

vii. Complexity
The estimated complexity of the recipe.

d. Recipe Preparation
Recipe preparation would provide information necessary for the user to
complete preparations that make the completion of the recipe possible.
The recipe preparation would open an entry point into recipe execution to
be accessed at a later point.

i. Shopping List
A list of ingredients necessary to complete the recipe.

ii. Long Timeline

A timeline representing the general steps necessary overall to
complete the recipe. More detail will be available for steps
necessary to complete before beginning the main series of
consecutive steps (thawing, marinating, etc.).

iii. Tools
A list of tools necessary to complete the recipe.

e. Recipe Execution

i. Short Timeline
A detailed timeline representing the specific and consecutive
steps necessary to complete the recipe.

ii. Timers
Timers to help the user keep track of recipe cooking times.
iii. Step Pictures
A representative picture of each recipe step.

iv. Step Video

A representative video of the recipe being prepared.
Figure 5: Conceptual Design
Section 6: Page Design & Prototypes

Our initial prototypes were exploratory and we did not use paper prototyping. We were,
at the initial stage, attempting to determine where the pieces might fit together in a final
product. Thus we concentrated on interface leaving the final details for the end product.

Figures 6-10 illustrates our initial prototypes with annotations.

Figure 6: Home page with menu navigation for favorites on the right, middle column
provides faceted search system for directing selection and far right-hand columns is for
advertisements.
Figure 7: Once leaving the home page, the navigation scheme changes but remains
consistent unless one returns to the home page. This is a common use of navigation in
today’s web world. However, at this point the user is able to select from the type of meal,
cuisine, time, occasion, etc.

A point to note here is that the above design, in order to truly be an effective faceted
system, should allow for the selection of more than one category at a single time to
minimize clicks. That is, put everything on one page or at least the most popular choices.
This comment was confirmed in our test of our final prototype.
Figure 8: This guided navigation pushes the user down another level to determine the
ingredients in their recipe.

Again, what if the user decides they would prefer to select a breakfast based on the time
to prepare? This prototype does not allow for that and we would have to develop a
solution.
Figure 9: The user is given a series of choices based on their selections thus far. Note
the picture is included as well as description and rating. It would be prudent to include
the time at the top of the description section.
Figure 10: Once the recipe is selected above, the user is moved to the instruction page
and are given a timeline for preparation. They are also able to email a version of the
recipe and extrapolate an ingredient list.

This initial prototyping session allowed us to ferret out deficiencies and find
shortcomings in the initial design process. This was extremely helpful as we moved into
the final prototyping sessions.

The final prototype was constructed using a rapid prototyping tool Axure RP. As a rapid
prototype, there were many limitations to the possible functionality, specifically that
Axure RP prototypes mimic a static, event-based interface and mainly rely on
JavaScript. Several graphics were developed to encourage the users to view the
prototype in the context of popular social content websites, such as MySpace and
YouTube.

The pages were built from a minimalistic approach to allow the usability study to focus
more on the metaphors and use cases rather than visual layout or specific content. The
homepage (Figure 11) was constructed with entry points to the login functionality, the
recipe browser, the recipe execution, and the uploading functionality. Before logging in,
all entry points led to the login functionality first, and the uploading functionality was not
built into the prototype but rather presented for context of the intended use case.

Figure 11: Prototype homepage.

Once logged in with a dummy username and password, the user would be able to
access the recipe browser functionality (Figure 12) through the “Find!” button. The
recipe browser presented entry points into choosing specific criteria for sets of recipes.
As in the conceptual prototype, the four criteria were number of guests, mealtime,
cuisine, and cooking time of the recipe.
Figure 12: Initial recipe browser screen.

The criteria would present options for the user to choose or clear a selection for the
criteria (Figure 13). Choosing or clearing a selection would provide an entry point back
to the recipe browser screen and display three random recipes that met the criteria while
also displaying the criteria selections made (Figure 14).

Figure 13: Recipe browser selection for “Guests” criterion.

Figure 14: Recipe browser displaying results and “Guests” selection after selecting “5”
guests.

As more criteria selections are made, three new random results are displayed that match
all criteria (Figure 15). This way, the user would be able to browse for a recipe with
increasing narrowness of a search but would also be able to cease the search and
choose a recipe as soon as a suitable or interesting recipe was displayed. Each recipe
picture would offer an entry point into the recipe detail (Figure 16), but only the far left
recipe browser result was active in the prototype.
Figure 15: Recipe browser displaying results “Guests” and “Mealtime” selections after
selecting “5” guests and “Dinner,” respectively.
Figure 16: Recipe detail page presenting general information about the recipe.

The recipe detail page presented the name of the recipe, the author, a picture, a
description, a list of ingredients, the estimated complexity, number of servings, a list of
tools, and the long timeline developed in the conceptual design. The author name would
in theory offer an entry point into information about the author but was not implemented
in the prototype. The “Go Back” button would return to the recipe browser and results,
while the “Make this!” button would offer an entry point into the recipe preparation
(Figure 17).
Figure 17: Recipe preparation displaying steps required before beginning the recipe.

The recipe preparation included a list of ingredients necessary for the recipe in the form
of a grocery list. The “Print List” button would generate a print command for the browser
but was not implemented in the prototype. The long timeline was again presented but
this time with the “inactive” steps before the recipe highlighted along with more detailed
instructions. The “Back to Home” button offered an entry point back to the homepage.
This time, the number of recipes marked to learn would be displayed next to the “Cook!”
button (Figure 18).
Figure 18: Prototype homepage after a recipe has been marked to learn.

The “Cook!” button now offered an entry point into a list of recipes marked to learn
(Figure 19) that each would offer an entry point into the recipe execution (Figure 20a,b)
through the “Let’s Cook!” button. Only a single recipe was able to be marked to learn in
the prototype, so only a single recipe was displayed.
Figure 19: List of recipes marked to learn.
Figure 20a: Recipe execution page with short timeline, recipe steps, and representative
pictures of each step.
Figure 20b: Recipe execution page continued.

Page jumps were active at the top of the page and within each recipe step to make
scrolling unnecessary. Along with the list of steps at the top of the page, a set of
rectangles were sized according to the time estimated, keeping in theme with the long
timeline shown to the user on the recipe detail and preparation pages.

Section 7: User Feedback and Salient Scenarios

The users were given a series of salient scenarios with which to provide feedback. We
used two users under the age of 21 and put them through a chosen scenario. The
scenarios follow:

Usability Study
Welcome to the YouFood! prototype.  YouFood! is designed to be social website, like
MySpace, where experienced cooks can upload recipes and instructions to teach less
experienced cooks.  In this usability study, we will be using “think aloud” technique,
where you will try to describe what you are doing and thinking while using the prototype.
The facilitator may ask you questions like “What are you doing?” or “Why did you do
that?” to help you think out loud.  Please note that only “Dinner” and “Dessert” recipes
are implemented in the prototype.
 
Scenario 1
Describe a circumstance where you would be looking for a recipe to make for a dinner or
dessert.  Log into YouFood! and look for a recipe you might make.
The point of Scenario 1 is to guide the participant to describe how the decision-making
process interfaces with the prototype.  Be careful to note where the participant becomes
frustrated or confused and also where the participant is particularly pleased with the
design.  Try to explain as little as possible in order to encourage the participant to
explore.

Scenario 2
You want to make a unique dessert for a family occasion with a large number of people.
Find a suitable recipe and mark it to make later. Describe the steps that would need to be
taken in order to make the recipe.
The point of Scenario 2 is to have the user step through choosing an appropriate recipe
for a specific need. Be careful to note where the participant deviates from the path
leading toward successful completion and also what information the participant uses to
make the decision.  There should only be one suitable dessert: Baklava.  If the user does
not find the recipe after a while, guide the user to the Baklava recipe. After the baklava
recipe has been found, prompt the user for the steps necessary to take, like “go shopping
for the ingredients,” “defrost the phyllo,” etc.

Scenario 3
Step through making the recipe that was marked.
The point of Scenario 3 is to test how the user would actually use a recipe.  Have the
participant roleplay making the recipe in the actual space that would be used (kitchen).
Be careful to note any unexpected uses or positioning of the computer in the space that
would impact the design.   Also note how the participant scrolls around the page during
use.

User #1

User #1 was a 16-year-old female who is a novice cook. She was placed in the scenario
and given the instructions listed above (orally). Primary points to note in the outset are
the user did not truly comprehend the idea of a prototype with limited functionality. She
also noted it seemed to simplistic of design. However she later noted the entire design
seemed overly complex for what it attempted to present. She was able to step through
the process with limited problems. Primary problems were related to the limited
functionality of the prototype and not the design itself. There were, she stated too many
clicks to get to the end point. This was noted above in our initial prototype. She stated
she would like to see everything (all of the choices) on a single page rather than being
guided through the process. She noted there was no home button in our final prototype.
This is incorrect and there is a home button based on the site logo. It is important to note
she did not notice this.

She had no problems with scenario 2 or 3 and her comments were central to the
interface suggesting we had the instruction portion well designed, but are still having
problems navigating our user through the selection process. It was mentioned our final
intention would be to include videos of techniques. This was received with enthusiasm.

User # 2

User #2 was a 23-year-old female who is a novice cook. The user needed explanation
to further clarify the purpose and intent of the prototype use case of choosing a recipe
for making at a later date. After receiving an explanation, the user was comfortable with
the use case.

The user behaved as expected when looking for a recipe and exhibited behavior
consistent with the earlier interviews. The user primarily used the pictures of recipes as
the first level of discernment. However, the user did comment that the constant
presence of the four browsing options made her feel that she had to have an option
selected for each.

Once an interesting recipe had been found, the user accessed the recipe detail to
discern whether or not the recipe was possible to be made. The user did comment that
she preferred recipe steps be made available through another page of deeper recipe
detail and said she would only access the extra information “sometimes.” The user
seemed to understand and latch onto the concept of the timeline and suggested that
“active” time be indicated somehow visually.

The user disliked the terminology and methods for choosing a recipe to make for later
and suggested a shopping cart metaphor, instead. Also, the user wanted a way to find
recipes that had been seen or used previously. The user suggested a “wall” with the
recipe pictures to find previously seen recipes and said, “I’m not even looking at the
names.” For previously used recipes, the user suggested a “favorites” function that
could display a list of recipes marked as a favorite.

Several functions expected to be useful to the user turned out to be unimportant. For
example, the user found the idea of printing a grocery list to be absurd and said, “I would
just look at the things I already have and add the things I don’t to my shopping list.”
Also, because of the user’s perceived need to have a selected option for each browsing
category, the user did not seem to need or want to be able to clear a selected option.

Overall, the user said she liked the concept of the site and said she would use a similar
product if one were available. The user said the main improvements necessary would
be to: (1) make it easy to browse for a recipe that had been seen before, (2) to change
the metaphor used when choosing a recipe to make for later, (3) make it easy to find a
recipe previously made, and (4) to make more information available through but not on
the recipe detail page.
Discussion

In completing this project it is important to note both the number of challenges and the
number of deficiencies we discovered. The greatest challenge in this particular project
was narrowing the scope since we quickly realized after data collection that we had a
number of different projects rather than a single project. This project would have to be
completed in phases and could not have been done in completion given the amount of
time we spent on it. We also found a challenge in managing data content. Specifically,
the recipes were a challenge and attempting to build a cohesive product required
management of recipe data and compilation of that data. Finally, a challenge existed in
choosing a format for the educational piece. Video would have been the preferred
format, but we needed to storyboard that effort with stills prior to moving to a full-scale
model.

Deficiencies are always important to note and an interface requires several designs and
redesigns prior to being complete. We had the option of two user sessions for feedback
giving us some required data for redesign. Ideally, we would have wanted to go through
this process a number of other times before moving into a redesign. Also worth noting is
the decision to sacrifice efficiency for guidance. The values of our users and the data we
received placed the problem not in an efficient interface that reduced clicks or provided
quicker access, but one that both guided the user through the decision making process
and one that guided them through the preparation process. This posed both a challenge
and in the end what some might term as a deficiency in that as noted above these sites
require a larger number of clicks on average than many others. This was due to the
added value of providing guidance and instruction

In the end, our development process shifted based on the data collected and the needs
associated through our interpretation of the data. This led to a product that was
considerably different from the product we initially envisioned giving us a somewhat
disjointed project in that we were required to shift directions midstream. This was a final
important lesson learned. We began with a simple idea of developing an improved
method of recipe selection and preparation to take shape in the form of a web page or
mobile application. Based on our data, we moved forward with more than a simple web
page, but a product designed to steer the cognition of our user through the interface. We
ended with a prototype that is a step in the right direction, but a work we feel would
require further investigation and study.