Reflecting with the Fall 2018 Human-Computer Interaction Class

The truth is that I had been a bit down on my HCI class. I set up what I thought would be a wonderfully inspirational cooperation with the David Owsley Museum of Art, and I gave them the challenge of prototyping real solutions to some of DOMA's problems. As with my Spring 2018 HCI class, I wanted these solutions to be firmly grounded both in human-centered research methods and in the general design theories we studied in the first half of the semester by reading Don Norman's The Design of Everyday Things. However, as we moved through the stages of the project, I was not seeing teams doing either of these. In the first iteration reports that they submitted before Thanksgiving, it was obvious that their designs were not really rooted in their research, nor were their designs intentionally applying the principles we discussed. This left a heaviness in my heart, both because I doubted the efficacy of the class and because we were going to be showing our results to DOMA at the end of the semester.

Our primary contact at DOMA was their Director of Education, Tania Said, who has been a gracious and kind partner in this endeavor. Due to the schedule of docent training, we scheduled our final presentations for Tuesday of last week, which was the penultimate day of class. I was impressed by how well my students presented their work and the effort they had put into revisions in the 1.5 weeks since Thanksgiving. It helped that Ms. Said has a grace and wisdom that made her questions uplifting to the students: her questions were fair and honest, yet always supportive and encouraging.

I think we would all call this meeting a success, yet there was one more meeting yet in the semester—Thursday, December 6, which was also the deadline for their projects. I had originally planned to have them present their final projects to each other, but this clearly would have been redundant after the meeting on Tuesday. I decided that my goal for the meeting would be to try to wrap up some of the loose ends, to share with them some of my joys and frustrations from the semester, and to prime their reflections to prepare for the final exam. To this end, I decided to present them with three questions and an activity: What went well this semester? What did not go well this semester? What still puzzles you? The activity would be to write final exam questions.

We pushed all the tables against the walls so we could sit in something like a circle, doing the best that the room permits. I opened the class with a few remarks about my perspectives, and I got them into groups of three or four students to answer the first question. Here is a transcription of the notes from the board after we openly shared our results, slightly expanded from my blackboard shorthand:

• Project pride & satisfaction
• Presentation to Tania Said
• Getting class feedback
• Using the Click-Share system from our seats promotes discussion 
• Second round of paper prototyping helped clarify the difference between sketch and prototype
• Museum visits
• Connecting with a real place / real partner
• Two-week warm-up project provided a trial run before working with the real partner
• Relationship between design principles and Clean Code
• Reading Design of Everyday Things

It gave me satisfaction to see them bring up many of the items that I too thought were our greatest successes of the semester. Of course, we didn't vote or rank these, so some may only be important to one or two students, but that's fine for our purposes. One of the biggest surprises came from the comment about the second round of prototyping. This was a particular exercise where everyone dropped the ball, so we agreed to reschedule literally the rest of the semester so that they could do this homework exercise again. At least the student who spoke up, this gave her the opportunity to really understand it, which is infinitely more valuable than just plowing forward. I was also glad to see students reflect positively on the two-week project warm-up rather than frame it as wasted time and effort.

The next question to cover was, "What did not go well this semester?" I had them get up and move around the room to sit with different people for this conversation—something I had warned them I would do in my introductory remarks. For many of the items, I asked a follow-up questions, whether the conversation included ideas about how to address the things that didn't go well. I used two markers for this: black for the original item, and green for the suggestions. Again, my notes are below, with the green parts offset in square braces.

• Project reports
• Balancing the need for functionality against the practical application of design principles
• [Emphasize making high-fidelity executable paper prototypes]
• Justifying designs as meeting the principles rather than intentionally applying them
• Struggling against "just make it work" vs. a good report
• The former is enforced by department culture
• One commented that I am the only faculty who grades on anything besides whether the software "works"
• [Focus on design (look, feel, operation) over implementation]
• [More practice exercises to practice implementations]
• "Two-class" phenomenon, where first half of the class focuses on DOET and second half on the project, without a clear bridge.
• [Again, high-fidelity executable paper prototypes might help here]
• There were more conversations in the first half than the second
• [Sitting in a circle would have increased conversation quality]
• [Use an Interactive Learning Space for this class]
• Test-Driven Development
• Still confused about types of testing (unit, integration), test-friendly architectures, and how to test first.
• Time management and problem slicing
• Other faculty do not emphasize Agile slicing approaches
• Continuous communication with DOMA
• We had to work around their schedules, which held us back on our tight timeline
• The collection database we used was inconvenient

I will quickly add comments about those last two points. Regarding working around their schedules, I explained that this phenomenon was one of the reasons why the granddaddy agile methodology Extreme Programming calls for an on-site representative of the client, so that they are always there to answer questions and work alongside you. Regarding the database we had, I pointed out that our data was a smaller copy of a live system in use by the University Libraries. That is, it showed what a "real" database looks like, rather than a fabricated one for a class example. 

It was delightful for me to hear students sharing so candidly about their struggles during the semester. Again, they identified many of the elements that had been on my mind as well, but it was more powerful to hear it come from them. I was particularly pleased at their comments about how the architecture of the room was an impediment to our activity.

At this point, we only had about twenty minutes left in the meeting. I told them that I was cutting the third question but still wondered if there was anything that still puzzled them. One student posed a really interesting epistemological question: how do we know if Don Norman's rules are the right ones? This got us into a quick conversation about how his rules in DOET are like Robert Martin's rules in Clean Code: they are not universal rules, but they are frameworks that help us consider what the truth might look like. In retrospect, I should have spoken about shuhari here, but I was trying to push ahead and it didn't come to me in time.

I moved on to the last question, again shuffling the groups. Here are their ideas of what might be a good final exam question for the course.

• What does good design mean to you?
• What are five of the seven Universal Principles described in DOET?
• What are the four stages of the Double Diamond?
• What went well or what did not go well?
• If you were to take this class again, what would you do differently?
• Give examples and applications of the seven Universal Principles
• How would you change the organization of this course?
• Reflect on something valuable you learned and how you will use it in the future.
• Reflect on the outcomes of the course.

When the first item was shared, I asked how the student would assess responses. I think they didn't expect this question, but I assured them it was a good question, and that I was trying to understand the nature of it. A few students suggested that it would be enough to see if the hypothetical test-taker could answer it coherently, to show that they had thought about it. 

The second and third questions really surprised me. Those are so unlike the kinds of questions I give. I wish I had noted at the time whether these were students who had ever taken a class with me before, but I didn't. By contrast, that fourth item is exactly the kind of question I like to ask on a final exam, and the student who suggested it pointed to our notes on the other boards and said, basically, "Just ask those. Those are good questions." 

I had been feeling a bit down in the dumps on Thursday morning for a variety of reasons. The way I put it on Facebook was, "I feel emotionally dead inside, and now I have coffee. I can be apathetic FASTER." At the middle of the day, though, my Game Programming students showed their final projects, and most of them did a great job. That lifted my spirits, but after this meaningful, honest conversation with my HCI students, I felt almost giddy. Of course, maybe it was sleep deprivation, but I'll give them the benefit of the doubt. Maybe I let myself grumble too much about those students earlier in the semester when I was feeling uncertain. They were really a good group, maybe an uncommon mix, but they were paying attention and they were learning.

My original plan was that I would work with DOMA to choose a project they really wanted to see polished up, and then use that in my premiere graduate-level course on Software Engineering. As I recently reported, however, those plans have gone up in smoke. Instead, I will be teaching another section of Human-Computer Interaction. This gives me a chance right away to incorporate some changes, although it has to be done in the all-too-short winter break. But first, I better actually write my final exams. Thanks for reading!