HuskyFind
A centralized platform for recovering lost items at UW
Timeline
Spring 2025
1 month
Client
HCDE 310
Role
Product Designer
Overview.
Context
As my first end-to-end UX project, I designed and developed HuskyFind from research through implementation.
At the University of Washington, students often rely on Snapchat stories, group chats, and word of mouth to recover lost belongings, making the process unreliable and difficult to navigate.
I explored how a centralized digital experience could make reporting, discovering, and claiming lost items simpler, more private, and more trustworthy.
The Problem
Students relied on scattered social media posts and informal networks to recover lost belongings, creating an inconsistent experience for both owners and finders.
The Opportunity
How might we create a centralized platform that helps UW students recover lost items quickly without relying on social media?
The outcome
A functioning web application where students can post, browse, and claim lost items using automated email connections.
Research.
Before designing anything, I wanted to understand:
How do students currently recover lost items on campus?
What's already here?
UW Snapchat Stories
Fast visibility, but posts disappeared quickly.
Facebook groups
Community-driven, but reached a limited audience.
Reddit threads
Difficult to search and verify ownership.
Each platform solved part of the problem, but none provided a centralized, trustworthy way to recover lost items.
Conversations with students
3 interviews, 15 minutes each
I spoke with UW students about their experiences losing and finding items on campus, the tools they used, and the frustrations they encountered.
Three key insights
that shaped every design decision that followed.
Students didn't know where to look.
Students searched multiple places—mostly Snapchat and department offices—with no clear starting point.
Design implication
Create one centralized destination.
Returning items felt uncomfortable.
Students described posting publicly as "exposing."
Design implication
Prioritize privacy.
Recovery took too much effort.
Students often called multiple campus buildings or searched several channels.
Design implication
Reduce friction throughout the recovery process.
Ideation.
One solution stood out.
A digital marketplace for lost items.
I chose the marketplace approach because it minimized operational complexity while making recovery accessible from anywhere on campus.
Assignment constraints to keep in mind.
6-week timeline
Working web application required
API integration required
Those constraints shaped both the scope and technical decisions.
Design.
were fully implemented using Python (Flask), HTML, CSS, and EmailJS API, translating my designs into a functioning end-to-end product.
Submit item
Quickly submit found items with photos and descriptions, making it simple for others to identify and claim their belongings.
Browse listings
Explore reported items through a centralized, easy-to-scan directory that streamlines the recovery process.
Claim Item
Claim an item by submitting your information, automatically connecting you with the finder through email to coordinate its return.
After completing the initial build, I revisited the project, reflecting on lessons from development, feedback from my professor and peers, and opportunities that weren't possible within the original implementation constraints
Weak visual hierarchy
The interface didn't clearly guide users' attention, making it difficult to identify primary actions and quickly scan listings.
Design implication
Improved typography, spacing, and button prominence to create a clearer visual hierarchy.
High cognitive load
Dense forms, repetitive inputs, and cluttered layouts made the experience feel more complicated than necessary.
Design implication
Simplified layouts, reduced unnecessary friction, and made key workflows easier to complete.
Limited trust and accountability
Users wanted greater confidence in who was using the platform and what would happen after submitting or claiming an item.
Design implication
Introduced UW NetID authentication, clarified system feedback, and streamlined the recovery process.
In response to the feedback,
The redesign includes
Improved usability
Added UW NetID authentication and clearer feedback to improve trust and reduce uncertainty throughout the recovery process.
Increased trust & clarity
Added UW NetID authentication and clearer feedback to improve trust and reduce uncertainty throughout the recovery process.
Final Product.
Outcomes
Designed and developed a fully functioning end-to-end web application
Implemented an automated claim workflow using EmailJS API
Redesigned the experience based on development insights and design feedback.
Strengthened my ability to balance user needs with technical constraints.
Reflection.
Designing with implementation in mind
Building HuskyFind taught me that strong design decisions also need to be technically feasible. Working within a six-week timeline helped me prioritize the core recovery flow and make intentional tradeoffs between functionality and scope.
Iteration doesn't stop after development
Implementing the product revealed usability issues that weren't obvious in static mockups. Revisiting the project reinforced that development is another opportunity to learn, evaluate, and continue improving the user experience.
Looking ahead
If I continued developing HuskyFind, I would conduct usability testing earlier and throughout the design process, strengthen claim verification to reduce misuse, and continue improving accessibility across the experience.
Have a project in mind?
We’d love to hear from you — whether you have a project in mind, or just want to say hi.