I came in thinking I already had a pretty good handle on HCI. I’d done the coursework, built things, sat through enough design critiques to know the language. So my honest assumption walking into 247B was that it’d be familiar territory. Maybe a chance to go deeper, but not somewhere I’d be genuinely caught off guard. But I was definitely wrong about that.
Our project was Tuck-In, a mobile app for helping college students build more consistent sleep schedules. The premise was that bad sleep isn’t really a willpower problem. There are specific patterns and personal blockers that get in the way, and an app could help students identify and work around those. I got most invested in the early research phase, figuring out what the actual problem was before we touched any design decisions. That part felt important to get right before anything else.
What I loved most was iterating. There’s something genuinely satisfying about taking feedback, even when it stings a little, and watching the design shift because of it. What was harder was the timeline. We were working off a partial prototype, which meant our usability testing felt more limited than I wanted. I kept running into this tension between what I wanted to learn from users and what we actually had bandwidth to test. A 7 week study can only really reveal so much, and sometimes I felt like I was pushing the limit when it came to the actual analysis/synthesis.
The moment that actually stuck with me the most didn’t come from our own project. It came from a sketchnote, this idea that environments are one of the biggest levers in habit change. I actually started thinking about that in my own life and the kind of habits I want to change. For example, I really want to be better at intuitive eating, but going out with friends all the time just puts me in an environment where that becomes a lot harder. So, in a sense, this class really helped me in terms of not being as harsh on myself when it came to behavior change.
On the ethics side, Tuck-In uses a progress bar and rewards to encourage consistent sleep habits. I think those are acceptable nudges in most cases since they’re transparent, opt-in, and tied to goals the user set themselves. But I do think there’s a real risk for someone dealing with something heavier, like chronic insomnia or anxiety that shows up at night. An app that gamifies consistency could add pressure in those cases rather than ease it. The nudge stops being okay when the user can’t opt out of feeling like they’re falling behind on their own health. That’s something worth taking seriously if Tuck-In were ever developed further.
Sleep data is also genuinely sensitive in ways that aren’t obvious at first. It can say a lot about mental health, stress levels, and daily life patterns. Our project didn’t collect data in a way that raised immediate red flags, but a more developed version would need to think carefully about what gets stored, for how long, and who could ever access it. The framework I keep coming back to is contextual integrity. Data you share in a personal wellness app should stay in that context. It shouldn’t travel to advertisers or researchers without clear, informed consent.
On the design side, I think we did okay thinking about diverse sleep needs during research, but I’m not sure we thought carefully enough about cognitive load. Our onboarding assumed a certain level of energy and tech fluency. For someone who’s exhausted and opening the app at 1am for the first time, a complicated setup is a real barrier. That’s not just a UX problem, it directly works against what the app is supposed to do.
The thing I’m taking away most from this class is that design for behavior change is harder than it looks. It’s not enough to build something clean and intuitive. You have to understand the whole ecosystem someone is living in, the environment, the social context, the emotional state, and design for that full picture. The usability test script is something I’ll definitely use again. The structure of it forces you to separate what you assume users will do from what they actually do, and that discipline is useful everywhere. What I’d do differently is wait until the prototype is further along before testing. The method is solid, the artifact just needs to meet it halfway.
I’m also more okay with unresolved questions than I used to be. But I also get now that that’s just part of doing real design work on a real timeline.
In 10 years time, what I’ll remember the most would actually still be the sketchnotes. I do think that drawing everything out has solidified a lot of concepts in my brain – ones that have quite surprised me. It sounds simple but it actually shifted how I think about behavior change as a design problem.
Next time I’m working on something like this, I want to ask way earlier, before wireframes, before user flows: what is this person doing, feeling, and surrounded by when they’d actually use this? That one question would’ve changed a lot about how we built Tuck-In.
