HW Instructions
I320U Information and Interaction Design

Published

October 16, 2025

The course has two major components:

  1. Milestones here These are group activities which together contribute to building a project over the course of the semester.
  2. Exercises here These are individual activities to help to learn concepts taught in the class.

Milestones

Together, the following milestones constitute a project that determines half of your grade. The whole project divide into 5 major sprints:

  1. Milestone 1, Project Focus
  2. Milestone 2, Contextual Inquiry
  3. Milestone 3, Personas
  4. Milestone 4, Scenarios
  5. Milestone 5, Hi-fi Prototype

This is the most important and time consuming part of this course. Past projects groups claim to have spent upto 40 hours in meetings to plan and organize their projects.

The course needs the following submissions: 1. A digital portfolio piece - Should be shared via the web, the website design will not be graded content is what matters. This will be updated with every milestone submission, ideal case a webpage following the structure: - A page for each milestone. - A section showing all the milestones. - A small description of the team and it’s members. - Etc 2. Final information deck - A concise summary of the project this will be used to present during the class, ideally following the structure: - A pdf file (can be styled in any format) not a ppt or keynote presentation. - Project and it’s explanation. - Team introduction - Explanation of each milestone - Learnings - Etc

Create a project website

I currently (at the start of the semester) don’t know of your sophistication level with website creation. We will devote some class time to understanding your sophistication level and may devote some additional time based on your response. Keep in mind that the project website is a container for your project documents. You will not be graded on website design so, unless you are trying to improve your website design skills for some external reason, you should not waste time on the website except to make it possible for me to find the individual milestone sections, the covenants section, and the id section.

Diverge, then converge

You must do two things to develop a creative project and meet deadlines. You must first diverge, then converge. Divergence is fun and, in my experience, people spend too much time on it, then go into a frenzy of convergence. You must decide in advance what fraction of your time is spent on each process and be decisive about switching from one mode to the other when your time comes.

The same is true for gathering ideas and implementing them. If you’ve overused the web for a decade or more you probably remember the meme involving Hitler getting bad news in the film Die Untergang (2004). People would subtitle the scene endlessly with bad news affecting different hobbies, occupations, sports, or celebrity foulups.

Did you know that there were even versions for UX? Yes, UX is everywhere. And UX people seemingly have time to throw up endless websites with internally conflicting advice, eternal truths, urban legends, and the occasional valuable piece of information. During your program here, you need to find a way to better cope with all the UX information coming at you from every direction. You need to share with each other how you get information as well as how recall information when you need it. As you approach a difficult milestone like contextual inquiry, it will be tempting to keep gathering information right up to the last minute. Resist that temptation! You already know too much!

Making a deadline is a convergent process. You don’t want to be open to new ideas. You want tunnel vision near a deadline. Any new information you receive has to be put somewhere you can find it after the deadline. Over half of your classmates probably don’t have a good place to put new information right now. So put it anywhere and concentrate on processing the information you have right now.

Milestone 1. project focus

Establish a website that identifies your team, your customer, the problem, and the general direction for solution. (Onsite version of the course only: Be prepared for a critique of your milestone similar to the widget redesign critique. After you present this milestone, you must summarize the critiques by your classmates on your website. You will need to do this for every milestone, so develop a repeatable process.)

You can use Holtzblatt, Wendell, and Wood (2005), chapter 2, to help you think about the scope of the project, its stakeholders, and your general approach. That text identifies examples of projects with a small, tight scope that can be done rapidly, such as usability fixes, market characterization for new system concepts, website evaluation and redesign, next generation systems, supporting a coherent task, and reporting. There is also a discussion of stakeholders that can inform you. You should briefly identify your proposed stakeholders and consider the following points about them: goals, worries, ideas, how to involve them, how to communicate progress, how to understand their way of communicating, and how to communicate the design to them. You should include a set of covenants to govern your group. These must be agreed to by all members and must specify grounds for expulsion from the group. Only ten percent of all groups wind up having to enforce these, but they may help stave off disaster, so everyone should form covenants.

Milestone 2. contextual inquiry

Conduct a contextual inquiry for your project on a workplace to which you have access. You can use Holtzblatt, Wendell, and Wood (2005), chapters 3 through 8 to complete this milestone. Also see Spinuzzi (2000) and Beyer and Holtzblatt (1999).

Revising milestone 1

Your milestone 1 website work is not done. Milestone 1 was about specifying the broad outlines of your project: scope, users, problem statement, solution statement. Those broad outlines are likely to change. There should always be a place on your website where people can look to find out the big picture so I’m not saying that you should do away with that and replace it with a lot of details, but be flexible about it and go back and change a few words or diagrams or whatever that tell the big picture as you go along. Refer to that so that the big picture directs you when you have to decide which details are relevant.

Products

You are likely to find that there are natural products of a contextual inquiry that can be added to your website. Your website should help you as a team. Typically a team has to come together to do some activities, then go off individually to do others. Your website can be used to document the things you do as a group so that individuals can use them, and to document what individuals do that needs to be reported back to the group.

Deliverable Products

You must include a legible version of your affinity diagram and documentation of all your interviews. This includes your questions, your protocol (the procedure you follow), and your interview notes. You should include a transcript if you record the interview, but it should be a written transcript and fully anonymized. Each group member should conduct two interview / observations.

Planning

You will plan your interviews and the interpretation session that follows and the construction of any artifacts you develop like affinity diagrams. This planning can go on the website in the form of a schedule or checklist that individuals can refer to. Holtzblatt, Wendell, and Wood (2005) has several relevant checklists, such as the CI process checklist (pp 80–81).

Interviews

Individuals need to conduct their interviews so they can be used in the interpretation session which, according to Holtzblatt, Wendell, and Wood (2005), should occur within 48hrs (p 101) after the interview. Realistically, between now and your deadline, you’ll only have time for one of these cycles. By completing an entire cycle, you’ll have a blueprint you can refine for future use. One timesaving feature advocated in Holtzblatt, Wendell, and Wood (2005) is to avoid discussing an interview before an interpretation session (p 101).

Interpretation session

You should have a lot of data after an interview and it should be a challenge both to share it and to make sense of it. You should review, analyze, and capture key issues in an interpretation session. A natural product of this activity is the affinity note, which becomes a natural input into the next activity, constructing an affinity diagram. Chapters 6 and 7 of Holtzblatt, Wendell, and Wood (2005) give guidance on capturing sequence models, artifact models, and physical models, and using them to construct affinity diagrams. These are different for different projects, especially the physical models, although the use of affinity notes are likely to pervade all groups.

Affinity Diagram

Holtzblatt, Wendell, and Wood (2005) gives very detailed guidance in Chapter 8 about developing an affinity diagram from affinity notes. I won’t reproduce that guidance here but I will give a brief overview. Beware trying to use this overview as anything more than an introduction. Your diagramming session could easily drag on for eight hours if it is to succeed. You really need more detailed guidance to complete it. The following paragraphs give an overview of these steps:

  1. Add 500 post-it notes to the wall
  2. Add the bottom level of labels above the post-it notes
  3. Add the temporary top level of labels and reorganize all the notes and labels to fit them.
  4. Remove the temporary top level labels.
  5. Add the middle level of labels.
  6. Add the top level of labels.

Note that there are four levels of post-it notes. The lowest level is the atomic observation, referred to as an affinity note by Holtzblatt. These each simply copy one thing a participant said. For example, a participant might say “I hate the menu system because it’s so hard to navigate.” The other three kinds of post-it notes are the affinity labels, as Holtzblatt calls them. There are top, mid, and bottom level labels. For example, a bottom level label for the above note could be “I struggle navigating the menus”, while a higher level might be “I struggle to find things”.

The overview of the process is that you use post-it notes grouped together on a wall, preferrably on enough wax butcher paper taped to the wall so that a group of four can comfortably navigate and fill it with about 125 groups of 4 notes. Holtzblatt suggests starting with about 500 yellow post-it notes that represent atomic items (step 1). These are the affinity notes mentioned in the description of the Interpretation session. Your group should stop when you can no longer keep track of the groups of these yellow notes.

Next (steps 2 through 6), Holtzblatt, Wendell, and Wood (2005) describes a process of labeling these roughly 500 notes with three layers of notes of different colors. I find the colors confusing so my brief overview will simply refer to the bottom level, the middle level, and the top level. You start with the bottom level but, confusingly, you next proceed to the top level as a rough cut. Then you remove this temporary top level, build the middle level and finally the actual top level.

Although the labels are also post-it notes, albeit colored differently, be aware that Holtzblatt, Wendell, and Wood (2005) distinguishes between them and the yellow atomic affinity notes by using the term labels to describe the post-it notes at these three levels.

The general guidance for these labels is to write them in the first person, to reveal concrete detail, to use words that mean the same to everyone, to let the meaning emerge from the groups (instead of predefining), and to reorganize hard-to-label groups rather than continue wrestling with unsatisfying label wording.

As I mentioned above, the bottom level of labels is begun (step 2) when the people can no longer keep track of the groups of affinity notes without any labels. The labels at the bottom level should have design relevance and highlight distinctions rather than bringing groups together.

The next step (step 3) is to build a temporary top level, largely because this will help you move the affinity notes around into positions closer to their final positions. There should be only half a dozen or so of these temporary top level labels. Once everything has been moved around then remove the temporary top level (step 4).

The next step (step 5) is to build the middle level of labels. These labels should highlight high level work concepts, such as steps in work, communication strategies in work, tool use, and organizational structure.

The final step (step 6) of the affinity diagram is to add the top level, the level that describes the key issues. These key issues will inform the behavior patterns that will be the basis for the next milestone. Any break in the chain from interviews to these key issues jeopardizes the next milestone and, ultimately the entire project.

Keep in mind that these affinity labels are written in the first person and represent things an archetypal user might say. They certainly don’t need to be things actually said in an interview but they do need to be things someone might say. That way, they can be a concrete basis for a persona. The following figure shows a fragment of an excellent set of affinity labels.

Affinity diagram details

One thing that I would like to add is that you can probably get a lot more done by using a paper process than by using an online tool. It’s harder to document a paper process on a website, though. My best suggestion is that you get four Elmer’s display boards, 36” \(\times\) 48” $3.60 in bulk, $7.39 individually at an office supply store. You should be able to fit 150 3” \(\times\) 3” post-it notes on each board. It will be even easier if you have neat handwriting and use smaller post-it notes.

Use these boards and post-it notes and just bring the results to class to present. One previous semester, the most productive groups found it difficult to fit everything onto one of these boards. Less productive groups found it quite easy and even had space left over. If you find that you have sparsely populated one of these 36” \(\times\) 48” boards, you probably haven’t dug deeply enough. On the other hand, adding more post-it notes until the thing is covered may only mask the problem of not digging deeply enough, rather than solve it. One previous group made the unwise decision to omit pink and green labels altogether so they could concentrate on boosting the number of yellow post-it notes, having discovered that they could not reach the 500 minimum specified in Holtzblatt, Wendell, and Wood (2005). (The above color scheme is clarified in detail in Holtzblatt, Wendell, and Wood (2005) — basically the above means that they did no grouping of notes into themes at all). As a result, they were unprepared to say anything analytical about what they had found, instead trapped at the individual anecdote level.

There is a lot of software for doing affinity diagrams, but the overhead is significant and it’s harder for a group of people to interact with tools that are inherently meant for one person, one keyboard, one mouse. If you have a bunch of post-it pads and are sitting around a posterboard display on a wall or a conference table, you can generate a lot more material faster. By the way, you could just do stuff on a wall as Holtzblatt, Wendell, and Wood (2005) recommends, but then you have to figure out what to do with 500 – 1,000 post-it notes afterward. The display board gives you something you can fold up. If you tie it tightly enough or cover the surface with fixative spray or tape or staples, you may find that post-its will retain their positioning.

Figjam

One final addition to this section is that students have actually had good luck with a software package called FigJam. This is web-based collaborative diagramming software that all members of the group can access at once from their own machines. I like it because of that and because it looks good on my thirty inch monitor when I’m grading assignments. Although I am generally against software for affinity diagramming, this is a wonderful exception to the rule. And it is free for students!

Milestone 3. personas

See Pruitt and Grudin (2003). Use Cooper et al. (2014), chapter 3 to complete the persona milestone. The first author of that book, Alan Cooper co-originated the persona concept, so you should regard that as basic required HCI reading anyway.

The persona process involves fewer steps than does the contextual inquiry, so I won’t give an overview here. Let me just remind you that each persona’s behavior patterns are selected because of the key issues at the top of the affinity diagram. Cooper et al. (2014) describes various ways to research the persona but the way you have done it in this project is through the contextual inquiry.

You must generate a primary persona. These are the focus of your prototype and any scenarios that the prototype will satisfy. You should also develop at least two secondary personas, especially if your contextual inquiry has led you to a complicated picture of goals and means.

Finally, you may benefit from inclusion of one or more anti-personas. These personas define behavior patterns you have explicitly determined to be out-of-scope for your project. I mention this because overly broad scope is one of the most severe afflictions to beset student projects. You should welcome anti-personas as a tool you can use to eject aspects of the project that will dilute your focus, sap your energy, and make your direction waver.

Personas sometimes benefit from dashboard displays, displays that were once fashionable in data analytics for their resemblance to instrumention of cars or planes. The point of the resemblance is what matters. Dashboards are meant to be instantly readable. It may be easy to create meters along several behavioral axes showing, at a glance, the difference between personas. This is optional but it has clearly helped some groups.

Milestone 4. scenarios

Inject your personas into scenarios and document a few (at least three) for this milestone. Each scenario should be represented as a cartoon of four to six panels, illustrating a successful use of your product. Not that you don’t need to have developed a prototype of your product to this successfully. In fact, there are four typical kinds of panels for a scenario, a manual step, a user interacting with an extremely lofi picture of the product, a lofi screen closeup, or a sketch of the “behind the scenes” view. These are illustrated here.

These scenarios flow directly from your contextual inquiry and personas. There should be a clear through line between these three milestones. That’s the main basis for grading this milestone. The quantity of work is not apparent in a successful scenario milestone. It may have taken you a long time or a little time to develop the appropriate cartoons. The quality of the cartoons is only important insofar as they are clear and can be used to compare to your later prototypes. The scenarios are a tool to reference during the construction of prototypes. Does the prototype fit any of your scenarios? Does it seem like that your prototype will successfully come into play in these scenarios?

Milestone 5. hi-fi prototype

The outcome of this milestone should be something viable for user testing. You should not have to modify this so you can use it for testing. Therefore, the definition of hi-fi may be relaxed. This may well be a mid-fi prototype. The goal is to prepare something you can use to gain relevant knowledge about the design from users.

You need to show the flow of your application rather than just showing individual screens. You may achieve this with a narrated video or other means you negotiate with the instructor.

The video of your hifi prototype should be a walkthrough of your site or app. It should show the paths that a user takes through the application or site. There should be some narration of the tasks that the user is thinking of while the user achieves their goals using the prototype. It should be clear throughout what the user is doing and why they are doing it. You should state the purpose of the app or site at the beginning, along with the name of the project. This should be followed by each task or path in turn. At the end, there should be some indication that we’ve reached the end, rather than leaving us to wonder if some of the video was cut off.

Final project presentation

You will have about eight minutes to present your work to the class, including any questions you’re asked by the instructor. You will focus on the prototype and the design decisions that got you there (you’ve been making design decisions since you established your project focus). It is up to you to articulate which design decisions mattered. Think of the presentation as an opportunity to share what you’ve learned.

You should try to have every member of your group speak at least briefly but this is not mandatory.

No slideshow is needed for this presentation but you should be prepared to show your website and the prototype.

The final presentation is not graded but you can not receive a grade for the course if you do not complete it. It is your responsibility to schedule it with the instructor in the event that you can’t do it in class.

Milestone critiques

Someone in a group working on a shopping cart device (at a university where I taught previously, RIT) asked whether they should change direction or scale back because I said that I thought it would be too expensive to put a device in each shopping cart. Here’s what I said in reply.

I would like you to think about this in a different way. Instead of trying to decide what to do based on what I have said, try to find evidence that supports or refutes what I have said.

There is a major grocery store chain headquartered near here, Wegman’s. They donate a lot of IT equipment to RIT so I know they are friendly to RIT. When I visit there, I often see the employees themselves shopping for groceries. I’ll bet you could interview them to find out about the needs of shoppers that might be helped by having a device on the grocery cart or perhaps an app that might help.

I’ll try to say more later but for now let me just add that the needs of the shoppers as perceived by the employees may differ from the needs of the shoppers as perceived by the shoppers and ALSO from the needs of the shoppers as EXPERIENCED by the shoppers. In other words, even the shoppers themselves may perceive differently from their experience.

A famous quote from Henry Ford, explaining why he did not listen to his customers was that, if he had, they would have just told him to invent a better horse and buggy.

Project management

Many teachers agree that no project management skills are required to work on a project with a group of four or fewer people. This is a major reason teachers who are not teaching project management advocate groups of four or fewer for class projects. Nevertheless, many students are unaware of or don’t believe this claim, and ask about project management. There are two things I can share about project management without diverting much attention from our purpose. One is the individual interactions between team members. I will discuss that later. For now, I would like to make a few remarks about the practice of project management in the IT workplace.

The Project Management Institute (PMI) has become the most popular focal point worldwide for best practices in project management. For example, a recent recruiter at UO identified the PMI as the source for project management practices at DataLogic ADC, a Eugene manufacturer of automatic data capture equipment. Some universities devote entire departments or even, as in the case of Stevens Institute of Technology, entire business schools to PMI education. PMI practices are inescapable in information systems development.

The main reference guide to these practices is called The Project Management Body of Knowledge Guide. The required reading for this section is an excerpt from an earlier edition of that guide, offering some general definitions for project management. In addition, the Guide lists all the non-controversial processes in project management and provides lists of their inputs and outputs. By non-controversial I mean all the process that the project management profession agrees upon as a baseline. Innumerable project management consultants offer proprietary extensions to this body of knowledge and these extensions are not covered in the guide, nor are the basic processes covered in any great depth. The Guide simply serves as a brief summary of the current state of agreed best practice in the field.

The significance of project management for information systems is that most information systems activities are organized as projects. Productive organizations may be managed as functional areas, operational areas, a matrix of these kinds, or entirely as projects. This latter category is extreme but it can be seen in the organization of Hollywood movies and in the activities of BP, one of the world’s major oil companies.

I had the good fortune to interview a vice president of BP in 2006 and learn that BP was then trying to discover best practices from Hollywood blockbusters in order to reduce its exposure to operational management by outsourcing as much of each oil rig as possible and treating each oil rig as if it were a Hollywood feature film. Each oil rig is as large and complicated as a 70 story skyscraper, although it is meant to be used for far less time and for only one purpose. Interestingly, BP had just experienced a catastrophic oil spill (6,000 barrels) at the time and I could not help but wonder how large a role exposure to litigation may have motivated its project focus. Alert readers will note that, just four years later, BP experienced a vastly more important oil spill (5 million barrels), known as the Deepwater Horizon oil spill. That event and its aftermath are far too complex to even summarize here. I just want to note that the project management approach to organization may be tied to other considerations but that they feature prominently in contexts other than information systems.

An alternative to thinking with a project management focus is to think with a devops focus. Devops is a contraction of development and operations and is popular in organizations whose primary product is software. Thinking from a devops perspective is often seen as contradictory to project management thinking because devops preaches continuous improvement of processes rather than seeing the delivery of software as primarily the product of a lifecycle. While an organization practicing devops will typically have projects and project managers, they are not the primary concern. The primary concerns are (1) the flow of work from development to operations to customers, (2) the flow of feedback from customers to operations to developers, and (3) a culture that fosters innovation, trust, and continuous improvement. Additionally, devops is concerned with reducing work in process and unplanned work. You can read more about devops in books with either devops in the title or titled with the related term release engineering.

Exercises

This section has four parts, which are the following:

  1. Completing Exercises here - How to complete and submit exercises.
  2. Exercise List here - List of all the exercises that will be happening this semester.
  3. Post Submission Reflection here - Suggestions and activites post submission to improve your learnings outcomes.
  4. Exercise Objectives here - Some exercises have additional examples and suggestions, these could be helpful if you are stuck during completion.

Completing exercises

The following paragraphs give general guidelines about your sketchbook, your process, time constraints, and a storytelling model for exercises.

General directives

When submitting your assignments please the keep a few things in check, for the sake of example we will be considering you are submitting the assignment called “Picking up a key”:

  1. The file name should not have any spaces and no need to include your name in the file name.
  2. If the submission has only one file then name the file as PickingUpAKey.jpg.
  3. If the submission has multiple files then name the files as:
    • 01pickingUpAKey.jpg
    • 02pickingUpAKey.jpg
    • 03pickingUpAKey.jpg
    • And so on….
  4. Do not combine multiple files submissions into a zip or folder, upload them one by one.
  5. Accepted formats are (Please stick to these formats ONLY):
    • jpg
    • png
    • pdf
  6. Every exercise must be accompanied by two hand-drawn sketches of good design. These will serve several purposes: (1) improving your hand-eye coordination for sketching at the whiteboard, for instance (graduates often tell me they spend 2/5 of their time at the whiteboard!), (2) refining your idea of what constitutes good design, (3) recording your progress in sketching, and (4) sharing examples of good design with others. Please note that design is created by humans, so pictures of trees or mountain ranges are not acceptable. Each sketch should be of one good design, rather than, say, a street scene with many designed artifacts. It should be apparent at a glance what you mean as a good design.

Using your sketchbook

Windows Phone 7 HQ

Michael Smuga, studio manager, Windows Phone 7 Development HQ, is seen relaxing while the press photographs him to show that Microsoft is no longer uncool as part of a large publicity campaign prior to the launch of WP7, circa 2010. Note what appear to be hand-sketched storyboards behind him and I dare you to tell me that this is not an advertisement for doing sketchbooks in this class!

Diverge then converge

For each exercise, you must diverge or your ideas will be boring. Then you must converge or you will not meet deadlines. Another way to say this is that you must spend part of each exercise trying to play followed by some time trying to produce.

How do you know whether you have played and produced? We spoke of the concept of flow and you know that you have that you are playing when you have achieved flow. That is an internal measure you may assess for yourself. An external measure might be a judgment of creativity. Your output is more likely to be assessed as creative if you have played but beware. Your output may be assessed as not creative for another reason. If you fail to converge, you will not have adequately conveyed your creativity. Thus you may find converge a necessary but not sufficient condition for others to appreciate your creativity.

Leonardo was a terrible example of failure to converge. He rarely finished his work and much of it only began to attain prominence centuries after his death. Mona Lisa, for instance, was not widely touted as the greatest example of oil painting until about the past hundred years.

It’s easier to see the outcome of convergence than divergence since you have a series of sketches that people can or can’t understand. You have to ask yourself whether people get the message you conveyed.That is separate from whether or not you conveyed a good message. So your creativity may be judged by how good the message was. Your convergence can be defined as how well you conveyed the message you intended to convey.

Allocate your time

In each exercise, you should try to work within a severe time constraint and prepare a presentable artifact in that time. You should improve your ability to complete each step so that you have something to show at the end. You have to get to know yourself well enough to know what you need to spend the most time doing. Do you struggle with the problem definition? Are you indecisive about which aspect to tackle? Do you struggle with rendering your ideas? Each exercise should contribute a little to your picture of what you need to do to grow.

Tell a story

Every single exercise from the picking up a key exercise until the last exercise offers the opportunity to tell a story with your solution. Storytelling is one of the oldest and most defining human activities. You must be a good storyteller to be a good designer. People expect to experience stories and you can take advantage of our human predisposition to experiencing storytelling to communicate your design ideas.

Many, perhaps most, great stories are not told in linear time. Stories do not unfold stepwise, like appliance manuals. (Actually, Ikea does assembly manuals that approach storytelling.) You have to develop a way to tell story that takes the viewer’s experience into account. This is often starting with a detail and expanding to a big picture or starting with a big picture and drilling down to a detail. It may start with a use case and end with an argument. However you plan a story, you must plan a story.

Exercise list

Here are two lists. First is the list of exercises mentioned in the syllabus. These are mandatory, graded exercises. Second is a list of exercises used in the past or proposed for the future. You are welcome to try these exercises but no class grading credit is available for them.

Mandatory Exercises

The following exercises are compulsory for the completion of the course:

Draw a face

Draw two horizontal lines to divide your notebook page into three parts, so each part is about 2 and half inches high.

Step 1 is to draw a human face in left-facing profile in the top third of the page. It is important to do this before looking at steps 2 and 3. Looking at those steps will affect how you do this step, so quit reading this now and draw the face!

Step 2 is to first make sure you have already drawn a face in left-facing profile before reading further. Quit reading! Draw that face in the upper third of your page. Are you sure you’ve drawn it? Really? Okay, then, step 2 is to draw another face in the middle third of the page but, this time, make one change. Carefully plan this head so that the eye is halfway between the top of the skull and the chin.

Step 3 is to draw a third human face in left-facing profile in the bottom third of the page. This time, use a dime and a half dollar as aids. (This exercise was conceived in an era when half dollar coins were common—your teacher can supply an appropriately sized disk as a substitute.)

This exercise is drawn from the 1964 book Thinking with a pencil by Henning Nelms, Nelms (1964), a great book that was just reprinted in June of 2015 for the first time in 30 years. The picture captioned step 3 of drawing a face is a photo of my copy of the book.