Day 6 — designing the "no surveys match you yet" state (and why it might matter more than the happy path)
A comment on my Day 4 post pushed me on something: a "verifying"
state only builds trust if it can actually fail and show why —
otherwise it's decoration, not proof of fairness.
Today I designed the activity history with that in mind. Instead of
generic pass/fail, it shows specifics: "Didn't qualify — age range
mismatch," "Spot filled," "Still verifying." Real reasons, not a
shrug.
I also had to face the cold-start problem head-on: what does a new
user see if there simply aren't enough surveys yet? Rather than fake
it, the empty state just says: "We're a new platform and add survey
supply daily. Completing your profile fully is the best way to
increase your matches."
This ties into something aryan_sinh asked me a few days ago about
which side of the marketplace to optimize for first. I still don't
have that fully solved, but I'd rather the product be honest about
where it's at than hide the gap.
Still zero app code — but the trust-critical moments are getting
designed deliberately instead of as an afterthought.
The specific rejection reasons build trust, but the empty state should separate “no supply exists” from “your profile is incomplete.” Telling users to add more profile data when the real constraint is marketplace supply makes the gap feel like their fault. Show which condition applies, the last supply refresh, and an opt-in alert; only recommend another profile field when it can actually unlock a known match.
This is a really good catch, and you're right — my current copy
blends "there's no supply yet" with "complete your profile" into one
message, which quietly puts the burden on the user for something
that isn't their fault at all.
Going to split this into two distinct states: one for "no matching
supply right now" (with a timestamp on last supply refresh + an
opt-in alert for when it lands), and a separate one for "your profile
is missing something that would unlock a known match" — only shown
when that's actually true, not as a default suggestion.
Appreciate you naming this specifically — it's the kind of thing that
looks fine until you think about who it actually applies to.
That split fixes the blame problem. I'd test it with one tiny instrumentation rule: if users in "no supply" repeatedly edit their profiles anyway, the state still implies personal fault even when the copy says otherwise. A clean state should drive alert opt-ins, not profile churn.
That's a great instrumentation instinct — the copy can say "not your
fault" while the UI still only gives someone a profile-edit button to
press, which quietly steers them back to blaming themselves anyway.
Going to make sure the "no supply" state's primary action is clearly
the alert opt-in, not a profile edit shortcut, and I'll keep your
test in mind once there's real usage data — re-edit rate in that
state is a good signal to watch for whether the fix actually worked,
not just whether the copy changed.
Also checked out Agent Island — starred the repo. Clean concept, and
appreciate that it's fully local/no telemetry, that's a good trust
signal in itself for a menu-bar tool that reads your disk.
That action hierarchy is the important part: 'alert me when supply appears' matches the system state, while 'edit your profile' quietly tells the user they caused it. Watching re-edit rate alongside alert opt-ins should expose whether the interface still creates self-blame. And thank you for checking Agent Island and for the thoughtful trust note.