Authentic Product Representation

---
name: authentic-product-representation
description: Product visuals must show the real product with real data. Use when building landing pages, hero sections, screenshots or demo panels.
metadata:
  priority: 7
  pathPatterns:
    - "app/**"
    - "src/**"
    - "**/*.tsx"
    - "**/*.jsx"
    - "**/*.html"
    - "**/page.tsx"
    - "**/hero*"
    - "marketing/**"
    - "landing/**"
  promptSignals:
    phrases:
      - "hero section"
      - "landing page"
      - "product screenshot"
      - "screenshot in the hero"
      - "product shot"
      - "mockup"
      - "demo panel"
      - "fake data"
      - "placeholder data"
      - "lorem ipsum"
      - "marketing visual"
      - "make it look impressive"
retrieval:
  aliases:
    - authentic product representation
    - honest product visuals
    - design with real data
    - real content not lorem ipsum
    - credible hero
    - product screenshot
    - anti AI-slop
    - show the real thing
  intents:
    - make this hero credible
    - show the real product output
    - replace the fake screenshot with something real
    - use real data in this mockup
    - this looks AI-generated, make it authentic
  examples:
    - this hero looks fake, make it credible
    - replace the lorem ipsum with real content
    - the demo panel should show what the product actually outputs
    - this screenshot is invented, base it on the real thing
    - the landing visual looks AI-generated
---

# Authentic Product Representation

The fastest way to lose a visitor's trust is a product visual that is obviously staged. People have seen thousands of landing pages; they recognise a fabricated dashboard, a screenshot full of lorem ipsum, or a "terminal" that prints things the real tool never would. The visual that converts is the one that looks like it was screenshotted straight out of the working product — because it was, or because it was built to be indistinguishable from it.

The principle is simple: **the visual is the product, not a poster of it.** Every shortcut away from that — invented data, decorative chrome, a capability shown that does not exist — is a small withdrawal from the trust account.

This skill governs whether a visual is *credible*; what it has to accomplish in the page's argument comes from the product narrative framework in [[layout-paradigms-and-consistency]]. A fabricated proof point proves nothing.

---

## Design With Real Content

Idealised placeholder content hides the problems your design will actually face.

- **No lorem ipsum.** Use real copy, or the closest draft of it. Real words have real lengths, real line-wraps, real awkward edge cases. Latin filler is uniformly tidy in a way your content never will be.
- **Real names, real numbers, real lengths.** "John Smith / $1,234" is a fantasy dataset. Use the longest realistic name, the account with 0 items, the title that wraps to three lines. If the design only looks good with perfect data, it is not finished.
- **Design the empty, loading, error, and overflow states too** — they are the product as much as the happy path. A screenshot that only ever shows the full, perfect state is selling a product that does not exist.

If you genuinely cannot use production data, generate the mock **from the real schema and the real renderer**, so its shape, formatting, and constraints match what ships.

---

## Mirror the Real Output

When a visual stands in for what the product produces — a CLI run, a generated file, a report, a chart, an editor — reproduce the **actual format**, not a prettier reinterpretation.

- Use the product's real output structure: the same labels, the same ordering, the same tree/log/table shape, the same truncation rules ("+4 more").
- Pull the values from a real run where possible. If the visual claims to process `yourdomain.com`, show what processing `yourdomain.com` actually yields — not another site's values relabelled.
- Reuse the real rendering component if one exists. A faithful embed beats a hand-built lookalike that drifts from reality the moment the product changes.
- Breadth is more convincing shown than claimed. Listing the real categories the tool already covers ("also: borders, shadows, motion, components") communicates scope truthfully; a "coming soon" teaser for things that already exist communicates the opposite.

A reinterpreted mock is a maintenance liability and a credibility risk: it looks like the product until someone compares it to the product.

---

## Keep It Truthful

The visual makes claims. Every one must hold.

- **Numbers reflect reality.** Stats, counts, and metrics are real or clearly illustrative — never inflated fiction presented as fact.
- **Labels match content.** Do not relabel one thing as another (a screenshot of system A captioned as system B; a domain in the command that does not match the results shown).
- **Show only real capabilities.** A demo that performs a feature the product does not have is a promise you will break on first use.
- **"Soon" means soon, and rarely earns its place.** A pending/soon badge on something that already ships is a lie; a pending badge on a real roadmap item is usually just noise in a product shot. Prefer showing what works.

---

## Refuse Fabricated Marketing Chrome

A recognisable visual dialect signals "generated to look impressive" rather than "screenshotted from a real product." It reads as AI-slop and erodes the authenticity you are trying to build.

Avoid:
- Invented dashboards, fake charts, and decorative "terminals" that print marketing copy
- Gradient-filled text, sparkle/star accents, aurora glows, and glassmorphism used as a substitute for substance
- Typewriter/rotator headlines and faux-AI chrome (scanning lines, "thinking" shimmers) with no real function
- Pill badges and ornaments that exist only to fill space, especially in places where they clash with the medium (e.g. a label chip dropped into monospace output)

The restraint test: if an element does not exist in the real product, it does not belong in a visual that represents the real product. Decoration that carries no information is the first thing to cut.

---

## When You Must Stage

Sometimes a literal screenshot is impossible (pre-launch, sensitive data, a composite view). Stage honestly:

- Build from the real schema, the real component, and realistic values.
- Match the product's real states and formatting, including the unglamorous ones.
- Keep claims conservative — under-promise in the visual, let the product over-deliver.
- Label clearly illustrative figures as such rather than passing them off as measured.

---

## Photos on a Tinted Stage

A product shot on a tinted tile needs a transparent cutout. An opaque shot with a baked-in white background shows as a white box on the tint. Where cutouts do not exist, multiply-blend the photo onto the tile so the white vanishes.

When a design export and its own screenshot disagree, the screenshot wins. The export is the tool's opinion of the file. The rendering is what shipped.

---

## Review Checklist

- [ ] Is there any lorem ipsum or obviously idealised placeholder content left? (There should be none.)
- [ ] Does the content use realistic lengths — the long name, the empty list, the three-line title?
- [ ] Are the empty, loading, error, and overflow states represented, not just the perfect state?
- [ ] When the visual stands in for product output, does it match the real format, ordering, and truncation?
- [ ] Do the values correspond to the input shown (right domain, right source), not another case relabelled?
- [ ] Is the real rendering component reused where one exists, instead of a hand-built lookalike?
- [ ] Do product photos on tinted surfaces use transparent cutouts or a multiply blend?
- [ ] Are all numbers, labels, and capabilities truthful — nothing inflated, mislabelled, or not-yet-real?
- [ ] Is there any "coming soon" framing on things that already ship?
- [ ] Is there fabricated marketing chrome (fake dashboards, gradient text, sparkles, decorative terminals) that should be cut?
- [ ] Could a visitor screenshot the real product and get the same impression this visual gives? If not, why not?