InHand rethinks the traditional e-commerce return process by introducing AI-assisted, real-time product verification. Customers first describe the issue with their purchase, then complete a series of dynamically generated camera challenges—such as rotating the product, changing angles, adjusting distance, or revealing specific details. AI analyzes these interactions alongside the customer's claim to determine whether the product condition can be verified.
The goal is to give merchants stronger evidence before approving refunds. By replacing static photo submissions and repetitive manual review with an adaptive verification flow, InHand aims to reduce fraudulent claims, lower operational costs, and create a more trustworthy return experience for both merchants and customers.
TIMELINE & STATUS
1 day · Team of 4
TOOLS
Figma, FigJam, Base 44, Codex, Github
ROLE
UIUX Designer & Front-end Developer
SKILLS
Market Research · UX/UI Design · AI Integration · Rapid Prototyping · Front-End Development
E-commerce returns create significant costs for merchants through the time required to review claims and determine whether they are legitimate.
Annual Cost / Loss Related to E-commerce Returns

Manual verification doesn’t scale.
Reviewing suspicious claims requires time from customer support or operations teams, making low-value returns especially expensive to investigate.
Static evidence is easy to manipulate.
Photos can be reused, edited, selectively framed, or generated, making it increasingly difficult for merchants to determine whether an image accurately represents the returned product.
We designed InHand as a lightweight plugin that merchants can integrate directly into their existing return experience.

01
02
03
04
05
Rather than treating every return as suspicious, InHand uses verification to determine how much intervention is actually necessary.
VERIFIED
When the product and reported issue are successfully verified, the return can continue through the merchant’s standard refund process without additional review.
NEEDS REVIEW
When evidence is incomplete or inconsistent, the case is escalated to the merchant with the relevant verification data for manual review.
HIGH RISK
When multiple signals strongly conflict with the return claim, the case is flagged as high risk and the merchant can apply its own return policy before issuing a refund.
Adding fraud prevention introduces a UX challenge: every additional verification step creates friction for legitimate customers.
Our goal was therefore not to maximize the amount of evidence collected, but to collect enough evidence with as little effort as possible.
We mapped the experience around a short mobile-first flow: select the return item, describe the issue, prepare the camera, complete a small set of live challenges, and receive a verification result.
Early wireframes helped us simplify instructions, reduce unnecessary screens, and make each camera challenge understandable within seconds.
01
02
03
04
05
06

Once the core interaction was defined, we moved quickly from interface design to a functional prototype using Base44.
Rather than polishing every edge case first, we focused on testing the central product hypothesis: could a return flow built around AI-generated live camera challenges remain simple enough for customers while providing merchants with stronger evidence?
Building the prototype allowed us to experience the flow as a connected product rather than a collection of individual screens—and exposed limitations that were much harder to see in static designs.

Build Rapid prototype in Base44

Our first prototype focused heavily on one question: Does the product in front of the camera match the customer’s claim?
Through the process, we realized that this alone is not enough to make a reliable return decision.
A stronger system should evaluate the return in context—combining live product verification with signals such as order information, account history, previous returns, payment consistency, and other merchant-authorized risk data.
Most return decisions are evaluated as isolated events. A merchant may see the current order and claim, but often lacks a structured way to understand how that return fits into a customer’s broader behavioral history.
A future version of InHand could build a merchant-authorized return history from transactions processed through the platform. Instead of starting every verification from zero, the system could combine current evidence with historical return patterns to produce a more contextual risk assessment.
The decision system could also adapt to each merchant’s policies and risk tolerance.
A low-value item may qualify for an instant refund, while a high-value or high-risk claim could require stronger verification or manual review.
Customer
↓
↓
↓