# Community Reviews System — Design & Strategy

**Status:** Design proposal (no backend yet)
**Author:** drafted for Ajay & Tessa
**Companion mockup:** `/supplements/community-reviews-preview/` (visual proof-of-concept)

---

## 1. Why reviews at all

Right now the site reads as a curated opinion column from two people. That is a strength — it is the reason the picks feel vetted. But it caps the conversation at "what Ajay and Tessa think." The stated goal is to let products have bigger conversations around them: a reader who took magnesium glycinate for three months has information that the founders don't have, and other readers want it.

The risk is that open reviews erode the editorial voice. A 2.3-star pile-on from people who took a product wrong, didn't like the packaging, or are review-bombing a competitor would undo the trust the category pages have worked to build.

The design below tries to get the first thing without the second. It leans on *structured, moderated, first-person experience reports* rather than anonymous star-ratings.

## 2. Design principles

**Editorial first, community second.** Community content appears *below* the existing pick-card and the founders' description — never replacing it. Body By A's take is always the loudest voice on the page.

**Structured over free-form.** Free-text reviews are the lowest-signal, highest-drama format. Each review is a short structured form: "How long have you used it?", "What changed?", "Anything you'd warn a friend about?". This turns reviews into mini case studies instead of star drama.

**Stars are muted, outcomes are loud.** A single "would recommend to a friend" percentage (derived from a yes/no field) replaces the 1–5 star average. Individual reviews don't display stars — they display the reviewer's goal, how long they took it, and what they noticed.

**Identity over anonymity.** Reviewers create a short profile (first name, age range, primary goal). Anonymous reviews are not supported. This alone filters out 80% of bad-faith content and makes the remaining content more useful: "Jen, 34, perimenopause" is more informative than "Anonymous — 1 star."

**Moderated, not open.** Reviews sit in a review queue for up to 72 hours before publishing. Reviewers are told this up front ("Reviews are read by Ajay or Tessa before they go live"). This is the single biggest trust lever and is non-negotiable.

## 3. Review structure (the form)

Six fields. No more.

1. **How long have you been using this?** (single select: < 2 weeks, 2–4 weeks, 1–3 months, 3–6 months, 6+ months)
2. **What were you hoping it would help with?** (multi select from a fixed list per category — e.g. for sleep: falling asleep, staying asleep, morning grogginess, stress, restless legs, other)
3. **Did it help?** (single select: Yes, Somewhat, No, Too early to tell)
4. **What changed?** (free text, 300 char limit — the only free-text field)
5. **Anything a friend should know before buying?** (free text optional, 200 char limit — for "it comes in a tiny jar" / "the lemon flavor is strong" / "requires taking with fat")
6. **Would you recommend this to a friend?** (Yes / No — this is what powers the headline percentage)

The character limits are deliberate. The goal is focused experience reports, not blog posts. Longer-form experience writing belongs in `/blog/`.

## 4. Display logic (what a reader sees)

On each product card, below the existing card-footer and above the fold of any community section, one small block:

```
  ★ 47 reviewers   ·   89% would recommend   ·   Median use: 3 months
```

That line is the entire summary. No star average. No percentages per field.

Below the card, a section titled **"From people who've taken this"** shows up to 6 reviews by default, with "Read all 47" expand. Each review is a card with:

- First name, age range, primary goal chip
- "3 months" use-duration badge
- The "What changed?" text
- The "Anything a friend should know?" text if present
- A tiny metadata strip: "Posted April 2026 · Verified purchase? No / Yes (see §7)"

Reviewers are NOT shown individual star ratings. The recommend Yes/No becomes a quiet chip on each review card, not the headline of the card.

### Sort & filter

Two dropdowns above the reviews: **Sort by** (Most recent / Most helpful / Longest use) and **Filter by goal** (the multi-select list from field 2). These should be the only two controls. Do not add filters for age range or gender — it encourages demographic sorting in a way that the site should not endorse.

## 5. Moderation & trust

**Queue.** All submissions go to a queue. No auto-publish. Ajay and Tessa (or a designated moderator) approve or reject within 72 hours. Tell submitters this on the form: *"One of us reads every review before it goes live. Usually within 2 days."* This sentence is load-bearing.

**Rejection rules.** A short public page (`/community-guidelines/`) states what gets rejected: content attacking individuals, unverifiable medical claims ("cured my cancer"), marketing copy (likely a brand employee), reviews of the wrong product, abusive language. The list should be short and the tone neutral — not defensive.

**Edit rights.** Reviewers can edit or delete their own reviews through a tokenized link emailed at submission time (no account required for v1). Ajay/Tessa can edit a review to correct formatting but cannot change the substance; edits are timestamped.

**Verified purchase badge.** At launch, there is no way to verify purchase because BBA is an affiliate site, not a merchant. Do NOT fake this. Instead, use a "Verified by photo" badge for reviewers who upload a photo of the product (optional, surfaced as a trust signal). That's honest; "Verified purchase" is not.

**Brand response.** Brands can respond to reviews via a separate form. Responses are clearly labeled ("Response from [Brand]") in a different visual treatment. A brand CANNOT gate, edit, or reply inline with a reviewer's text.

## 6. What community reviews are NOT

Enumerating this is important, because every review system has scope creep.

- **Not a Q&A forum.** Questions live in comments on blog posts or a future `/ask/` feature, not in reviews. A review is a post-hoc experience report.
- **Not a discussion thread.** Reviewers cannot reply to each other. This prevents flame wars and keeps the page readable. If someone disagrees with a review, they can write their own.
- **Not a 5-star rating system.** The absence of stars is deliberate. Repeat: no stars.
- **Not a medical claim board.** "Did it help with X?" is a structured yes/somewhat/no, not a free-form claim.

## 7. Trust signals the reader sees

Arranged by strength (strongest first):

1. **Ajay/Tessa's own note.** On products one of them has personally used, a pinned-style callout at the top of the reviews section: *"Tessa has been taking this for 6 months. Read her take →"* — links to the existing description or a blog post.
2. **Moderation disclosure.** A one-liner near the reviews: *"Every review is read by a human before going live."*
3. **Verified-by-photo badge** (when available).
4. **First name + profile chip.** Anonymous-free.
5. **Use-duration badge.** "2 weeks" carries less weight than "6 months" and the UI should make that legible at a glance.

## 8. Launch phasing

**Phase 0 — this mockup (current state).** Static design shown on `/supplements/community-reviews-preview/`. No form submissions. Used to get alignment on look/feel and test the editorial promise.

**Phase 1 — one category, seeded.** Add real review functionality on ONE category (recommend: Magnesium, because Tessa has the strongest opinion there and there's latent curiosity in the comments on that category's blog post). Seed with 8–12 reviews from known readers who've emailed in. Form submissions go to Netlify Forms / Formspree → email queue → manually published as static HTML updates, not a DB. This keeps the editorial-first loop tight.

**Phase 2 — expand + semi-automate.** If Phase 1 works for 2–3 months (signal: >10 quality submissions / month per category that Ajay & Tessa are happy to publish), expand to all categories and move review storage to a simple CMS (Sanity, Airtable, or a lightweight SQLite endpoint on Netlify). Keep the moderation queue.

**Phase 3 — brand responses + verified-photo.** Only after Phase 2 is stable. These are trust-multiplier features but add moderation complexity; they should wait until the review volume justifies them.

## 9. What this document doesn't answer

- **Account system.** v1 uses email + magic-link edit tokens. A full account system is a Phase 2+ question.
- **Spam handling.** Hashcaptcha / honeypot fields + the moderation queue are enough for Phase 1. Review volume is the constraint, not abuse volume.
- **Legal.** Terms need a section on user-submitted content licensing. Defer to existing `/terms/` update before Phase 1 launches.
- **FTC disclosure inside reviews.** If a reviewer received the product free, the review should state that prominently. Form should ask "Was this product sent to you by the brand or by Body By A?" and display "Sent free by [Body By A / Brand]" on the review card if yes.

## 10. Open questions for Ajay & Tessa

- How do you want to handle a negative review of a product where you have an affiliate link? (Recommendation: publish it, and if the pattern repeats across reviewers, remove the pick. Don't delete the reviews.)
- Do you want to allow reviews from people who bought elsewhere (e.g. Costco, not via the affiliate link)? (Recommendation: yes — the review is about the product, not the purchase path.)
- What happens if a brand emails asking to remove a critical review? (Recommendation: publish a standing policy: no removals outside of community-guidelines violations, including at brand request.)