Before this class, I thought this…
I’m going to be honest and say that I did not initially plan to take this class, but I’m very glad I did. When my original Winter CS course turned out to not be what I was looking for, I asked around for something worth taking, and a good friend pointed me to CS247B. I’d never taken CS147 or any HCI class before. My interests have always lived on the more technical side of software engineering: AI, systems, cloud infrastructure, the kind of work where success is measured in uptime and throughput, not user experience. But the class description caught my attention, and I figured I’d give it a shot. What I expected was a different angle on being a software engineer. What I got was something that genuinely challenged how I thought about what software is for in the first place.
I did this work with these experiences…
The biggest thing I took away from this class was learning to actually think about the user, not in an abstract “we should consider the user” way, but making it the real starting point of every decision.
Coming from a more technical background, I always thought of UX as something you layer on at the end. Like, you build software, and then you make it look nice. This class kind of dismantled that assumption. The choices that matter most, what to show first, what the defaults are, what you make easy vs. hard, those are made way before any polishing happens, and they have real consequences for real people.
What surprised me most was how much work happens before you write a single line of code. Pre-study interviews, screening for the right target demographic, intervention studies, post-interviews, comparative research, user flow planning, moodboards, assumption tests, none of this was anything I’d encountered in my software engineering internships. In industry, at least in my experience, you kind of just get handed a ticket and build. The “why” is already decided somewhere above you.
Going through the full process myself made me realize how much gets lost when you skip it. And honestly, it made actually building the app so much more rewarding. By the time we were vibe-coding and putting something real together, we genuinely understood the problem we were solving and who we were solving it for. It didn’t feel like shipping a feature. It felt like we’d earned the right to build it.
Ethical considerations
The class also opened my eyes to the ethical weight of design decisions. Tech companies have spent years designing for engagement, and engagement isn’t always the same thing as value for the user. Learning to notice that gap, and to ask whose interests a design is really serving is really important.
One ethical topic I really enjoyed learning about was Nudging vs Manipulation. A nudge, the way I now think about it, is when you shape behavior in a way that genuinely benefits the user. Manipulation is when you use the same exact mechanisms, but for someone else’s benefit (usually the company’s). And the scary part is that from a purely technical standpoint, they look identical. The same default setting, the same notification timing, the same framing of a choice can be either one depending on intent. That’s not something I ever thought about when I was just building features.
It also made me look at apps I use every day completely differently. A lot of what I’d just accepted as “good UX” is actually very deliberately engineered to keep me engaged longer than I probably want to be. I can’t unsee that now.
Now I think this…
Software is never neutral. Every interface encodes assumptions about who the user is, what they know, and what they need and those assumptions have real consequences. Before this class, I thought of ethics in engineering as something you consider after the system is working. Now I see it as something that has to be baked in from the very beginning, because by the time you’re polishing the UI, the most consequential decisions are already made.
I also just think about products differently now. When I open an app, I notice things I never used to notice. I ask myself why a button is where it is, what the default is and who it serves, what behavior the design is quietly nudging me toward.
Next time when faced with a similar situation I will…
Talk to users way earlier than feels necessary. I used to think of research as something you do to validate an idea you already have. This class taught me it’s how you figure out whether your idea is even the right one to begin with. The times our team felt most lost were usually when we’d gotten ahead of ourselves and started building before we fully understood the problem.
