Author's Note: This post is neither here nor there. It's probably a little too flippant, but it's Friday and I've had a couple beers.
We are roughly at the midpoint of the semester, so today I solicited anonymous feedback from my Human Computer Interaction (HCI) students. One comment I got goes something like this (paraphrased):
Why do we spend so much time on critique, and so little time on actual designing? I didn't feel like I have the skills/tools to create a good design for the assignment.
For some context, here's our rough syllabus:
- Week 1: Introduction to user-centered design.
- Weeks 2-3: Principles of perception, motor control, cognition, and interaction. Assignment: design critique.
- Weeks 4-5: The design process of ideation, user testing, and iteration. Assignment: mobile re-design.
- Weeks 6-7: HCI and AI in conversational interfaces. Assignment: chatbot.
I want to use this blog post to explore the surprisingly good question posed by the comment. My class ended at 10:30 this morning, and I ended up with three responses after this question bugged me the rest of the day.
First, the part about tools. First, tools are the first things to change - Sketch is the current trendy design app, but another one could replace it tomorrow. You could design with Adobe XD or InDesign or Photoshop, or you could make delicate line drawings on paper. I did show a brief demo of InVision in class, because it was the easiest way to add interactivity, but I honestly prefer prototyping directly in HTML/CSS. I didn't spend time on HTML/CSS for the same reason I didn't spend time on Photoshop: the learning curve was too steep and you can easily do without.
But second, I think there is this misconception that knowing the tools will make you a good designer. A tool might help you design faster if you have mastered it, putting the tool on your resume might get you past an automated filter, but it won't make you a better designer. Good designers are not good because they use trendy tools, trendy tools are trendy because good designers use them. All the pixel-snapping and grids and symbols won't help you if you don't know how to put them together into a good design.
Second, learning to design is learning to see. We could stop at saying that this design is "good" and this design is "bad", but that doesn't offer much guidance. All the time spent on critique is so we have the vocabulary - signifiers, friction, mental models - to describe everything that is wrong. This particular instance of HCI probably spends above-average time on perception and cognition - but then again, this course is crosslisted between computer science and cognitive science.
A philosopher colleague of mine recently talked about how she was in the rainforest in Costa Rica, and how her hiking companion, a biologist, muttered "nope, just a cricket" while looking for grasshoppers. To quote my colleague, she "didn't see a damn thing" - not the non-existing grasshopper, not the cricket, nothing. There is something to be said for the "mere" skill of noticing, and that's what the critiques are building towards.
Raymond Hettinger has this amazing talk at PyCon 2015 where he refactors a bit of Python code. The code has obvious issues with spacing and extraneous comments, which he fixes. The PEP-8-fied code looks great - until he points out that the code is still Java-esque, when Python has constructs that make it 80% shorter. It's like that joke about Sherlock asking Watson what seeing the stars tells him. Noticing is hard.
I once read somewhere - and I wish I could remember where - that artists start by absorbing what they consider "good" art before trying to create their own. Of course, their first piece is terrible, but that's because there's a mismatch between what they created and what their model of "good" art is.
I'll be honest here: I'm not sure I know how to teach someone to be a good designer. (Not the least because I'm not a designer, but that's beside the point.) All I know is that when I design something, I make it first, I notice places where it doesn't work, and I try and fix it. Eventually, after doing this enough times, my first iterations have fewer places that don't work. Eventually, after doing this enough times, the fixes become "intuitive".
I guess what I'm saying is that the "skill" of being a good designer is just noticing the problems and fixing them, over and over again. By definition, I can't teach you that intuition - at least, if there's a way to teach it, I haven't discovered it. All I can do is point out all the things that I notice and how I would fix them, and hope that at some point you start noticing the same things.
Could I have spent more time on designing and less on critiquing? Yeah, probably. In my ideal world, I would meet with student teams multiple times during the biweekly design process, and provide critique on things they might change. Heck, I probably will do this in future iterations of HCI.
But I think it is a mistake to expect that enrolling in HCI will make you a good designer. HCI can give you the ideas and start you down that path, but being a good designer probably takes a lot more trial and error, and probably takes more than a semester.
To quote Adventure Time: "sucking at sumthin' is the first towards being sorta good at sumthin'."