A recent study found that “mimicking the effects of a disability for only a few minutes fails to account for the diverse coping mechanisms and innovative techniques persons with disabilities develop in long-term situations. Thus, momentarily experiencing the challenges a disability may create could cause participants to underestimate the true capabilities of persons with disabilities”.
When I first started working on UX Night School, I had some very strong opinions about what, and how I wanted to teach, and how I thought my intended audience: grownups with jobs, wanted to learn. Granted, I hadn’t generated these ideas in a vacuum, but through reflecting on my own work and interactions with others. But still, in starting the design process, we often fall back on assumptions. They’re like the air we breathe.
I can also fess up that these assumptions, which we can be generous and call hypotheses, were fairly reactionary, especially the ones based on my own experiences teaching at UW. There are so many conventions of classroom teaching (especially in Computer Science) that are just painful and alienating.
Lectures, for one. I hate giving lectures, and I hate expecting people to listen to them, and ostensibly take notes in order to repeat the points back to me that I may or may not have actually made in a quiz or written assignment. And quizzes, too. NO THANKS! I said. And although I’m always recommending books and articles to folks, I was loathe to assign reading. I’d had too many nightmares of assigning reading and just seeing the PAIN in my students’ faces, or the blank looks when I tried to initiate discussion. I’m no sadist - I like learning, and teaching, in fun, embodied ways, working with other people and moving around.
“No powerpoint presentations, no videos, no homework, no assigned reading.” I wrote in my initial website copy. And up until recently, I’ve been very faithful to this. UX Night School’s Workshops are, without exception, very active - we survey the neighborhood for accessibility barriers; we interview local business owners in their shops; we build paper prototypes and test them. Increasingly, participants take active roles in this: leading interviews, recording them, analysing them, building prototypes. And I’ve been really amazed at how folks have stepped up to the challenge.
Yet, iterative design means you take note of what people ask for. And to my surprise, people have asked for readings! They asked me for backstory, for why we do these things, instead of just how to do them.
So I did something wild in winter quarter: I gave a lecture! I got real geeky and talked about industrialisation, ergonomics, and the history of human-factors. And people said “Thank you!” My mind was blown, but in a good way. It makes sense, I thought. We all need a narrative to initiate action.
With the feedback of the Portland workshop crew, I decided to build out a 5th workshop, all about this question of “Why do we do what we do in Human-Centered Design?”. And to make things interesting, I built it as a self-paced online course.
So here’s the next step: to test our hypotheses. We’re going to do it by offering this course free to a small, diverse cohort of students, in exchange for their engagement and feedback. Interested? Apply here to join us - we’ll kick off April 23, and selected participants will have 30 days to complete the course.
Engineers still tend to believe in logic. They often explain to me in great, logical detail, why their designs are good, powerful, and wonderful. “Why are people having problems?” they wonder. “You are being too logical,” I say. “You are designing for people the way you would like them to be, not for the way they really are.”