The project that taught me UI thinking isn't enough.
This was my first mid-sized project, less than a year into the job. Multiple internal teams each had something they wanted to push to customers — education tips, marketing alerts, operational reminders. Nobody was thinking about what the customer should actually pay attention to first.
I built a notification system. It worked. But the moment it launched, I realized I'd missed the most important problem: I never defined what mattered most. Customers had dozens of notifications and stopped looking at them.
What I got right: the system architecture, the surfaces, the cross-team alignment. What I got wrong: I designed for visibility, not attention.
Property managers using this platform needed to stay on top of activity across reviews, leads, surveys, and billing — all at once. Meanwhile, multiple internal teams each had signals they wanted to surface to customers.
The ask seemed straightforward: build a notification system.
What I didn't realize going in was that the harder problem wasn't "how do we send notifications" — it was "how do we decide what's worth interrupting someone for."
Product Designer, end-to-end ownership. This was also my first project where I was responsible for defining system behavior, not just interface patterns. I was less than a year into the company, and I was learning what that actually meant in real time.
Four internal teams had legitimate reasons to notify customers: