Lost & Found:
A Trust Problem

The Problem

Five WhatsApp Groups. Zero Solutions.

As a VIT student, I personally lost my ID card and spent two hours scrolling through WhatsApp groups trying to find if anyone had posted about it. Messages from the previous day were already buried under 200 new messages. There was no way to filter by category, no way to search by location, and sharing my phone number with strangers to get my belongings back felt genuinely risky.

I was not alone. Talking to friends across CS, Biotech, and MBA programs, everyone had the same frustration. We all relied on the same five WhatsApp groups and they simply did not work for this problem.

"What users say the problem is and what the actual problem is are not always the same thing. Testing reveals the truth."

My initial instinct was that the problem was just a lack of a centralized place. But after usability testing, I realized the real problem was trust: how do I prove this is mine, and do I really want to give my number to a stranger?

My Role

Leading Design for a Team of Eight

This was my first time coordinating other designers, and it taught me more about communication than about design. My responsibilities spanned the full project: I built a shared Figma design system on Day 1 so all four designers used the same components, colors, and spacing. I ran weekly Monday reviews to align the team and give feedback. When disagreements came up (tabs versus bottom navigation), I made the call. I also owned the developer handoff with precise specs for four engineers.

The hardest part was saying no to features people were excited about. One designer pushed hard for a bookmark feature. I cut it because it was not in our top three user needs. What I would do differently: involve developers much earlier. Some ideas, like an animated campus map, were not feasible in six weeks. I found that out in Week 4, not Week 1.

Research & Discovery

What the Data Actually Said

Research started with our own lived experience as VIT students, which gave us a strong starting point but also introduced assumptions we had to actively challenge. Three themes emerged consistently across interviews and usage observation.

Zero feedback loops. After submitting a lost item, users received no acknowledgement. No confirmation, no notification, no indication that anyone had seen their post. The silence felt like abandonment.

Trust collapse at handoff. The most stressful moment was not losing the item. It was the handoff: meeting a stranger, handing over a valued possession, with no verification system in place. Multiple students described this as feeling "sketchy."

Search that felt broken. Students stopped using the search functionality after two or three failed attempts and defaulted to scrolling — or left entirely.

Design Solution

Four Flows. One Principle: Make It Feel Safe.

We designed 12+ screens covering four core flows. Browse and Search: a visual layout showing found items by photo, filterable by category. Report Found Item: a guided form with structured fields including photo upload and a location tag. Claim Verification: a request system where finders can verify ownership before any contact information is shared. Track Requests: a dashboard showing what you have posted and what you have claimed.

We chose a calming green palette because losing something is already stressful. Photo first cards came from the insight that people recognize belongings visually faster than they read descriptions. The claim request system kept contact information hidden until both parties verified — solving the privacy concern that research had surfaced.

"Users do not abandon bad features. They abandon the moment they feel invisible."

Low Fidelity

Testing the Logic Before the Look

Low fidelity prototypes focused on three interventions: a real time status indicator for posted items, a verified handoff flow with confirmation, and a relevance ranked search experience. Testing with users revealed that the status indicator alone — a simple "3 people have viewed this" counter — meaningfully reduced the feeling of being ignored. It cost nothing to build and solved the core emotional problem.

High Fidelity

The Final Design

The high fidelity design preserved the simplicity of the original concept while layering in the trust infrastructure: live view counts, verified handoff screens, in app notification threads, and a dramatically improved search with filter tags and recency sorting. The visual language stayed purposefully neutral because campus facing products need to feel official, not trendy. The trust features are the product; the UI steps back and lets them do the work.

Usability Testing

3 Students. 4 Tasks. The Quotes Revealed the Real Problems.

I conducted moderated usability testing with 3 VIT students — one each from CS, Biotech, and MBA — to see if they could navigate the core flows. Each participant completed four tasks: browse for a lost item, report a found item, claim an item, and track a claim request. All four tasks had a 100% success rate. But the hesitations and questions in between told me what needed fixing.

Task 1 — Browse. "The labels 'Lost' and 'Found' were a bit ambiguous. Lost by whom?" Fix: reframe as "Items found on campus."

Task 2 — Report. "'Unique identifier' — what does that mean? Like the serial number?" Fix: rename to "Identifying details" with a tooltip showing examples.

Task 3 — Claim. "After clicking Claim, nothing tells me what to expect. Will they message me?" Fix: add a confirmation explaining the 24 hour notification window.

Task 4 — Track. "'Active' is vague. Does that mean they saw it, or I just submitted it?" Fix: change to "Awaiting Response" with a timestamp.

Outcomes

What Changed

The verified handoff flow — the biggest design risk — was rated the feature participants most wanted in the live product. The redesign taught me that trust is a design material. You can engineer it intentionally through visibility, feedback, and verification, just like any other feature.

The app was handed off to VinnovateIT's development team within the six week timeline. It was not built during my time with the project. That is the honest reality. But the testing surfaced issues we could fix before engineering started, which is better than shipping and discovering confusion afterward.