What this prompt does
This prompt designs a landing page for an AR/VR product ([product_name], a [product_type] experience) that sells the experience on the open web without forcing visitors into a headset. You supply the [platforms], the [audience], and the [status], and it generates the full page: an immersive hero, an experience preview, a feature showcase, device compatibility, a how-to-get-started guide, social proof, and a download/try CTA, plus [framework] code for the hero with a 3D background.
The structure works because it treats the 2D web version as a first-class product, not a fallback. It sells the experience rather than the technology, it refuses to require a VR headset just to browse, and it explicitly guards against making the page so heavy with WebGL that it lags on mobile. The [feature_count] variable controls how many key features appear in the showcase, and [status] (available now, coming soon, demo) shapes the CTA so visitors are pushed toward the right next action whether that is a store link, a QR code for mobile AR, or a demo.
When to use it
- You are launching an AR/VR or 3D product and need a page that works for non-VR visitors
- Your audience is enterprise or education and won't tolerate jargon-heavy VR marketing
- You need a WebGL or Three.js hero that still loads acceptably on a phone
- You want device compatibility laid out clearly with minimum specs
- You need platform store badges and a QR code for the mobile AR entry point
- You are shipping this as a real production front-end, not a throwaway demo
Example output
You get a section-by-section page spec on a dark, futuristic palette with vibrant accents and gradient glows, each section describing its content, interactions, and the 3D or parallax effects involved. The final deliverable is [framework] code for the hero with a 3D background and the feature showcase section, written to stay within a sensible performance budget.
Pro tips
- Fill
[product_name]and[product_type]specifically so the copy sells your actual experience, not generic VR - Set
[platforms]to only the headsets you truly support so the compatibility section stays honest - Match
[audience]to your real buyer; enterprise training reads very differently from consumer gaming - Keep
[feature_count]modest (4 is plenty) so each feature gets a real visual demonstration - Ask explicitly for a mobile performance budget on the
[framework]hero; WebGL is easy to overbuild - Use
[status]to drive the CTA: a demo option for "available now" versus an email capture for "coming soon"
