Final Reflection
Before this class, I thought behavior change was kind of straightforward. Like if you design the right system (streaks, reminders, rewards), people will just… do the thing. I didn’t think it was easy, but I thought it was something you could more or less “figure out” with the right combination of features. I definitely did not think it would be this complex.
Now I think behavior change is one of the messiest, most human problems you can design for. It’s not just about motivation, it’s also about identity, energy, timing, emotion, and everything else going on in someone’s life. And most of the time, when something “doesn’t work,” it’s not because the person failed, it’s because the system didn’t actually fit them. That realization hit pretty personally for me, especially across the two projects I’ve worked on over the past two quarters.
From CS147 to CS247B
In CS147, I built DareDrop, a playful app that gives people small, daily creative dares. That project was very much about joy, spontaneity, and breaking people out of routine. I was thinking a lot about creativity and play, but not as explicitly about behavior change. Looking back, though, it was a behavior change system, it was just one that leaned heavily on play instead of discipline. In CS247B, we worked on TalkTalk, a language learning app focused on helping people actually stick to speaking and practicing regularly. This was based on a mutual connection our team members had: we’ve never successfully learned a language as adults. For me, I’ve tried Duolingo, structured courses, streak systems, all of it. I always start strong and then slowly fall off. Before this class, I kind of just assumed it was a discipline problem, that maybe I wasn’t consistent enough or didn’t want it badly enough. But through this class, I started seeing it differently. Those systems didn’t really fit my life. They required consistency at times when I didn’t have energy. They felt more like obligations than something I actually wanted to do. They optimized for streaks instead of meaning. And they didn’t align with how I naturally like to learn, which is through conversation, storytelling, and social interaction. Designing TalkTalk forced me to confront that more directly. Instead of asking, “How do we get users to practice every day?”, I started asking:
- What would make someone want to speak, even when they’re tired?
- How do we make language feel social?
- How do we design for imperfect, inconsistent lives instead of ideal routines?
- What does “progress” even mean if someone isn’t practicing every day?
Working with new grads similar to me was also a joy, in learning about their lives, their motivations, their identities. That was perhaps even more rewarding
What I Learned About Behavior Change
One of the biggest shifts for me is realizing that behavior change is less about control and more about alignment. When building DareDrop, I saw how powerful play could be. People were more likely to engage when things felt low-pressure, surprising, and optional. The moment something felt like a requirement, it lost its magic. In TalkTalk, I saw the flip side: if something feels like a chore, even a well-designed system won’t save it. You can add reminders, streaks, or gamification, but if the core experience doesn’t feel good, people will eventually drop off.
This class made me think more deeply about:
- Motivation vs. ability vs. triggers, and how all three need to line up
- How small frictions (like opening an app, thinking of what to say, or feeling awkward speaking) can completely break a behavior
- How important identity is, feeling like “I’m someone who speaks this language” instead of “I should practice more”
It also made me realize that behavior change is rarely about one big intervention. It’s usually about small, repeated moments, and whether those moments feel easy, meaningful, or worth returning to.
What Worked, What Didn’t
I really liked how hands-on and experimental this class was. Running quick experiments, making test cards, and talking to real users made everything feel grounded instead of just theory. It also forced me to test assumptions quickly instead of overthinking things. At the same time, it was sometimes uncomfortable how ambiguous everything felt. There’s no clear “right” answer, and even when something works in one context, it might not work in another. There were moments where I wanted more certainty: like a clearer signal that we were moving in the right direction. But I think that uncertainty is part of designing in this class, since people aren’t consistent, so the solutions won’t be either.
A Challenge I Encountered
One challenge with TalkTalk was designing something people would actually come back to without it feeling like pressure.
We found that:
- Too structured , people feel like homework
- Too unstructured , people don’t know what to do
- Too frequent, can be overwhelming
- Too infrequent, can be easy to forget
There’s a really balance between inviting behavior and demanding it. We tried to make things more lightweight and social, for example, focusing on quick, low-stakes speaking prompts instead of long lessons, but it still feels somewhat unresolved. Different people respond to different levels of structure, and it’s hard to design something that works for everyone.
Ethics & Behavior Change
This class also made me think more critically about the ethics of what I’m building.
In TalkTalk, we’re trying to encourage people to practice speaking more. But that raises questions like:
- Are we helping people, or just giving them another thing to feel guilty about?
- Are we designing for real learning, or just engagement metrics?
- Who might feel excluded or intimidated by speaking-based interactions or starting language learning?
Some of the things we talked about in class also came up in our product. For example, I think a nudge is okay when it aligns with what the user actually wants and supports their well-being. If it starts prioritizing engagement over the person, like pushing people to maintain streaks at all costs, it can become manipulative pretty quickly. This made me more aware that every design decision carries some sort of value judgment, whether intentional or not.
What I’ll Take With Me
I don’t think I’ll remember specific frameworks from this class as much as I’ll remember the experience of actually working with people and running experiments. A lot of things that felt like they should work didn’t really work once we tested them. And sometimes small changes, like how something was phrased or when it showed up, made a bigger difference than expected. I think the main thing I’m taking away is not to overthink things upfront. It’s better to try something quickly, see how people respond, and adjust from there.
Next time I work on something like this, I’ll probably:
- Talk to users earlier instead of waiting
- Test smaller ideas instead of building everything out
- Pay more attention to behavior instead of just feedback
Also just getting more comfortable with the fact that things won’t work the first time, and that’s kind of the point.
