Making Feedback Feel Safe Enough to Give
Customers weren’t skipping worker reviews out of indifference. They were skipping them because it took too long, because they could be identified, and because of what a bad review might cost the person it was about.
Customers weren’t rating workers, which starved worker reputation, matching quality and the marketplace’s own signals.
Not that they didn’t know how — 13 of the 16 surveyed disagreed with that. It was effort, anonymity, and what a bad review might cost the person it was about.
Held the rest of the experience intact and put everything into the rating modal, then decoupled rating from timesheet approval so it could be skipped.
62% more reviews in month one, against a 30% target.
Customers weren’t rating workers,and three sides of the marketplace felt it.
Many customers simply weren’t rating their workers. That hurt three sides at once: worker quality depended on it, other customers needed real signal to hire from, and workers had nothing concrete to improve against.
The goal: more use of, and more confidence in, the rating system, with data the business could use to keep worker quality up.
Hypotheses first,so the survey had something to disprove.
I ran the research two ways at once, and wrote the hypotheses down before the survey went out — so it had something to disprove rather than something to confirm.
A survey, built with the customer-side PM and shaped by CommOps, account managers and support, let customers answer in their own time. Alongside it ran interviews with account managers, who knew these pain points best, and a product workshop so the worker side had a voice too.
Set before any design work, so there was something to be wrong about.
Checked how comparable systems had already solved it
I also looked at competitor and adjacent rating systems, not to lift a pattern but to see which parts worked and which caused problems of their own.
Pattern analysis
Adjacent marketplaces break ratings into categories, with something concrete to act on.
Not indifference.Effort, exposure, and what a bad review might cost.
The easy read was that customers didn’t care. Rather than assume, I wrote four hypotheses and built the survey to test each one.
Privacy — they’re concerned about being identified. Worker impact — a negative review might have real consequences for the person it’s about. High effort — leaving a review is too much work to be worth it. Learning curve — they simply don’t know how.
Sixteen clients completed it, and three hypotheses held. Effort led by a distance: 69%, 11 of 16, found reviewing too time-consuming. 44% didn’t want to be identified, and 38% worried about the effect on the worker.
The fourth was wrong, and it was the useful one: 81%, 13 of 16, knew how to leave a review. The thing that looks most like a design problem wasn’t a factor at all.
Sixteen is small, so I’d treat any single figure as directional. It was usable because the hypotheses came first, and because three details in the old interface matched the three barriers it ranked.
Had we skipped it, an onboarding tooltip would have been a very reasonable thing to ship — and it would have solved nothing.
Survey evidence
Effort led at 69%. And 81% knew how to review, which ruled out the fourth hypothesis.
That’s what fear of retaliation meant in practice: not a vague discomfort, but a specific, remembered consequence.
We didn’t need to teach customers how to review. We needed to make reviewing feel safe enough, and quick enough, to bother with. Every design choice after this point is built against those two things rather than against comprehension.
Change one modal,and build it around the actual fears.
Deliberately minimal, deliberately focused
My strongest scoping call was what not to change. With the PM, engineering and the Head of Product, I argued for keeping most of the experience and putting the effort into the Rating Modal, so customers who already reviewed had nothing to relearn.
Exploration
Six variants explored within the existing design language.
An adaptive modal built around the actual fears
The modal responds to the star rating in three places, not one. The heading turns from “That’s great! What went well?” to “We’re sorry to hear that. What went wrong?”. The answer set switches from qualities to shortcomings. And the free-text label changes from “Share your feedback with other hirers” to “Share details about your experience”.
The label is the piece I’d defend hardest. On a good review, naming the audience is reassuring. On a bad one, the same words put the reader in mind of exactly what stopped them: a critical judgement, attached to them, circulating. So the negative state asks about their experience instead.
Free text stayed, but pre-canned options meant a time-poor customer could be specific in a couple of taps, which is what the 69% had asked for.
Rating experience
Safe enough to give.
At five and two stars, the heading, suggested answers and free-text prompt change together.
Alongside the hypotheses, the survey asked what makes clients review someone well or badly, from a candidate list they could add to. Cross-checked with account managers and industry research, those answers became the final sets. Pre-canned answers only save time if they’re close to the words people would have chosen.
Answer sets
What clients said drives a good or bad review. The shipped answer sets came from these.
What the old flow was actually asking for
Three details in the existing interface map almost exactly onto the three barriers the survey found, which is the clearest evidence they weren’t hypothetical.
Rating lived inside timesheet approval: one modal, one Approve button, so a review came attached to the task people came to do. The free-text field said “Write Fernanda a public review”: public, and addressed to the worker by name. And stars came pre-filled at five, so approving a timesheet silently issued a rating nobody chose.
Effort: the rating became its own skippable step, with pre-canned answers. Exposure: “write a public review” became “share your feedback with other hirers”, with a line stating exactly what the worker will and won’t see. Worker impact: the star rating reaches the worker so they get something actionable, while the written detail stays anonymous and hirer-only.
Review flow
Before: hours and rating behind one Approve. After: the rating is its own, skippable step.
Making a system default look like a system default
An unrated worker genuinely defaults to five, so hiding that would have been dishonest, but solid stars implied a customer had chosen them.
Stars now show on the worker row whatever the timesheet status, and render faded. Outlined reads as “nothing yet”, solid as “someone rated this”, and neither was true. Faded says the system has a value nobody has confirmed.
The card header changed for the same reason: it said “review and complete” while timesheets hadn’t arrived, so it now names the stage it’s actually at.
Shift list
Stars sit on the row, faded until someone confirms them. The header names the real stage.
Lower ratings
The logic mapped end-to-end before anything got built
Before engineering, I mapped every branch: whether a timesheet was in, whether the worker was already rated, the fork into positive or improvement-focused answers, and how an existing rating is returned rather than overwritten.
The worker’s list changed as little as possible, for the same reason as the modal.
Worker list
Perception, not usage,from the same customers, with a working test.
The timeline didn’t allow broad testing, so I went back to the survey respondents with a second survey and a working test version. It was positive, and surfaced a few logic gaps, unsurprising for a feature woven this deeply through the platform.
But it was perception, not usage. Customers found it more logical, and liked that rating no longer stood between them and their timesheets.
62% more reviews in month one,against a 30% target.
In the first month after release, worker reviews left by customers rose roughly 62%. First-time reviewers increased by roughly 21%. Both numbers landed well past the original 30% and 10% targets.
Two caveats. Stars used to come pre-filled at five, so the numbers only compare if both count deliberately submitted ratings, and that’s the definition I’d hold myself to. And month one is when novelty is largest. A month-three read would be the honest test, and I left before there was one.
That came from the worker side of the business, about a feature built for customers, which was the point: more reviews meant better matching, and eventually something a worker could act on.
The same empty fieldcan have several causes.
- The same empty field can have several unrelated causes. Treating low engagement as one problem would have produced one answer — and it would have solved at most a third of it.
- Removing the obligation increased the participation. Decoupling ratings from timesheet approval meant customers could skip it entirely — and fewer of them did.
- Testing breadth was the thing I’d buy back with more time. The logic gaps the second survey caught were a symptom of how much surface area this feature touched, and a broader test would have found them earlier.
Next was worker-behaviour signals: attendance, lateness and no-shows adjusting a rating without a customer weighing in every time, closer to how DoorDash handles drivers, and giving workers a criteria-by-criteria view to act on.