UX research — the editor flow

Scope. Design & UX best practices for the Redpoint editor journey: recruitment (/editors) → application → vetting → first assigned job → productive edit loop (/workspace). Research is mapped to our screens, not offered in the abstract. Every recommendation is tagged:

• [adopt now] — a copy/layout change within the current design briefs; no new capability, safe to fold into the /editors + /workspace specs.
• [design change] — needs a spec update to MARKETING-PAGES-BRIEF.md or PAGE-SPECS.md before build.
• [Phase 10] — belongs to full self-serve onboarding (out of scope now); may shape Phase 10 but must not pull it forward silently.
• [reject — reason] — considered and declined, with the reason.

Hard constraints respected throughout (from CLAUDE.md, ARCHITECTURE §2/§7/§8, MARKETING-PAGES-BRIEF §2):

• Pseudonymity is non-negotiable. No recommendation may surface an editor's real identity to clients, or a client's identity to editors beyond brief-level info.
• Payout split is an operator placeholder ([EDITOR PAYOUT SPLIT]). Every earnings recommendation shows a slot ("you keep {X}%"), never an invented number, rate, or turnaround.
• Full self-serve onboarding is Phase 10. Today the /editors form is interest capture; vetting and tenant eligibility are operator-driven.
• Supply is platform-scoped, engine-neutral. /editors and /workspace carry no tenant branding.

Our current editor journey (from docs/FLOWS.md): /editors (recruitment, design-stage) → apply & vetting (applied → test_assigned → approved) → tenant eligibility (ops approves per vertical) → /login → /workspace (assigned jobs only) → /workspace/jobs/[id] (brief · originals · ship draft). /workspace is built (matches PAGE-SPECS C1); /editors is not built (spec in MARKETING-PAGES-BRIEF §2).

Theme 1 — Supply-side recruitment (/editors)

Best-practice findings

• A recruitment landing page is one page, one goal, no distractions — the role, the benefits, a short form; long forms and menu chrome drive bounce. Numbered signup/process steps reduce uncertainty and lift completion (Instapage).
• Lead with schedule control and earning potential; don't bury pay below the fold. Early pricing/earnings transparency increases conversion by qualifying in-budget visitors and reducing bounce (Instapage).
• Peer-level social proof converts — a testimonial from someone the visitor recognises as like them out-performs logos (a customer quote showed ~35% lift over logos); video testimonials out-perform text (SaaS Hero, UserEvidence).
• What repels professionals is the freelance-marketplace status quo: bidding wars ("30–50 bids in hours… $10/video from overseas vs $200 from a portfolio"), underbidding, copy-paste churn, and going "weeks or months without any work." What they actively want is regularity and reliability — jobs that show up, no negotiation, no flaky counterparties (DDIY, Vidpros).

Our current / planned state

/editors §2 already sells the right things: assigned work (no discovery calls / chasing files), pseudonymity, a workload cap the editor controls, per-job Stripe payout, bounded revisions. Message architecture is: hero → "how it works for editors, honestly" → "what we look for" → 5-field form. This maps almost 1:1 onto the research — Redpoint's pitch is the antidote to the bidding-war world editors resent.

Recommendations

1. Keep the "we handle everything else" spine and make anti-bidding-war contrast explicit. The pitch already lists the loop; add one honest framing line — assigned work, no bidding, no client-acquisition — because "steady, no-negotiation work" is the single strongest documented pull for this audience. [adopt now] — copy within /editors §2.2, engine voice.
2. Earnings visible above the fold as a config slot. Render the payout share ("you keep {X}% of every package") in the hero/how-it-works region, not buried — transparency lifts conversion. The number stays a placeholder slot. [adopt now] — already the spec's intent (§2.2); elevate its placement.
3. Reserve a peer social-proof slot — one editor testimonial (pseudonymous or consented first-name) or a factual figure ("N editors in the pool"). Design the slot now; leave it empty until real content exists. Do not fabricate testimonials. [design change] — add an optional proof section to §2; render nothing when unpopulated (graceful empty state, per house rule).
4. The workspace-preview motif is a conversion asset, not decoration. §2's "framed workspace screenshot / stylized job-card in engine-dark" doubles as product honesty — showing the actual tool answers "what will my day look like?" Prioritise it. [adopt now] — already in §2 branding notes.
5. Reject: real-time "recently signed up" activity widgets. Documented as a gig-economy conversion tactic, but it manufactures urgency, clashes with the calm/premium DESIGN-BRIEF §6 voice, and would be dishonest at low volume. [reject — voice + honesty]

Theme 2 — Vetting & test-work UX (application → test_assigned → approved)

Best-practice findings

• The "application black hole" is the #1 dropout cause. Ghosting peaks right after submission ("after submitting my application," 28% of ghosting reports); silence makes candidates assume rejection and disengage. The fix is explicit SLAs on every touchpoint — e.g. acknowledge in 24h, confirm next steps in 72h, decide in 48h (Candidate Experience Institute, Tenzo).
• A visible, staged funnel makes good candidates persist and unfit ones self-select out. Toptal publishes its funnel and pass rates (≈26% past screen; ~3% past the test project) and states a timeline (test project completed in 1–3 weeks; overall 2–5+ weeks) — the stated difficulty is part of the filter (Delesign, Tecla).
• Pay for test work. Paying for the trial "signals you value their time," sets a partnership tone, and improves the signal you get back; work trials are a mutual-fit exercise, not a weed-out (FreeUp, Linear).

Our current / planned state

Schema already models the funnel: editor_profiles.vetting_status: applied → test_assigned → approved (ARCHITECTURE §7). /editors §2.3 states the process plainly — "apply → short paid test edit → approved into the pool" — which is already best-practice on both the staged-visibility and paid-test axes. The form success state is currently a single calm message: "We review every application and reply within a few days." There is no logged-in status view between apply and approval (Phase 10 owns self-serve onboarding).

Recommendations

6. State the funnel and a timeline on /editors, not just the three step names. Add expectation-setting microcopy: what each stage is, that the test edit is paid, and a rough time-to-hear-back. This is the cheapest, highest-leverage anti-black-hole move available pre-Phase-10. [adopt now] — copy within §2.3.
7. Make the success state a concrete promise, not a vague one. "…reply within a few days" is good; bind it to an explicit acknowledgement commitment ("You'll get an email either way") so silence is never the outcome. The operator must be able to honour it. [adopt now] — §2.4 success-state copy.
8. Design a lightweight applicant status surface for Phase 10. A logged-in "your application: received → test edit → in review → decision" tracker is the structural cure for the black hole, but it needs the self-serve backend Phase 10 owns. Spec it now so Phase 10 inherits it; do not build ahead of the backend. [Phase 10]
9. Keep the paid test edit prominent and honest about the bar. The pitch should say the test is real short-form work, reviewed like a real job — this is what makes it a fair filter and lets unfit applicants self-select out. [adopt now] — §2.3.

Theme 3 — First-assignment activation (first job in /workspace)

Best-practice findings

• A guided first-run removes first-task anxiety. DoorDash gives new Dashers a demo order walking the full accept→complete loop "to remove any guesswork or anxiety." Uber gates activation behind a short course familiarising drivers with the app before their first real trip (Dasher Central, Uber Help).
• Reassurance lowers the stakes. "The first day of any new gig can cause anxiety… messing up isn't the end of the world" — explicit, calm framing that a mistake is recoverable (Dasher Central).
• A visible person/channel for questions and a clear "what happens next" reduce first-task drop-off (candidate-drop-off research, Theme 2 sources).

Our current / planned state

/workspace is built and clean: assigned jobs soonest-first, deadline framed as focus not alarm ("due in 6h" / "overdue by Nh", not the ops breach-red), a prominent brief render, originals download, a single "Ship it" action column, and QC/revision notes surfaced as calm labelled blocks ("QC returned this to you" / "Client requested changes"). The empty state reassures ("No jobs assigned to you right now."). There is no first-run guidance and no visible question/help channel on the page. Actions gate correctly (Submit-for-QC disabled until a draft exists, per PAGE-SPECS C1).

Recommendations

10. Add a first-job affordance that appears only on the editor's first assignment. A dismissible strip on /workspace/jobs/[id] walking the loop — "Read the brief → download originals → upload your draft + watermarked preview → Submit for QC. QC checks every edit before the client sees it." No new backend: gate on "editor has no prior submitted job." This is our equivalent of the Dasher demo order and directly de-risks the first ship. [design change] — add a first-run state to PAGE-SPECS C1.
11. Name the safety net. One calm line near the ship action — "A human QC reviews every edit before it reaches the client; QC notes come back here" — turns the QC step from a judgment into a support. Mirrors the "recoverable mistake" framing that lowers gig anxiety. [adopt now] — helper copy in C1's "Ship it" column.
12. Give the editor a visible channel for questions. Even a static "Questions on this brief? Contact ops" affordance (email/route TBD by operator) answers "who do I ask?" without breaching pseudonymity — it routes to the platform, never the client. [design change] — add a help slot to C1; operator wires the destination.
13. Reject: a mandatory gated tutorial before the first real job. Uber-style forced courses fit high-liability physical work; our editors are vetted professionals who resent ceremony (DESIGN-BRIEF §2: "zero ceremony"). A dismissible first-run strip (rec 10) captures the benefit without the friction. [reject — persona/ceremony]

Theme 4 — Professional work-queue UX (the productive edit loop)

Best-practice findings

• Anchor feedback to the exact moment. Frame.io's frame-specific, time-coded comments removed "long explanation threads… no ambiguity about which scene needs attention" — precise, located feedback is faster and less demoralising than vague notes (Maniwebify).
• Categorise feedback (technical fix / creative adjustment / strategic change) so reviewers are directed to their lane and the recipient can triage (Maniwebify).
• The process should make the work feel lighter. Revision-heavy tooling (.draftroom) is built on "creativity is already demanding; the process around it should make the work feel lighter, not heavier," with clear pending / approved / next states (draftroom).
• "Everything you need is here" completeness signals reduce back-and-forth — the recurring freelance-editor complaint is chasing files and unclear scope (Theme 1 sources).

Our current / planned state

Strong foundation. The brief render is the page's most legible element (PAGE-SPECS A6); originals are a clean download list; scope is bounded by the package revision cap (can't creep). QC and revision notes arrive as distinct, labelled, calm blocks — QC (internal) visually separated from revision (client-driven), which is exactly the categorisation Frame.io advocates. Gaps vs. best practice: (a) notes are plain text with no structure or location anchoring; (b) no explicit "footage complete / everything's here" signal on the editor side — getFootageReadiness() exists but is surfaced on client /jobs/[id], not /workspace; (c) no per-job progress sense beyond status chip.

Recommendations

14. Surface a footage-completeness signal in /workspace. Reuse getFootageReadiness() to show "All originals in — N file(s)" vs "Footage still arriving" on the job detail, so the editor knows the assets are complete before starting. This is the "everything you need is here" signal, and the data already exists. [design change] — add to PAGE-SPECS C1 (today C1 only guards the empty "Footage isn't here yet" case).
15. Keep QC vs. revision notes visually distinct — and consider light structure. The built split (internal QC / client revision) already matches the categorise-feedback finding; hold it. Optionally let ops mark a note's intent (fix / creative / must-change) so editors triage — but only if the ops action panel gains the field. [design change] — note-taxonomy is a coordinated /ops + /workspace spec change; the base split is [adopt now].
16. Frame notes as instructions, never verdicts. Keep the professional, specific voice already in the labels ("QC returned this to you"); the demoralising-feedback research says located, actionable, non-judgmental framing is what protects morale. [adopt now] — voice already compliant; lock it in the spec.
17. Reject (now) / Phase 6+: in-player time-coded review inside our own UI. Frame.io-grade timeline commenting is the gold standard, but ARCHITECTURE §9 is explicit — no custom timestamped review player; Frame.io fills that gap early. Client review (Phase 6) shows a watermarked preview in a designed frame, not a commenting surface. Don't rebuild Frame.io. [reject — explicit non-goal, ARCHITECTURE §9]

Theme 5 — Payout trust (per-job earnings + Stripe Connect)

Best-practice findings

• Show predictable, per-job earnings up front. "Seeing a clear and predictable payout schedule builds trust"; Stripe's Express Dashboard exists to give connected accounts real-time balance, upcoming payouts, and an earnings chart (Stripe docs, greenmoov).
• Minimise onboarding friction. KYC onboarding is ~10–15 min of compliance forms; Stripe reduces it via API-driven flows and networked onboarding (reuse verified info across accounts, skip redundant KYC) (Stripe docs, greenmoov).
• Connect nets out refunds/chargebacks and handles per-job calculation, which is the trust substrate — the editor doesn't chase or reconcile (greenmoov).

Our current / planned state

Our mechanism is right by design: payout share is shown on the job before work starts (packages.editor_payout_*, ARCHITECTURE §5/§7), paid per job via Stripe Connect transfer on client approval (§5.3), no invoicing. /editors §2.2 promises "payout share shown on every job before you start." But the built /workspace/jobs/[id] does not yet display a per-job earnings figure — PAGE- SPECS C1 shows brief/originals/ship, with no payout line. Connect onboarding is a Phase-6/payout concern, not yet specced in the editor surfaces.

Recommendations

18. Show the per-job payout on the job detail before the editor starts. Add a quiet earnings line to /workspace/jobs/[id] ("Your payout: {share} of this package" or the computed per-job figure) sourced from packages.editor_payout_*. This is the promise /editors §2.2 makes; the workspace must honour it. The split stays a placeholder — render whatever the operator configures, never a hardcoded %. [design change] — add a payout element to PAGE-SPECS C1.
19. Set payout timing expectations honestly. State the trust-critical fact that payout lands on client approval, not on submission (ARCHITECTURE §5.3) — both on /editors and on the job. Surprise-free timing is the payout-trust finding. [adopt now] — copy on /editors §2.2 and C1.
20. Design Connect onboarding as low-friction and deferred. When per-job payout wiring lands (Phase 6+), use Stripe Express + networked onboarding to keep KYC minimal, and trigger it at the right moment (approval into the pool / first payout), not as a wall before the first edit. Spec the entry point; don't build ahead of payout wiring. [Phase 10] (onboarding UX) / [design change] (where the entry point lives).
21. Reject: embedding a full earnings dashboard in /workspace. Stripe's Express Dashboard already provides balance/payout history; rebuilding it violates "boring, well-documented choices" (CLAUDE.md §4) and the dense-but-minimal DESIGN-BRIEF §6. Link out to the Express Dashboard for history; keep /workspace about the work. [reject — reuse Stripe]

Prioritised top-10

Ranked by leverage (impact on editor conversion, activation, retention) against cost, honouring the constraints. Tag in brackets.

1. State the vetting funnel + timeline + "you'll hear either way" on /editors — the single biggest anti-"black-hole" move, pure copy. (rec 6, 7) [adopt now]
2. Show per-job payout on /workspace/jobs/[id] before work starts — closes the gap between the /editors promise and the built workspace; split stays a placeholder. (rec 18) [design change]
3. Earnings + payout-timing ("paid on client approval") transparency on /editors, above the fold — documented conversion lift; honest framing. (rec 2, 19) [adopt now]
4. First-job dismissible walkthrough on the first assignment — our Dasher demo-order; de-risks the first ship without ceremony. (rec 10) [design change]
5. Surface footage-completeness ("everything's here") in /workspace — reuses existing getFootageReadiness(); kills the "chasing files" anxiety. (rec 14) [design change]
6. Name the QC safety net + a visible "questions → ops" channel on the job — lowers first-task anxiety, preserves pseudonymity. (rec 11, 12) [adopt now] / [design change]
7. Make the anti-bidding-war contrast explicit in the /editors pitch — speaks directly to what repels professionals. (rec 1) [adopt now]
8. Reserve a peer social-proof slot (render-nothing-when-empty) — highest- converting proof type; no fabrication. (rec 3) [design change]
9. Lock feedback voice as located, categorised, non-judgmental instructions — protects morale in the revision loop; mostly already true. (rec 15, 16) [adopt now]
10. Spec (don't build) the Phase-10 applicant status tracker + low-friction Connect onboarding entry point — structural black-hole cure and payout trust, deferred to their backends. (rec 8, 20) [Phase 10]

Explicitly rejected (kept out on purpose): fake real-time signup widgets (rec 5), forced pre-job tutorial (rec 13), rebuilding Frame.io-style in-player review (rec 17, per ARCHITECTURE §9), embedding a full earnings dashboard (rec 21, reuse Stripe Express).