Those who've followed me on various other platforms will probably have heard bits of this spiel before, maybe worded slightly differently in each instance, but ultimately discussing the same ideas / talking points. So I thought it'd be good to write up a canonical version once and for all - especially since it's unlikely that I'll end up doing this anytime soon anyway (i.e. never say never, but at least for the foreseeable future in the next 3-5/10 years, I'm honestly not really that interested in a return to academia or teaching).
Key Points:
1) I've seen things. Perhaps a whole lot more than most people get the chance to see, and with a bunch of variables controlled for (or at least held somewhat constant).
2) From my observations, left to their own devices, the majority of students gravitate towards doing certain things that, left uncorrected / undiscovered (until too late usually) practically mean they probably don't learn half the lessons they probably really ought to (i.e. From my perspective, they practically learned nothing (beyond maybe picking up some new trivia that'll be gone soon after the final exam) and just tried to get an easy pass on a course they may have thought was one of the "easier" ones they may be required to take). At least IMO.
3) "UCAPT" - A useful mnemonic I developed during my time doing this, which I adopted for evaluating student's work (+ and also later in my own practice) to check if all the necessary things have been accounted for.
Some Background Context First
As I do note on my CV / for all application materials relating to teaching HCI courses in particular, I've had the privilege of helping teach (as TA / Tutor) multiple successive cohorts of students taking a 3rd year HCI course, but taught by different lecturers (and in different ways / with slightly different content each time). This is of course in addition to the version of the course that I myself took back in the day.
I must also stress that I do not mean to say that what the lecturers of said courses did was bad per se. I'm just saying that these are some of the slight practical implementation tweaks I'd personally make to the running of the course to really maximise their learning (so they're not bumbling around trying needing their mentors / supervisors on their first jobs needing to do quite so much hand-holding on navigating these issues).
Common Student Behavioural Patterns / Biases / Blindspots / Tendencies / etc.
Over the 3-4 years I tutored these courses, I observed that, left to their own devices, students would end up naturally doing the following things pretty much every single time, without considering the possibility that there are some alternative options.
1) A good chunk of all individual students (or students working in groups) will end up spending some portion of their time in class (when working on UI designs) / outside-of-class-doing-assignments on creating / describing / illustrating often elaborately detailed + described variations on some or all of the following things pages / forms: "Login / Sign Up / Forgot Password + Reset Password / User Profile stuff / Socials Connecting + Linking + Sharing stuff"
Meanwhile, for the actual domain-specific + functionally interesting / key-interactions + designs, etc., they are very light on details (likely as they ran out of time doing all that busywork regurgitating stuff they've seen in various forms everywhere). If they did bother to spend more time on that stuff though, they often have only scratched the very surface (something that's quickly evident if you catch them early enough in class circling the drain and probe/steer them with some leading questions, and they realise they didn't know to think in that direction at all)
2) When asked to choose an App / UI project to work on, many students will end up creating some kind of Recipe Suggestion type thing. The more adventurous may attempt some GPS / Geotagging Thing instead. (The rare one might propose something with some actual niche use-case for good in the community, which is always really refreshing to see)
3) When asked to come up with a mechanism for sharing data between two devices, most of them settle on the first idea that comes to mind:
``Oh that's simple - just make them both *connect / "sign in" to <blah> server*, then "A" can send to "B" (with variations whether "B" needs to be actively logged in at the same time or not).``
What they don't do (and really, it is a massive loss for them, as they don't get to really try to build + flex their design thinking muscles) is to instead consider the "mechanics" of the interaction, especially for considering if there may be easier / better / alternative ways for carrying out the interaction (especially if a different set of constraints other than - "what way will work regardless of where the users are in the world, and assuming that everyone has superfast always on internet" - apply).
For instance, by just reframing the problem to make it your own, you quickly have variants like:
* What if you cannot have internet access / only need to share amongst people who are physically near each other?
* What if the users are temporarily disabled and/or located in physically challenging conditions (i.e. see more in the UCAPT section)
All of a sudden, you can see that we have a *much* more challenging problem that I think engages students more, and you now really have to start engaging with the various concepts a lot more to try to figure out what may or may not work.
How We Can Do Better
With that in mind, if anyone was actually crazy enough to get me to teach such a course (or at least plan / organise / manage it), here's some of what I would do.
Most importantly, the following measure would be implemented:
There would be explicit instructions + expectations stated up front (and repeated at appropriate intervals / junctions) that handing in solutions describing/containing the prohibited things (i.e. designs + flows for "Login / Sign Up / Reset Password / User Profiles / Socials Connect", OR solutions requiring those as an integral means of making those design function) in any labs or assignments would constitute an instant fail for that activity (with suitable penalties for their final grade)
It is only by taking these options completely off the table (with clearly expressed expectations, and suitably severe penalties) that students will get the message that they *cannot* take the easy path and/or waste time doddling around wasting everyone's time regurgitating that crap. Only then do they stand a chance of being actually challenged to actually grow + develop some actually useful skills in the area, instead of getting the wrong idea that they can just fake it by copying one of the many designs they've seen already (without stopping to think whether those designs are even any good, or if they could be better)
As for the in-class projects and/or assignments, I'd personally assign variations on the following tasks. (Note: I'm flexible / undecided on the order in which these are introduced / tackled. But I think both do *need* to be covered):
* 1) One of their projects would be to retrofit a new feature into an existing complex application (i.e. "real world work")
i.e. This is the type of work I personally engage in the most. As most computer users would probably attest to, the one where UI designers / developers usually get things wrong the worst (and with the most dire + annoying consequences). However, for the majority of students, their current training often completely glosses over or neglects to give them even a whiff of experience on this front, so is it any wonder that when they get their first job(s) and eventually have to do this, that they make a hash of it?
* 2) Design a simple UI from from scratch with where there are multiple classes of different users (with conflicting requirements for what each want, a few constraints, and no room for introducing logins or "social" features
i.e. This is the typical "greenfield" work they'd encounter if working at a startup or working for themselves on some personal project, giving them the scar tissue for doing this.
* 3) Critique a badly designed UI feature, and suggest a solution
(Bonus points for doing so in an open source project, and being able to convince the maintainers to change it by making a convincing argument)
UCAPT
The "UCAPT" Acronym / Mnemonic stands for:
* 1) Users
* Who are the users?
* What do they want and/or (more importantly) need to be able to do?
* What are their capabilities + limitations?
* What sort of prior experience / biases / assumptions are they bringing to the table?
* 2) Context
* Where + when are the users using the UI? (i.e. Sitting at a desk in a calm office, on the move, in a challenging environment like hanging off a ladder, or surrounded by kids/clients/etc. all vying for attention, etc.)
* Distractions? Urgency? Constraints / Limitations / etc.
* How often does the user do this? What happens before/after they do this?
* What equipment do they have at their disposal? (What is reasonable to expect, vs maybe optionally present in some cases?)
* 3) Assumptions <--- This is a *really* important one not only when designing, but more critically, when evaluating + debugging
* a) List all assumptions you have about anything + everything. From your own assumptions / biases too (i.e. everyone knows about "x", or users will always do "a" before "b" or do so in a particular way)
* b) For every single assumption, go back and verify whether it's really true, and/or under what circumstances. <--- This here is the real power move, and is the one that is also the real bug squashing magic weapon
* 4) Purpose and Priorities
* First and Foremost: It's important to figure out, in as succinct a form as you can (i.e. "short sentence elevator pitch") what your App / Interface is supposed to help people do.
* Second, you need to figure work through the competing priorities, and how they relate to that purpose statement. i.e.:
* Of all the competing priorities / etc., you need to figure out (i.e. collate + score + rank + order) priorities for how important various aspects / concerns of the design are.
* There will be conflicts. There will also be some that are way more important than others.
* The key thing is to figure out exactly what your priorities are (then go back to step 3 - Assumptions) and iterate until you get this right
* 5) Tasks
* Check whether your users are able to accomplish the tasks they need to with your design.
* To do that, you need to have a clear idea what these are.
* You also need to be considering how their ability to perform these tasks stacks up against the capabilities + limitations in the context they find themselves.
From experience, I've found that if you methodologically work your way through this set of things, you *will* often be able to spot some glaring problems with your design that need to be rectified. It's therefore a great tool for when you think you've already "done everything" (and "very well", too)... LOL... yeah right!
In Conclusion
These are just the crazy ramblings of someone who hasn't really tried / gotten to try putting these ideas to the test in practice (or at least not at any level of scale). Who knows, some of this may be overdone / impractical, or may backfire in weird and horrible ways in practice.
(Also, whether aspects of this approach may actually fall afoul of whatever the relevant university's "idealised teaching/course-design guidelines" look like these days is also open for debate)
That said, having spent time in both academia AND as a practitioner facing these very scenarios in my own work, I'd argue that we're selling our students short if their training is NOT beefed up to actually challenge them beyond the bubbles of ignorance they often reside in. In that sense, I feel that I am a bit of an "old school" academic in some senses (vs all the newfangled bunch who are busy messing around with Audience Response Systems, and all that other jazz)
No comments:
Post a Comment