Life as a UX Problem
UX doesn't stop at the screen. It shows up in clubs, clothing, classrooms, and everyday interactions. These are small stories about seeing ordinary problems, treating them like design challenges, and learning from the results.
Role
Problem Finder
Collaboration
UX@Berkeley, EECS External Relations Team
Tools
Outreach, Canva, Google Survey
UX@Berkeley: The Blind Were Leading the Blind
Redesigning how UX@Berkeley teaches designers and engineers by changing the structure of my own club.
Context
UX@Berkeley split client projects by skill: juniors led the low-stakes, seniors led the high. In my first project, I felt the gap. I was the PM, and I didn't know what a design system was. I couldn't keep my own team on track, and when the client asked how to implement our designs into their actual website, I had nothing.
What that first project actually looked like
The Pitch
When I became Co-President, I brought it to the heads: merge the teams, or keep them separate. Merging meant juniors could finally learn from seniors, but risked seniors doing all the work in the end. Staying separate meant no changes.
My pitch was simple: risk nothing, gain nothing. The club had tried merging once before, and it failed. Nobody had asked why.
Research
So I did the research. Three things were wrong: teams crammed at the last minute, projects fixated on visuals instead of the actual problem, and a club with more juniors than seniors to balance them.
Solution
Merging teams wasn't enough. The learning system around them also needed to change.
I introduced weekly design critiques during our general meetings so every team regularly shared progress, received feedback, and learned from one another throughout the semester.
I also worked with our internal advisors to pressure-test the structure against how professional product teams from places like United Airlines and HubSpot operate before implementing it.
Why design critiques?
Conclusion
Senior designers learned to lead product direction and mentor teammates, while junior designers learned to work in Figma while understanding the reasoning behind design decisions, not just how to make interfaces.
How did I measure success?
EECS Pop-Up Shop: Designed for the Silent Majority
640 responses on my google form survey on what the EECS merch should look like. I designed what they wanted, but still received some hate
Context
EECS wanted to run a pop-up shop, so we sent a survey to the entire EECS student body to find out what they'd actually want.
Research
640 people responded. Most preferred a Minimalist/modern and traditional/academic style. We also gave room for open-ended responses, so we received comments such as:
"Whatever is cheap."
"Low price points."
"Please be affordable."
At the same time, people also wanted quality and durable fabric that lasts. We had to account for that as well.
Result
So we designed just that. Sleek, well-made merch that matched what the majority asked for. But quality means more money, so we had to find a balance between the two
We got talked about…
We designed for the majority, great! But that didn't change the fact that there were some that were still… unhappy
Reflection
As a product designer, I learned that I can't design something that pleases 100% of the market. The loudest critics online rarely represent the actual target metrics. This project taught me to separate emotional noise from baseline user data, embrace product tradeoffs (quality vs. cost), and trust the quantitative research when evaluating a product's success.
