You might also be interested in this OMSCS FAQ I wrote after graduation. Or view all OMSCS related writing here: omscs.

Over summer in 2019 I took another of Prof David Joyner’s classes: Human-Computer Interaction. (I did Education Technology during summer 2018). Like all of Prof David’s courses, it was extremely rewarding, organized yet unstructured, lots of writing, and felt like a mini-thesis / exercise in industrial design.

Why take this course?

In my day to day job, I build machine learning systems and APIs for both internal and external users. Sometimes, adoption isn’t as smooth or straightforward as I hoped, and I wanted to improve my abilities in product and interface design to lower the barriers for adoption. This includes better understanding of product and interface design methods, having a guiding framework to ask users the right questions, and processes to iterate and improve on design quickly.

I’ve taken courses by Prof David before. Education Technology was a blast—very well run, a lot of writing practice, and I learnt a lot about how to scale and make education more accessible. (The result of this was publishing a MOOC on Effective Data Science). Thus, it was an easy choice to take another course by Prof David.

In addition, I wanted further practice on my writing skills. At work and in my recent classes, most of the writing has been code. Thus, I wanted an opportunity (and the context) to push myself to write more content and material.

What’s the course like?

Note: I took the course over summer—the course in the spring and winter semesters will likely vary.

Like all of Prof David’s classes, HCI is extremely well organised—you can find the full outline here. Overall, there’s zero to minimal coding involved, and A LOT of writing. It comes across as more of a course on industrial design. The bulk of the work involves researching, needfinding, and redesigning two (distinct) interfaces. These interfaces need not be digital—I’ve seen examples of people redesigning shower taps and shove hobs.

There are three main learning goals:

Understand the principles and theory of HCI (e.g., the gulfs of execution and evaluation, interaction design heuristics, etc.) Understand the methodology for developing and evaluating designs, from needfinding, to prototyping, to evaluation. Have exposure to current applications of HCI (e.g., augmented reality, etc.)—this aspect of the course was pretty light

Every week, there’s approximately one - two hours of video lectures. These give a high level view of the principles and methodology covered in the course. In addition, there are weekly readings (3-5 papers / text book chapters) which make up about 40 - 80 pages per week. This can get pretty heavy and you’ll want to keep up with the readings through the course (or you’ll have a tough time cramming for the tests).

Written assignments constitute 35% of the overall grade—there are 10 of these throughout the course which are eight pages each. Over the summer term, this meant one paper per week—I could hardly catch my breath! These assignments alternated between the principle (i.e., more of theory) and methodology (i.e., more of technique) topics.

Throughout the 10 written assignments, you pick an existing interface, perform an investigation, and propose a re-design. It is highly recommended that you enter the class with ideas of some interfaces that you might want to redesign or build—the assignments will be more enjoyable and rewarding this way. Do think through to ensure that the needfinding and redesign can be substantial (e.g., maybe you shouldn’t try to redesign a power socket).

The final project has a weightage of 20% and has a maximum page length of 16 pages. Similar to the written assignments, you pick an existing interface, perform an investigation, and develop a redesign. The difference is that the single 16-page paper will demonstrate your understanding and ability to apply the principles and methodology learnt throughout the course.

During my term, it was unclear whether the project would be a summary of the 10 written assignments, or a completely new interface had to be selected. Prof David clarified that the intent was for the assignments and project to have different interfaces. However, given that the rubric was unclear, students who had started work on projects with the same interface as the assignments were allowed to proceed, though he indicated that it would be less rewarding (perhaps in terms of learning, and possibly the grade). It was also made clear that the TAs would check whether the project was simply a rehash of the assignments.

There were two tests, one midterm and one final that accounted for 35% of the grade. These were not cumulative. The tests involved 30 multiple-choice questions (MCQ) which had five choices each, with between one - four correct answers. I found these tricky and fairly difficult, even though it was open book. The tests assessed on all the material in the lectures and readings (which is A LOT). Don’t underestimate the 30 MCQs, most people take the full two hours and still found themselves pressed for time.

Lastly, participation accounted for 10% of the overall grade. You get points via peer feedback, participating in research surveys, and chiming in on the forum. The opportunity to view other students’ work and provide feedback was invaluable—you could see how others applied the principles and methods in different ways.

What did I learn?

Firstly, you are not your user! Prof David must have reiterated this more than a dozen times over the course. He has a post-it note on his monitor stating this as well. Assuming that you are your user is a key mistake many technical people (e.g., developers, product managers, designers) make. They design products with themselves in mind and assume that users are like themselves. This assumption is highly flawed and doesn’t help with designing better products and interfaces.

Second, iterate, iterate, iterate! The course and projects made me go through first-hand the iterative design and redesign of interfaces. It’s never too early to seek user feedback. There are easy, low-effort techniques to seek user feedback such as paper prototypes, Wizard of Oz prototypes that allow users to walk through the process of using the product / interface, and give you quick feedback.

This is also something that “The Lean Startup” emphasises. Getting early feedback on a product is invaluable. In a start-up, who the customer is and what they find valuable is unknown—thus the earlier you start learning about how users respond to your product and interface, the better. Eric Ries (the author) shares his bitter lesson where his team took six months to flesh out and launch a product that no one wanted to use. On hindsight, running a quick experiment via offering users to a chance to try an idea and measure pre-registrations would have allowed them to validate their idea much faster at lower cost.

I also learnt and had lots of practice on how to write succinctly. (I know, it doesn’t seem so on these pieces—but my readers (read: my wife) says the writing has improved over time.) On average, I had to do literature review and write eight pages of an industrial design paper every week. For someone who doesn’t write often, this was pretty intense practice. However, each week I found myself requiring less time and effort for the same work—I take this as sign that I’ve become more efficient in the writing process. In addition, I also noticed that the quality and content of my writing has improved (slightly) since I started OMSCS (nearly three years ago). Every week, some written assignments are highlighted as exemplary and shared with the class—I had about 5-6 of my assignments highlighted throughout the term.

Lastly, the theory and knowledge picked up is valuable. While my work in the field of data science isn’t directly related to design, I still found the theory and knowledge useful when engaging with product managers and designers—I understand their lingo better now. I came away with a better understanding of how little I know about design and product, and hopefully improved my skills a little in designing products and interfaces (not necessarily visual interfaces) for people. One direct application is the design of interfaces for internal packages and tooling for other data scientists in the team.

What’s next?

Often, we learn a lot of theory and knowledge in a course but it fades away as we don’t apply it. Since the course, I’ve consciously been applying the learnings, from providing suggestions on visual interfaces developed, iterating with users on data and machine learning products, and using the frameworks learnt to better understand the gaps between the user and the interface. Hopefully, this helps me design better products and interfaces for users, with lower barriers for adoption—this was my key motivation for taking the course anyway.

If you found this useful, please cite this write-up as:

Yan, Ziyou. (Sep 2019). OMSCS CS6750 (Human Computer Interaction) Review and Tips. eugeneyan.com. https://eugeneyan.com/writing/omscs-cs6750-human-computer-interaction/.

or

@article{yan2019human,  title   = {OMSCS CS6750 (Human Computer Interaction) Review and Tips},  author  = {Yan, Ziyou},  journal = {eugeneyan.com},  year    = {2019},  month   = {Sep},  url     = {https://eugeneyan.com/writing/omscs-cs6750-human-computer-interaction/}}