Claims Flow Re-Design
A redesign of Plick’s claims flow to reduce manual support, increase self-service and give users clearer control when something goes wrong with a purchase.
Plick is a second-hand app for clothes where users buy and sell in a social, user-driven feed.
Company
Plick
Year
03-05/2025
Role
UX/UI
Research
Flows
Copy
01. Background
Can we make this
easier?
In Plick’s app, buyers are protected through an in-app buyer protection: when a purchase is made, the money is held for 24 hours before being paid out to the seller.
If a problem occurs during this time, the buyer can open a claim, which pauses the payout until support makes a decision.
Previously, all claims were handled manually via support chat, where support had to collect information from both buyer and seller. Resolutions, such as partial refunds, often happened outside the platform via Swish. This way of working was time-consuming, hard to get an overview of, and could be made more efficient – both for users and the support team.
02. Goals
Our goals were to reduce the number of returns to save both money and climate impact, offload support by cutting down on manual chat-based handling, encourage more self-service by helping buyers and sellers reach agreements on their own, and give users a clearer sense of overview and control throughout the entire claims process.
03. Process
The path towards a better solution
I was responsible for flow design, UI and copy, working closely with the support team. I had also spent time working in support myself, which gave me a solid understanding of the problems.
Process:
Reviewed previous cases and interviewed support staff
Sketched multiple flow proposals
Built clickable prototypes in Figma
Ran user tests (recorded and analysed)
Iterated on language, logic, placements and microcopy
Tested internally, presented to the whole company and adjusted based on feedback
04. The Solution
What does the new flow look like?
The buyer selects case type, accepts the terms, and uploads photos and a description.
The information can only be submitted once – no follow-up questions or additions via chat.
Immediately after submitting, the buyer can propose a price reduction (e.g. 25%, 50% or 75%).
The seller gets an overview of the buyer’s input and can either accept or provide more information.
If the seller accepts the price reduction, payouts are automatically adjusted for both parties.
If they can’t agree, support reviews the case and decides whether buyer protection applies or not.
If buyer protection applies, a return is booked, but there is still an option to resolve the case via price reduction until the item is actually shipped back.
The new flow is built directly into the receipt view in the app. Instead of opening a chat with support, we guide the user through a clear step-by-step form. The flow requires less manual handling, feels clearer for users and increases the chances that buyer and seller can resolve the issue themselves – without involving support.
03. Impact & Reflection
We will follow up with data after launch, but our hypotheses are that the new flow will reduce handling time per case, increase the share of cases resolved directly between buyer and seller, lower return costs, and create a clearer and more trustworthy experience for users. Already in user tests and from the support team we’ve seen that the flow is perceived as more structured and less stressful.
For me, this project was a chance to combine business goals with user value, removing friction without compromising on safety, and working closely with users and several different teams, testing, listening and iterating, was both challenging and very rewarding.