1. Inhalt, 3D und nächste Handlung in drei Ebenen beschreiben
Zuerst wird beschrieben, was Besucher erfahren und anschließend tun sollen. Namen, Produkteigenschaften, Bilder und Kontaktwege bilden die Informationsebene. Modelle, Texturen und räumliche Navigation bilden die Darstellungsebene. Eine Anfrage, ein Datenblatt oder eine bestätigte Weiterleitung ist die nächste Handlung. Diese Ebenen erhalten eigene Verantwortliche.
Das CMS kann bestimmte Texte oder Medien liefern; ein Modellwechsel kann zusätzlich einen neuen 3D-Export benötigen. Im Briefing steht deshalb pro Inhalt, woher er kommt, wer ihn pflegt und welche Änderung eine neue technische Prüfung auslöst. Es wird nicht pauschal versprochen, dass jedes vorhandene System jeden Szenenbestandteil direkt steuern kann.
| Inhalt | Quelle und Verantwortung | Was bei Änderung geprüft wird |
|---|---|---|
| Text / Produktmerkmal | Benannte Fachperson und freigegebener Inhaltsstand | Beschriftung, Sprache und fachliche Darstellung |
| 3D-Modell / Textur | Bestätigter Export und technische Produktion | Geometrie, Material, Dateistand und Zielgeräte |
| Nächste Handlung | Aktueller Link, Formular oder Ansprechpartner | Erreichbarkeit und verständlicher Übergang |
2. Eigenständige Route oder eingebettete Anwendung abwägen
Eine Anwendung kann eine eigene Seite erhalten oder als abgestimmtes Modul in eine vorhandene Seite eingebunden werden. Die Entscheidung hängt von Routen, Hosting, Inhaltsverwaltung und technischen Vorgaben ab. Bei einer bestehenden Website werden Zuständigkeiten von Agentur, IT und Produktion zuerst benannt; Zugang und Änderungsprozess folgen dem vereinbarten Umfang.
Für den technischen Check helfen CMS-/Frontend-Angaben, gewünschte Domain und Route, Authentifizierung, Inhaltsquelle und vorhandene Kontakt-/Messwege. Nach Prüfung wird das konkrete Integrationsmodell beschrieben. Eine allgemeine WordPress-, Webflow- oder CRM-Kompatibilität wird aus einem räumlichen Prototyp nicht abgeleitet.
| Variante | Vor dem Angebot klären | Prüfbare Übergabe |
|---|---|---|
| Eigene Route | Domain, Hosting, Navigation und Inhaltszugriff | Erreichbare Anwendung mit abgestimmten Hin-/Rückwegen |
| Eingebettetes Modul | Technischer Einbau, Größenwechsel, Lade-/Bedienverhalten | Funktion im echten Seitenkontext und auf Zielgeräten |
| Dynamischer Inhalt | Datenquelle, Aktualisierung und Fehlerfall | Geprüfte Inhalte und dokumentierte Schnittstelle im vereinbarten Umfang |
3. Kaufrelevante Inhalte außerhalb der Szene erreichbar halten
Produktinformation und Kontakt dürfen nicht ausschließlich in einer grafischen Szene verborgen sein. Relevante Aussagen erhalten eine verständliche HTML-Ansicht. Links zu Datenblatt, Leistung und Anfrage sind echte Verbindungen mit nachvollziehbarer Beschriftung. So finden Besucher den nächsten Schritt auch dann, wenn sie die räumliche Navigation nicht nutzen.
Google beschreibt Crawling, Rendering und Indexierung als getrennte Verarbeitungsschritte. Ein HTTP-200-Status bestätigt die Erreichbarkeit, nicht die Aufnahme in den Suchindex. In der technischen Vorschau werden sichtbarer Inhalt und Linkwege vor und nach JavaScript verglichen; eine Suchdarstellung oder Indexierung wird nicht garantiert.
4. Laden und Bedienung mit einer konkreten Besuchsaufgabe testen
Der erste Prototyp enthält die zentrale Interaktion. Getestet werden Einstieg, Orientierung, Touch-/Tastaturbedienung und der vereinbarte Informationsübergang. Desktop, Smartphone und Messedisplay haben unterschiedliche Eingaben und Netzbedingungen. Die tatsächlich vorgesehenen Geräte und Testbedingungen stehen im Protokoll.
Modelle, Texturen und Medien erhalten ein begründetes Ressourcenbudget. Aufwendige Effekte können später oder nach einer bewussten Interaktion geladen werden. Eine statische Ansicht erklärt dieselbe wesentliche Information, wenn ein reduzierter oder alternativer Weg erforderlich ist. Reduzierte Bewegung und Rückwege werden als eigene Bedienanforderungen beurteilt.
5. Hosting, Pflege und Fehlerverantwortung übergeben
Vor dem Release stehen Inhalts-, Modell- und Softwarestand fest. Die Übergabe nennt Ansprechpartner, vereinbarte Zugänge, Dokumentation, Einweisung und Pflegegrenzen. Wenn eine Datenquelle ausfällt, muss erkennbar sein, welche Darstellung verwendet wird und wer den Fehler bearbeitet. Eine lauffähige Demo enthält diese Betriebsvereinbarung nicht automatisch.
Die Abnahme umfasst technische Funktion und fachlichen Inhalt. Zusätzliche Produktvarianten, Sprachen oder Systemanbindungen werden mit ihrer eigenen Datenbasis und Prüfung erweitert. Für ein erstes Gespräch reichen die vorhandene Website, Zielgeräte, wichtigste Besucheraufgabe und benannte Systemverantwortliche.
Checkliste für Ihr Briefing
- Vorhandene Website, CMS und technische Ansprechpartner benennen
- Wesentliche Inhalte und gewünschte Besucherhandlung beschreiben
- Inhaltsquelle und Modellpflege getrennt zuordnen
- Route oder Einbettung anhand des echten Systems prüfen
- HTML-Alternative, echte Links und mobile Bedienung testen
- Hosting, Fehlerfälle, Dokumentation und Pflegeumfang vereinbaren
Fachliche Quellen
- Google: Grundlagen von JavaScript-SEO
Inhalt, Rendering und Crawl-Verarbeitung.
- Google: Crawlbare Links
Verständliche href-Verbindungen statt alleiniger Klickaktionen.
- MDN: WebGL Best Practices
Geräte-/Ressourcenfragen als Grundlage des technischen Tests.
Die passenden Leistungen verbinden
- Immersive WebsitesKonzept, Webentwicklung und technische Prüfung
- Interaktive 3D-WeltenModelle und Besucherfragen verbinden
- AgenturpartnerschaftÜbergreifende Projektrollen und Produktion
Welche Bestandteile Ihr Projekt benötigt, klären wir anhand von Ziel, Fläche, Timing und gewünschtem Ergebnis.
Projekt besprechen