Before this class, I thought…
I thought that behavior change was mostly a design execution problem. First, you need to find the friction, then remove it, then ship the product. I came into class thinking that we need to define the user, identify what’s blocking them, and then build around it. I didn’t really anticipate the theory side would matter that much, and I figured the hard part would be the prototyping and testing, not figuring out why people do what they do. I learned over the course of this class that this was a little short-sighted.
I did this work with these experiences…
Our final project, Tuck In, was a sleep behavior change app that is paired with a physical smart teddy bear designed for college students. We identified three different archetypes through our research and interviews: the Picky Sleeper, the Screenager, and Always in Huang. Each persona type had a different relationship with sleep, but they shared the common problem that they couldn’t wind down and their environment wasn’t helping them.
My favorite part of the project progression was the grounded theory phase. I enjoyed analyzing interview transcripts as I felt that patterns emerged clearly and we didn’t need to force solutions into a pre-existing framework. This is different from how I usually approach problems by tending to jump to solutions quickly, so this process pushed me to slow down and actually sit with what people were saying. These three archetypes emerged from this process and I think this grounded theory process really helped us understand our end users more and their pain points.
I thought that the back half of the quarter was much harder, as by the time we were doing the usability testing, it felt like we were moving fast and making judgement calls we didn’t fully have time to validate. I think some of that is just the reality of a one quarter project, but I felt there were moments where it felt like we were iterating on intuition more than evidence.
A specific problem that stuck with me was during usability testing when one of our participants couldn’t tell whether she was logging last night’s sleep or setting tonight’s goal. While it might sound like a small error, it helped reveal to us that our labeling and time context were very unclear and while it made sense to us, because we made it, it needs to for everyone. We caught it and addressed it in the final prototype, but it was a good reminder that assumptions that feel obvious to the designer/creator are not always obvious to the user.
Ethical Considerations
An ethical consideration I thought about during this project is the nudging aspect. Our app is designed to use the bear’s cues, gentle app check-ins, and positive reinforcement to shift behavior. That feels acceptable to me because the user opted in and understands what the system is trying to do, but at the same time I can see how it flips. If in the case a student starts feeling guilty every time they look at the bear, or feels like they are being surveilled by it, this behavior change prompting starts to feel more forced. Moving forward, if we were to create an actual physical bear as part of the experience we would need to stress-test the nudges that do, and how they are perceived by different types of users.
For the privacy aspect, the prototype keeps data local and minimal. But the more important question is what happens if this product scales and someone wants to use that sleep data for a different purpose. Our assumption was that data collected for sleep improvement should only ever be used for sleep improvement and nowhere else, keeping the users personal data personal to them. If we were going to build a production ready app, security and privacy would be one of our core focuses to make sure users feel that they can safely generate data and learn from it without being at risk of exposure.
For design justice, I thought that our three personas were a useful starting point, but they were all created from a small part of the college student population. We thought about edge cases but did not design deeply for all of them, including students with sleep disorders, students sharing small living spaces, or students working night shifts. The physical bear also raises accessibility and cost considerations we did not fully resolve if it were to become a real product, which becomes a meaningful factor in how the app is used. A real launch would need an app-only mode or subsidized options.
What I’ll remember
I’ll remember most the decision to keep the bear as part of the project, rather than an app-only experience. At some point while we were brainstorming it, we considered dropping it because it felt too unconventional and unfeasible. We decided to keep it in the end because it was doing something emotionally that the app alone could not do and provided a unique experience that other sleep improvement apps don’t have. That decision, holding onto something that feels strange because it genuinely serves the user, is something I want to carry forward the next time I am tempted to cut whatever makes a project feel like itself.
Now I think…
I think that behavior change is a system problem and that the interface, while it is important, is just the surface. Users are complex people with different history, beliefs, competing priorities, and lives that don’t always revolve around or fit within our app. I came into this class thinking that good design meant reducing friction and creating a good experience, but now I am leaving thinking it means understanding why the friction is there in the first place, and sometimes designing around it rather than just through it.
Next time…
Next time, I want to spend more time on the messy parts, like understanding users, edge cases, and accessibility. I think that the phase where you have data but no clear answer yet is sometimes uncomfortable and my instinct is always to begin building. This class kept demonstrating that the time spent genuinely understanding the problem before committing to a solution is not wasted and some of the most impactful work you can do to build a good project.
