How to design a class

Credit: grace_kat

Ah, summer. That time when teachers around the world prepare for classes but aren’t paid to do it. Because of the shortage of time that inevitably comes with uncompensated work, many new teachers (particularly new faculty) often ask me how I go about designing classes—and if I have any pointers on how to do it quickly.

To me, the key to doing something both well and quickly is having a process. The challenge is that most teachers are expected to develop their own design process because there are so few examples of process to learn from (e.g., where are all of the five hour Kahn Academy videos of a teacher designing a course?). Instead, all you can find is the result of a class design process: a syllabus, some slides, and other materials. None of this helps shape a teacher’s process, and so instead, most teachers use a strategy of bricolage: take an existing syllabus, combining it with other materials, and adapt it as necessary. While bricolage can work fine, it’s not a great recipe for innovative or effective teaching, especially if the example you’re adapting isn’t very good (and most aren’t). Moreover, adapting a course to new learning objectives can often break it, because effective classes can have many highly interconnected parts, each carefully designed to serve a specific goal.

Since I’m often in the position of designing new courses (as part of my teaching and curriculum design duties, but also as part of my research on computing education), in this post I’m going to try to distill my process into something others can follow. I can’t promise it’s a great process or that it will work for you, but after applying it to a few courses, such as my course on HCI+Design, I have some weak evidence that it at least leads to strong student engagement, which is a precursor to learning.

The steps I follow go something like this:

1. Devise and sequence learning objectives
2. Ideate instruction, practice, and feedback for objectives
3. Iteratively sketch, evaluate and refine a syllabus
4. Layer extrinsic motivation (grades)
5. Extract action items
6. Teach the course
7. Synthesize reflections into revisions

I’ll walk through each of these steps, giving guidance on why each is important and how I approach each.

Seven steps to designing a class

1. Devise and sequence learning objectives

The first Zelda game

The fundamental goal of any course is to help students learn something. Deciding what that something is usually comes in the form of learning objectives, which are some statement of what a student will know after completing a course.

To illustrate, let’s use a running example of a course on the critical analysis of the long-running Nintendo game series Zelda. Here are a few examples of learning objectives about such a course:

• Enumerate the recurring game mechanics in the series
• Describe the interactions between the game mechanics
• Clearly articulate what about the game mechanics are fun

Learning objectives are basically statements of what a student can do (and should be able to do after finishing a class). The best learning objectives are clear and observable. For example, it would be straightforward to ask a student to enumerate the game mechanics in Zelda and decided whether they’d correctly enumerated them. In contrast, judging whether a student can clearly articulate what makes Zelda fun is much less clear and much harder to judge. That doesn’t mean it’s a bad objective, it just means it will be harder to teach and access.

Generating learning objectives comes down to having expertise in a domain, since these are essentially opinions about what knowledge is most valuable to know. As you can see with any effort to write curriculum standards, there’s often very little agreement about what knowledge is important, and for good reason: we don’t really know because there’s often no research investigating the value of knowledge across a life. Nevertheless, if you’re designing a course, you get to decide.

Note that courses don’t necessarily require fixed learning objectives: capstones and other courses may result in a wide array of different learning outcomes depending on the experience of each student. As I summarized in my post of Seymour Papert’s Mindstorms, there’s nothing inherently important about everyone learning the same things. In these cases, it is still helpful to brainstorm what learning objectives might occur, so that you can design experiences that make them possible to learn.

In many contexts, you might not be in charge of devising objectives. Someone may have already scoped the objectives of the course, or perhaps you’re trying to comply to a curriculum standard that imposes learning objectives on you. Even when this is the case, there’s always room to refine and elaborate on the objectives you’ve inherited.

In some domains, devising learning objectives is a full-fledged academic research activity because we don’t yet have a clue what’s important to know about a subject. For example, I recently participated in a group of faculty led by Michael Hilton trying to brainstorm learning objectives for a class on software startups. Every one of us had years of experience founding and running software startups, but trying to articulate what students should know about them—and why they should know these things—was challenging, speculative work.

The last task in this activity is to try to sequence learning objectives. The problem this solves is that some knowledge and skills can be dependent on others. If you don’t think about these dependencies, you can end up expecting students to solve problems that are too difficult because they require knowledge they haven’t learned yet. Try to order them in a way that keeps students in the zone of proximal development, but also keeps them engaged, by placing simpler objectives earlier, and more difficult objectives that rely on the simpler knowledge later.

2. Ideate instruction, practice, and feedback for objectives

Once you have a list of learning objectives, the next task I like to do is brainstorm ideas about how to teach each of the learning objectives. As I’ve noted elsewhere, good teaching comes down to deliberate practice. This means: 1) adapting practice to what your students know, 2) offering practice, 3) giving immediate personalized feedback on practice, and 4) repetition.

There is no secret shortcut to this inherently creative activity. To bootstrap this process, you need a large repertoire of examples in your head of ways to instruct, structure practice, and give feedback. The key is then selecting methods that closely align with an objective. Some great ways of finding examples is to attend a professional conference in which other teachers share their innovative methods (e.g., if you’re a computer science educator, the ACM SIGCSE Technical Symposium is one place this happens, or perhaps the Software Engineering Education and Training track at the ACM/IEEE International Conference on Software Engineering).

Let’s take the objective we discussed earlier of enumerating the central game mechanics in Zelda. What kinds of instruction, practice, and feedback would help someone rapidly learn this skill?

Here’s a rudimentary, conventional version:

1. Deliver a lecture defining each of the mechanics
2. Give multiple choice questions requiring students to recognize the game’s mechanics from a list
3. Grade the quiz
4. Pass back the grades

While this is conventional, and probably something most teachers know how to do, it fails to meet the requirements of deliberate practice. First, it ignores what students might already know about Zelda. Second, it offers no practice in enumerating Zelda’s mechanics; the quiz doesn’t even ask learners to enumerate, it asks them to recognize. It gives a bit of personalized feedback on the quiz, but not about the skill we wanted students to have. And it offers no repetition.

Here’s a better pedagogy that fits the requirements of deliberate practice:

1. Ask students to enumerate the mechanics they already know on a piece of paper.
2. For students who knew anything, give each student feedback on which ones they got right, which they got close to right, and which were wrong. If they got them all right, enlist them in your army of students to give feedback.
3. For each mechanic a student didn’t know, have them watch a short video illustrating and describing the mechanic.
4. Return to step 1), unless all students got all of the mechanics right.

This pedagogy adapts to students’ prior knowledge, it offers practice enumerating mechanics, it gives personalized feedback, and it repeats. It probably is also more engaging!

If you can devise activities like the above for every one of your learning objectives, and that also fits within the time and space constraints of your course, you’re well on your way to having a design.

3. Iteratively sketch, evaluate and refine a syllabus

As I generate ideas for how to teach each of your learning objectives, I like to capture them in a syllabus outline. Initially, I don’t worry about dates or times or other logistics like that. Rather, I try to capture the general flow of objectives and activities for teaching those objectives, and then iteratively refine that sketch into a more robust prototype. For example, the Zelda class we’ve designing might look something like this:

Enumerate the recurring game mechanics in the series. Enumerate mechanics, give feedback, watch videos, repeat.

Describe the interactions between the game mechanics. Present a lecture describing interactions, have students recite description to partners, evaluate recitations for misunderstandings until everyone has a correct understanding.

Clearly articulate what about the game mechanics are fun. Print a written argument for why the game’s mechanics are fun and have students memorize the key points and then present them to each other, with one providing immediate feedback. After a student feels comfortable, they present the argument to the class.

What this little prototype allows us to do is evaluate it against student experience. I like to do this evaluation by imagining I’m a student, imagining the experiences I would have in the activities I’d described, and then evaluating them against the degree to which they would sustain engagement. Would the experiences be socially engaging? Would they be encouraging? And if the activities are back to back, would students fatigue?

Let’s imagine all three of the activities above occur in the same contiguous block of time. It has some nice qualities: students aren’t sitting still for very long. They’re talking to each other regularly, and either leveraging existing friendships or making new ones. They’re getting to grapple with arguments about the game’s merits, and since many students of many ages enjoy video games and critiquing video games, they may be interested in understanding the facts about the game’s mechanics and the arguments about their qualities.

That said, students might not like having to focus so much on learning someone else’s arguments. Perhaps a better way to learn the instructor’s argument for the mechanic’s merits is to have students rebut the argument. That would require them to both know the argument, clearly articulate it, but also attack it by developing their own position. I’d then revise sketch and evaluate again.

Once a sketch of this level of detail is devoid of problems, it’s time to increase the level of fidelity, adding explicit class meetings, dates, and other boilerplate, such as time for students to be late, transition time, and other logistical details. Another key piece of information is estimating how long these activities will take. This extra information will constrain the pedagogy, requiring more refinement. To illustrate, let’s add this to our sketch, assuming a 2 hour class and 15 students:

Enumerate the recurring game mechanics in the series. Enumerate mechanics (10 min), give feedback (10 min), watch videos and repeat (20 min).

Bio break (5 min).

Describe the interactions between the game mechanics. Present a lecture describing interactions (10 min), have students recite description to partners and evaluate recitations for misunderstandings until everyone has a correct understanding (30 min).

Bio break (5 min).

Clearly articulate what about the game mechanics are fun. Provide a written argument for why the game’s mechanics are fun (5 min). Have students memorize the key points and then present them to each other, with one providing immediate feedback (10 min). Student generates their own argument to rebut the presented argument, and when they feel comfortable, they recite the provided argument and then rebut it in a group of four (15 min).

Now we can look at this higher fidelity sketch and again critique it for engagement. Are there enough breaks? Are the lectures too long? Are the time estimates off? Is there enough slack time in case the estimates are wrong?

At the end of this iterative refinement, you should have a pretty detailed syllabus, much like the one I’ve posted for my software engineering class.

4. Layer on extrinsic motivation (grades)

You’ll note I haven’t mentioned anything about grades yet. That’s because I think grades, and more generally, summative assessments, often get in the way of learning. They cause students to focus on gaming a grading scheme rather than learning, and worse yet, the act of demonstrating knowledge for summative purposes contributes little to advancing knowledge. If I had my way, I would just skip grades altogether and focus on formative assessment (evaluating work for the purpose of improving it, not for the purpose of archiving measurements of knowledge).

Unfortunately, most of us reside in institutions that have to somehow reduce everything a student has learned into a single number or letter. Since I’m forced to do this, I try to use grades as carrots rather than sticks, treating them as extrinsic motivators rather than punishment for failure. (After all, failure is how we learn, and so punishing failure prevents learning). Moreover, I try to make sure grades reflect knowledge and not just effort.

In the syllabus above, an example of this might be to simply take the last formative assessment from each of the activities in our syllabus and evaluate those:

There are 10 points that can be earned today.

Enumerate the recurring game mechanics in the series. Enumerate mechanics (10 min), give feedback (10 min), watch videos and repeat (20 min).

GRADE (3 points): we will count the number of correctly enumerated mechanics in the last enumerated set of mechanics, divide by the number of mechanics, and multiply by 3 points.

Bio break (5 min).

Describe the interactions between the game mechanics. Present a lecture describing interactions (10 min), have students recite description to partners and evaluate recitations for misunderstandings until everyone has a correct understanding (30 min).

GRADE (3 points): we will count the number of correctly enumerated interactions in the last enumerated set of interactions, divide by the number of interactions, and multiply by 3 points.

Bio break (5 min).

Clearly articulate what about the game mechanics are fun. Provide a written argument for why the game’s mechanics are fun (5 min). Have students memorize the key points and then present them to each other, with one providing immediate feedback (10 min). Student generates their own argument to rebut the presented argument, and when they feel comfortable, they recite the provided argument and then rebut it in a group of four (15 min).

GRADE (4 points): the class provides peer assessment of the clarity of each students’ argument on a Likert scale prompt.

If everything goes well, everyone gets all 10 points. And that’s exactly what we want to happen, since that means everyone met all of our learning objectives.

Note, however, that quantifying student learning dramatically changes the tone of the activities. Suddenly, the point of the exercise is not to enjoy critiquing the design of Zelda, but it’s about earning points. It’s just another example of how grades warp learning and motivation.

5. Extract action items

By now, you should have everything you need to launch a course. There are, however, a few key things to avoid forgetting.

First, there are countless details missing and a wide range of content missing for all of the activities you’ve designed for your course. If you’re really prepared, you can create all of this upfront. I often like to get a course to a level of detail that I don’t have to think to much about what happens when I get to class, and can instead just follow my own guidance. For example, here’s an activity from my software engineering class: there’s enough detail there that I can simply summarize it in class without having read it prior and then answer questions about it ad hoc. This has the advantage of providing a very high fidelity prototype of the classroom experiences, which is bound to help you find other issues.

Assuming you don’t prepare to this level of detail before class, a key task is to take your prototype and extract action items (also known as “to do” items), and due dates for those items. For example, if you look at the first activity above, we need to figure out the mechanics, find a way to explain them, create some videos, and devise some way of rapidly giving feedback on lists of mechanics. All of those are work we need to do to be prepared for class and we don’t want to forget to do it.

Once we actually offer the class, you may want to remember to capture reflections about what went well and what didn’t. This allows you to improve the design the next time we offer it. I like to write these down in the actual materials I prepare so that the next time I’m using them, I have a bunch of contextual reminders of what did and didn’t work. To remember to do this, I create action items for writing reflections about each class meeting after each class.

Secondly, after a class, you may have some grading to do. I like to go through my syllabus, note every thing that must be assessed and by when, and then generate action items for grading. That way I don’t forget to grade anything.

6. Teach the course

If you’ve prepped well, this should be a cinch! And if you’ve done a good job devising active, deliberate practice for everything you’re teaching, it should be engaging and fun for you and the students. Finally, if you’ve extracted action items well, you shouldn’t have a lot of unexpected work. Instead, you can just stay on top of all of the work you planned, keeping at least a week ahead of the class in terms of content creation.

7. Synthesize reflections into revisions

After the course, and especially getting feedback from students throughout the course and after in student evaluations, you should have a big list of possible revisions and a lot of feedback about what did and didn’t work about your design. Take the time immediately after the course to synthesize all of this feedback into a plan for revisions. That way, the next time you teach the course, you have a well-developed plan for improving it and you won’t have to remember everything from the three months ago, a year ago, or longer.

How long does this take?

Obviously, our little example doesn’t really capture the scope or scale of a quarter or semester long course. And if you’re prepping for a whole year in a K-12 setting, you have an even greater challenge. I find that after a decade of teaching, prepping a new course can take me about 5 hours per 1 hour of instruction, not including the actual time for instruction. That includes time for devising learning objectives, time to create materials, time to reflect, and time to grade. That means for a course that meets 4 hours a week, you should expect 20 hours a week of preparation and grading, plus the 4 hours a week of teaching. If you’re planning ahead (and you should!), perhaps half of those prep hours can be front loaded before a class starts. In all, for a quarter long course like I teach, that means spending 100 hours of prep before the quarter starts and another 10 per week during the quarter, plus class time. For a semester, this would be 150 hours of prep before the semester, and 10 per week during the semester plus class time.

Once you’ve taught the class once, this prep time drops considerably. For a 4-hour per week course I’ve already designed, I spend as little as an hour prepping, and most of my time providing feedback. And if I’m extra motivated to improve a course, I may retroactively improve materials as I go.

What if you’re inheriting course materials?

If you’re getting materials from another instructor, you might be tempted to just use them, assuming they’re well-designed and well-optimized. There are a couple of reasons this is a bad idea.

First, most courses aren’t well-designed or well-optimized. It’s a good idea to first evaluate the design of the materials for quality (e.g., qualities of effective deliberate practice) and extract the rationale for the design of the course from past instructors. This can help you first judge whether the materials require any tweaks. Where revisions are necessary, you can use the process above to redesign any parts of the course you think need improvement.

The more significant reason to redesign materials is that courses are often tailored to an individual instructor’s personality. For example, one of my colleagues, Jason Yip, has an insatiable, infectious optimism, which allows him to engage students in all kinds of activities I could never convince students to do, whereas I bring to class an authoritative, reflective, more serious tone, which allows me to more easily engage in heady debates. Teaching methods, especially active learning methods, depends on personality, and so they aren’t easily transferred.

Because of these concerns, if you’re inheriting a course and it’s materials, I recommend first deconstructing it’s learning objectives and methods, and rebuilding it using the process above. Then, the course design you inherit just becomes a set of inspirational content to accelerate and inform your design process rather than a straightjacket, constraining your innovation. If you’re lucky, you may find that the class you inherit is great as is, and just requires some tweaks for your personality. And if you’re not so lucky (say the course is terrible and you don’t have the authority to overhaul it), your superiors will still recognize their materials and learning objectives when they see your work, but they’ll also notice that you completely rebuilt it’s engine to your own exacting high standards.

Can’t I just do lectures, homeworks, and exams?

Sure. You can use the whole process I devised above, but just with lectures and exams. Students will learn less, you’ll be more bored, and you’ll still spend the same amount of time designing slides, writing exams and homeworks, and grading them, so I don’t really think it saves you anything, other than potential embarrassment from failed pedagogical experiments. When most lectures are failures, you don’t have much to lose.

So try to aim higher, be creative, and be a better teacher! We don’t prepare new materials very often, so when we do, we should do it well.