Before class
Before this class, I thought behavioral change was mostly influenced by an individual’s lack of motivation or willpower to start or stop a habit. I also did not realize how many social and environmental factors can shape behavior. I expected influences to be primarily biological or chemical. For example, I tended to associate behavior change with more extreme cases such as addiction rather than subtle daily habits. I also assumed that designing a solution for behavior change was a relatively linear process. Through the course, I realized that design thinking involves much more iteration, testing, and refinement than I initially expected.
During class
One of my favorite parts of the class was discussing the weekly readings on behavioral change. The reading that especially stuck with me was Tiny Habits by BJ Fogg which introduced the flexible yet effective concept of anchoring. Christina’s article on considering the ethical consequences of engaging with “evil” AI companies also stood out because it made me think more critically about the responsibilities designers and technologists have when building products.
Beyond the readings, I appreciated being introduced to a variety of models, frameworks, and tools. Some of them felt somewhat redundant since there was overlap with CS377G and CS177, which I took last quarter. However, that repetition actually made me more confident in applying these tools. At the same time, I found that certain models, such as the connection circle, can become visually complex. While it was interesting to map out many factors that influence an outcome, I wondered how practical such a diagram would be in real professional settings. If I were presenting something like this to colleagues or executives as a product manager, it might be difficult to extract quick and meaningful takeaways given the number of factors involved.
I also really enjoyed several of the guest lectures, especially Deb Aoki’s workshop on drawing and Jim’s lecture on vibecoding. Deb’s workshop was particularly memorable because it taught us a practical skill that I know I will use in the future. I now feel much more confident sketching quick visuals to communicate ideas, especially when drawing people, which I used to find difficult. The workshop also showed how expressive drawings can tell a narrative that helps teams empathize with users and visualize potential solutions. As for Jim’s lectures, I always enjoy them because he consistently introduces frameworks and tools that are both clear and practical. Having taken CS177 with him before, I know many of these frameworks and skills (e.g. vibecoding) will continue to be useful in my future work as a product manager.
Reflecting on our group project, I wish we had more time to develop our prototype. We were able to quickly vibe-code a functional front-end prototype, so it would have been exciting to also build the back end and potentially launch the app. I spent a lot of time designing a Figma prototype that aligned with our mood board and style tile, so I would have loved to see the app fully built and available to use. Some of our friends also mentioned they would genuinely want to use the product, which made me even more curious about how it might perform in real life.
Ethical considerations
Our project, Anchor, included mechanisms such as scheduled notifications and streaks to encourage microlearning. I thought these features are acceptable nudges since their intent is to remind users to engage in an activity they already want to do, which is learning. Additionally, the notifications are set up by the user and can be modified at any time, which helps prevent them from becoming overwhelming or intrusive.
However, these nudges could become manipulative if the messaging on the notifications were designed to guilt-trip or pressure users. This could be especially problematic for our “Optimizer” persona, who is already very busy and constantly trying to maximize productivity in every part of their life. If notifications framed learning in a stressful or judgmental way, they could unintentionally increase anxiety rather than support healthy behavior change.
Now I think this
After taking this class, I now understand that changing user behavior begins with deeply understanding the user. During our initial baseline study interviews, I was surprised by the diversity of participants’ mindsets, goals, and routines. It quickly became clear that a single solution would not work for everyone. Because of this, we created four different personas and chose to focus on one in particular. We ultimately selected the “Pure Vibes” persona as our target user and designed our solution around anchoring. This persona tends to learn spontaneously but lacks consistency, so the anchoring technique felt like the most natural way to support their behavior change.
Next time when faced with a similar situation I will…
Next time I approach a similar problem, I will spend more time understanding the user’s background and needs before jumping directly into a solution. When designing software products, especially when trying to increase metrics such as engagement or retention, it’s easy to default to adding more features or gamification elements like streaks and leaderboards. This class helped me realize that solving a problem is not simply about adding features—it’s about identifying the root cause and addressing it directly.
I will also prioritize continued iteration and testing as I refine a solution. The intervention study, assumption tests, and usability testing in our project were particularly valuable because they challenged many of our initial assumptions. This experience reminded me of the “9x problem,” where developers believe their product is three times better than alternatives while potential users perceive it as three times worse, creating a large perception gap. In the future, I will try to reduce this bias by relying on structured testing and user feedback throughout the design process.
