Leticia Sant'Ana
HomeAboutLinkedInSay hi
© 2026 Leticia Sant'Ana · designed and built by meFlorianópolis, Brazil© 2026 Leticia Sant'Ana · Designed and built by me · Floripa 🇧🇷
← Back to home

Product Design · Varsity Tutors tutor experienceLive product

Turning tutor feedback intoproduct signal

I led the design and implementation of an in-product feedback system for tutors, replacing an outdated Google Form with a structured experience that helped internal teams understand and investigate what tutors were experiencing.

3,229Feedback submissions capturedSupabase, since launch
1,340Tutors shared feedbackDistinct tutors, since launch
910Tutors consented to follow-up68% of all submitting tutors
GLOBAL-SHARE-FEEDBACK.MP4
A global feedback experience tutors could open from anywhere in the product.
RoleProduct Designer
ContributionProduct framing, UX/UI, Supabase data design, frontend implementation, internal dashboard, QA, and launch
PartnersProduct, UX Research, Tutor Support
TimelineFeb to Mar 2026

01 · The problem

Feedback existed,
but context did not

The global Share Feedback link opened an external Google Form whose responses landed in a spreadsheet. A separate post-session experience collected session-specific feedback in Supabase.

Both channels were useful, but they served different moments and their signals could become mixed in reporting. Global feedback also arrived with little context about what the tutor had been doing before submitting it.

I worked with Product, UX Research, Tutor Support, and Engineering to understand what needed to remain intact before changing the experience.

Before
Global feedbackGoogle Form
↓
Google SheetLimited context
Session feedbackIn-product flow
↓
SupabaseSession-specific context
After
In-product Share FeedbackSidebar · More menu
↓
Structured Supabase recordportal_share_feedback
↓
SlackInternal
dashboard
Session
replay
Existing systemsWhat I designed and builtStructured recordLater capabilities
I modernized global feedback without removing the value of in-the-moment session feedback.

02 · The solution

Preserve what worked,
structure what was missing

I kept the existing session-feedback flow unchanged and added a dedicated portal_share_feedback table inside the same Supabase project.

The new flow:

  • Replaced the external form
  • Captured structured product areas
  • Stored behavioral and technical context
  • Preserved the Slack feedback stream
  • Created a reliable source for internal analysis

The new table used row-level security so tutors could submit feedback associated with their own account without gaining access to anyone else's submissions. The existing session tables and client integration remained untouched.

CollectTutor-facing feedback flow
StructureProtected Supabase record
InvestigateSlack, dashboard, and replay

03 · The experience

Two steps, designed for a frustrated moment

The first step asked tutors what their feedback concerned. No product area was preselected, tutors had to choose at least one area, and they could choose several when an issue crossed different parts of the experience.

The second step prioritized the tutor's own words. Tutors could describe what happened, mark it as a product bug, and consent to being contacted.

The product automatically attached information such as the route, device, build version, tutor details, and later a PostHog session ID. It also protected unfinished feedback with a discard confirmation and guarded against duplicate submissions.

01 · Select one or more product areas
01 · Select one or more product areas
02 · Explain what happened
02 · Explain what happened
03 · Protect unfinished work before leaving
03 · Protect unfinished work before leaving
No default selectionMultiple areas supportedImmediate support pathContext captured automatically
The flow asked tutors only for information the product could not already capture.

04 · From feedback to investigation

The result was a feedback loop, not just a modal

Every submission became a structured record containing:

01

What the tutor said

Message, product areas, product bug indicator, and follow-up consent

02

Where it happened

Route, device, build, and tutor context

03

What happened beforehand

A Session Replay link to the minutes leading up to the submission

I also created the internal dashboard used to review this signal. Teams could filter submissions, identify patterns, inspect the original message, and open the relevant session recording.

INTERNAL-DASHBOARD.MP4
A tutor comment could be traced from the original message to the product behavior that came before it.Tutor names and emails were blurred to protect confidentiality.

05 · Outcomes

A feedback channel tutors continued to use

Since launch, tutors submitted 3,229 pieces of feedback through the new experience.

Those submissions came from 1,340 distinct tutors, with an average of approximately 2.4 submissions per tutor. This shows that the channel reached a broad group of tutors and was also used repeatedly over time.

Completed feedback submissions by month

516
618
581
468
355
411
280
Mar 2026Apr 2026May 2026Jun 2026Jul 2026Aug 2026Sep 2026 · partial
Strong early adoption was followed by sustained monthly use.

A large pool of tutors was open to follow-up

910 tutors, or 68% of everyone who submitted feedback, consented at least once to being contacted.

That created a substantial pool of tutors who could be contacted for:

  • Clarifying a reported problem
  • Verifying whether an issue had been resolved
  • Participating in usability research
  • Providing context for recurring themes
910tutors were open to follow-up68% of all submitting tutors

What tutors used the channel to report

During the named PostHog measurement period:

Feedback about the broader tutor experience · Named events since May 6

Product bug reports 42%General feedback and ideas 58%

This describes feedback about the broader tutor experience. It is not the defect rate of the Share Feedback feature.

“I do like the change in this feedback form!”
Tutor feedback, March 8, 2026

What I would measure next

Supabase captured every successful submission, and PostHog autocapture recorded entry-point interactions from release. Named submission and error events were added later.

The remaining gap is the middle of the journey. Modal opens, step progression, and abandonment were not explicitly tracked, so the experience did not have a clean open-to-submit funnel.

The next instrumentation layer would add:

  • Modal opened
  • Product area selected
  • Step two reached
  • Submission completed
  • Flow abandoned after progress

The highest-value next metric is open-to-submit conversion, followed by abandonment after a tutor begins writing.

06 · Takeaway

A feedback system should not ask users to perform the team's analysis

It should make it easy to explain what happened, capture context quietly, and give the team a clear path from signal to investigation.

On this page

01The problem02The solution03The experience04Investigation05Outcomes06Takeaway
Next case · EdTech · 2025Substitute tutoring→

Let's talk

Remote-first · Flexible timezone

← Back to homeleticiasantanaux@gmail.com