Produktmanager unterschätzen digitales Produktdesign mit Augmented Reality selten wegen mangelnder Kreativität, sondern wegen falscher Kostenzuordnung. Meine Position: Ein AR-Feature ist zuerst ein Systemrisiko und erst danach ein Interface-Problem, weil Tracking, Assets, Kamera-Rechte und Performance die Nutzererfahrung stärker begrenzen als das schönste Mock-up. Wer den Scope wie eine normale Screen-Erweiterung plant, kauft fast sicher Nacharbeit.
Der teuerste Fehler ist, AR wie einen weiteren Screen zu schätzen
Viele Teams starten mit Figma, FigJam und einem Jira-Epic namens „AR Experience“, weil diese Werkzeuge vertraut sind; genau das verzerrt den Scope, weil ein Bildschirmzustand in Figma keine Sensordaten, keine Beleuchtung, keine Okklusion und keine Framerate enthält. Den Beitrag Digitales Produktdesign fuer moderne Softwareentwicklung lese ich als nützlichen Gegenpol, aber ich würde seine Design-Logik nicht als Startpunkt für ein AR-Feature nehmen, weil AR-Prototypen früher technische Beweise brauchen als klassische Produktoberflächen.
Der erste falsche Kostentopf heißt „Design“. In Wahrheit entstehen Kosten in mindestens vier Arbeitspaketen: Erkennung der Umgebung, 3D-Asset-Pipeline, Runtime-Performance und Produktmessung. Wenn ein PM dafür nur UX-Tage reserviert, werden technische Schulden als Designfeedback getarnt. Das kostet typischerweise einen Sprint, weil Entwickler erst nach dem Usability-Test erklären können, dass das getestete Verhalten auf echten Geräten gar nicht stabil reproduzierbar ist.
Ich würde nicht mit einem perfekt animierten High-Fidelity-Prototypen beginnen, weil er Stakeholdern Sicherheit simuliert, bevor das Team die riskantesten Annahmen geprüft hat. Stattdessen würde ich in Woche 1 einen hässlichen technischen Spike planen: WebXR Device API im Browser, Three.js r160 oder React Three Fiber 8 für die Szene, glTF 2.0 als Asset-Format, dazu ein einziges reales 3D-Modell. Das ist weniger präsentationsfähig, aber es beantwortet die teure Frage: Läuft die Interaktion auf Zielgeräten überhaupt flüssig?
Als kalkulatorische Annahme setze ich für diesen Spike 2 Wochen an, nicht weil zwei Wochen magisch sind, sondern weil ein kürzerer Zeitraum oft nur Demo-Code erzeugt und ein längerer Zeitraum schon Produktentwicklung vortäuscht. Eine vom Anbieter publizierte Web-Vital-Schwelle wie 2,5 Sekunden LCP von Google ist für AR-Landingpages nützlich, aber sie reicht nicht, weil der schwere Teil erst nach dem Laden beginnt. Als justierbarer Budgetwert für frühe AR-Assets ist 8 MB pro GLB-Datei ein guter Start, weil größere Modelle auf mobilen Netzen die erste Interaktion spürbar verzögern. Als interne Messgröße würde ich 30 fps als Warnlinie festhalten, weil darunter räumliche Interaktionen schnell unpräzise wirken, selbst wenn Nutzer den Grund nicht benennen.
Teams verwechseln Prototyp-Treue mit Entscheidungsqualität
Der zweite Fehler ist ein zu breiter Prototyp. Ein AR-Konzept mit Onboarding, Objektplatzierung, Bearbeitung, Teilen, Account-Status und Analytics wirkt vollständig, kostet aber Entscheidungsqualität, weil jedes zusätzliche Detail verdeckt, welche Annahme gerade geprüft wird. Ein PM sollte nicht fragen: „Wie nah sind wir am Zielprodukt?“ Die bessere Frage lautet: „Welche Entscheidung dürfen wir nach diesem Prototypen treffen?“
Ein Figma-Prototyp gewinnt, wenn Textverständnis, Informationsarchitektur oder Call-to-Action-Reihenfolge geprüft werden sollen, weil Figma schnell Varianten erzeugt und mit Maze, Useberry oder Lookback ohne Geräteabhängigkeit getestet werden kann. Ein nativer oder browserbasierter AR-Spike gewinnt, wenn Skalierung, Platzierung, Lichtverhalten, Kamera-Permissions oder Gerätehitze relevant sind, weil nur echte Sensorik diese Risiken zeigt. Figma kostet hier falsche Sicherheit; der technische Spike kostet mehr Setup-Zeit, spart aber spätere Rewrites.
Die explizite Vergleichsentscheidung lautet: Unity 2022 LTS mit AR Foundation 5 gegen WebXR mit Three.js r160. Unity gewinnt, wenn das Produkt tiefe native Funktionen, ARKit 6, ARCore 1.43, plane detection und langfristig komplexe 3D-Interaktionen braucht, weil AR Foundation viele Geräteunterschiede abstrahiert. Unity kostet jedoch größere Builds, Spezialwissen und häufigere App-Store-Abhängigkeit. WebXR gewinnt, wenn Akquise, schnelle Tests und niedrige Einstiegshürden wichtiger sind, weil Nutzer keinen Store-Install durchlaufen. WebXR kostet Geräteabdeckung und Funktionsumfang, weil Safari, Chrome, WebGL 2 und WebXR-Unterstützung je nach Plattform unterschiedlich reif sind.
Den Beitrag Augmented Reality & digitales Produktdesign: Neue Erlebnisse schaffen würde ich vor dem Kick-off kritisch markieren, weil „neue Erlebnisse“ als Ziel zu weich ist, solange niemand sagt, welche technische Unsicherheit mit welchem Budget entfernt wird. Ein Scope-Dokument sollte deshalb nicht „AR erleben“ sagen, sondern „Objekt in unter 5 Sekunden platzieren“, wobei diese 5 Sekunden ein zu kalibrierender Zielwert sind und kein Qualitätsversprechen.
Auch Metriken werden oft falsch gewählt. SUS kann nach einem Test sinnvoll sein, aber SUS erklärt keine Tracking-Aussetzer. Task Success Rate ist nützlich, aber sie verdeckt, ob Nutzer wegen schlechter Anleitung oder wegen instabiler Flächenfindung scheitern. NASA-TLX hilft bei mentaler Belastung, aber es ist für kleine Produktentscheidungen zu schwergewichtig, weil Auswertung und Interpretation mehr Zeit kosten als ein klares Beobachtungsprotokoll. Für die erste Scope-Runde reichen meist vier harte Messpunkte: Startzeit bis Kamerabild, Zeit bis erste gültige Platzierung, Abbruchquote nach Permission-Dialog und Framerate während der Interaktion.
Die Asset-Pipeline wird zu spät geplant und frisst dann den Sprint
Der dritte Fehler ist die Annahme, 3D-Assets seien „Content“. In AR sind Assets Teil der Softwarearchitektur, weil Polygonzahl, Texturgröße, Materialsystem, Kompression und Downloadstrategie direkt über Performance entscheiden. Ein PM, der 3D-Modelle erst kurz vor dem Test bestellt, riskiert Leerlauf im Engineering, weil Entwickler ohne finale Größenordnung keine seriösen Performance-Budgets setzen können.
Ein realistischer Scope nennt Formate und Grenzen früh. Für Web-nahe AR sind glTF 2.0 und binäre GLB-Dateien oft praktikabel, weil sie mit Three.js, Babylon.js 6 und vielen Pipeline-Tools lesbar sind. Für iOS Quick Look braucht das Team häufig USDZ, weil Apple diese Datei direkt in AR Quick Look öffnet. Draco 1.5 oder meshopt-Kompression kann Downloadgrößen senken, kostet aber Decoding-Zeit, weil das Gerät Geometrie erst entpacken muss. KTX2 mit Basis Universal reduziert Texturspeicher, verlangt aber saubere Toolchain, weil falsche Transcodierung Artefakte erzeugt.
Die Kosten entstehen selten beim ersten Modell, sondern bei Änderungen. Ein Stakeholder sagt „etwas glänzender“, ein Designer ändert Materialien, ein 3D-Artist exportiert neu, QA findet Flackern, und plötzlich hängt der Sprint an Blender 4.0, gltfpack, Git LFS und Review-Konventionen. Deshalb sollte das Backlog ein Asset-Definition-of-Done enthalten: maximale Dreiecke, maximale Texturauflösung, erlaubte Materialtypen, Dateigröße, Exportbefehl, Testgerät und Screenshot-Nachweis.
Ein simples Budget kann automatisiert werden, bevor die Pipeline perfekt ist. Dieses kleine Skript läuft lokal, erzeugt bei Bedarf eine Testdatei und bricht mit Fehlercode ab, sobald das GLB-Budget überschritten wird:
python3 - <<'PY'
from pathlib import Path
budget_mb = 8
asset = Path("public/ar/demo.glb")
asset.parent.mkdir(parents=True, exist_ok=True)
if not asset.exists():
asset.write_bytes(b"0" * 1024 * 1024)
size_mb = asset.stat().st_size / 1024 / 1024
print(f"{asset}: {size_mb:.2f} MB")
raise SystemExit(0 if size_mb <= budget_mb else 1)
PY
Das Skript ersetzt keine Pipeline, aber es verhindert eine typische Scope-Lüge, weil Dateigröße dadurch nicht erst im Release-Candidate sichtbar wird. In CI kann derselbe Gedanke mit GitHub Actions, pnpm 9, Lighthouse CI 0.13 oder einem Playwright 1.49-Test erweitert werden. Wichtig ist nicht das konkrete Tool, sondern der Zeitpunkt: Budgets müssen vor dem ersten Stakeholder-Demo-Termin gelten, weil Demos sonst auf Entwickler-Laptops optimiert werden und echte Nutzergeräte erst später die Rechnung präsentieren.
Permission-Dialoge und Messung sind Produktumfang, keine Randnotizen
Der vierte Fehler ist die Unterschätzung von Kamera-Rechten, Datenschutztexten und Messpunkten. Ein AR-Feature ohne Kamera-Permission existiert nicht, und ein Produktfluss, der den Permission-Dialog schlecht vorbereitet, verliert Nutzer vor der ersten Interaktion. Das ist keine juristische Fußnote, weil der Dialog im entscheidenden Moment die Kontrolle vom Produkt an das Betriebssystem abgibt.
Ein PM sollte deshalb Scope für Copy, Zustandslogik und Fallbacks einplanen. Was passiert, wenn Kamera-Zugriff verweigert wird? Gibt es eine 2D-Alternative? Wird der Nutzer in iOS-Einstellungen geschickt? Gibt es eine Demo ohne Kamera? Diese Fragen kosten Design- und Engineering-Zeit, weil jeder Zustand in Storybook 8, Chromatic und End-to-End-Tests sichtbar sein sollte. Wer sie nicht plant, zahlt in QA, weil „funktioniert nicht“ später viele Ursachen haben kann: Permission verweigert, Browser inkompatibel, Sensor blockiert, Asset nicht geladen oder Tracking verloren.
Messung wird ebenfalls oft zu spät ergänzt. Google Analytics 4 oder PostHog können Ereignisse zählen, aber sie erklären ohne sauberes Event-Modell nicht, wo AR scheitert. OpenTelemetry ist für Frontend-Spans nützlich, aber es ist in frühen Produktteams nur dann sinnvoll, wenn jemand die Daten wirklich liest. Ich würde ein schmales Event-Schema bevorzugen: permission_requested, permission_granted, asset_loaded, surface_found, object_placed, session_abandoned. Diese Namen sind banal, aber sie machen den Funnel prüfbar, weil jedes Ereignis eine Nutzerhürde beschreibt.
Konkrete Zahlen helfen beim Scope, wenn sie als Hypothesen behandelt werden. Als Produktannahme für einen ersten Feldtest sind 20 bis 30 beobachtete Sessions oft genug, um grobe Bedienfehler zu finden, weil AR-Probleme meist wiederkehrend und sichtbar sind. Für statistische Sicherheit ist das zu wenig, deshalb darf daraus keine Conversion-Prognose gebaut werden. Als gemessener Betriebswert sollte die Abbruchquote nach dem Kamera-Dialog getrennt von der Abbruchquote nach Asset-Ladezeit stehen, weil beide andere Lösungen verlangen.
Auch Standards sind Scope. WebXR Device API, Permissions API, WebGL 2, OpenXR 1.1, glTF 2.0, USDZ, ARKit und ARCore bringen jeweils Annahmen mit. Wer „plattformneutral“ sagt, ohne diese Standards im Scope zu nennen, verkauft eine Abstraktion, weil die Produktentscheidung später doch auf konkrete Browser, Betriebssysteme und Geräte trifft. Geräte-Matrix ist daher kein QA-Luxus: Ein iPhone 12, ein aktuelles iPad, ein mittleres Android-Gerät und ein schwächeres Android-Gerät sind ein besserer Start als zehn zufällige Bürogeräte, weil sie unterschiedliche Performance- und Sensorprofile abdecken.
Realistischer Scope entsteht durch harte Nicht-Ziele
Der fünfte Fehler ist ein Scope ohne Verzicht. AR lädt zu Fantasie ein, und genau deshalb braucht der PM härtere Grenzen als bei einem Formular oder Dashboard. Ich würde für die erste Version keine Multiuser-Synchronisation, keine persistente Raumverankerung und keine fotorealistischen Schatten planen, weil jede dieser Funktionen ein eigenes technisches Risiko einführt und die Kernfrage der Nutzbarkeit überlagert.
Ein gutes Nicht-Ziel ist spezifisch. „Keine komplexen Animationen“ ist zu schwach, weil niemand weiß, was komplex bedeutet. Besser: „Nur eine Platzierungsanimation unter 700 ms, keine interaktiven Partikelsysteme, keine Physiksimulation.“ Diese Grenze ist streitbar, aber sie spart Abstimmungszeit, weil Designer, Entwickler und QA denselben Testgegenstand sehen. Ebenso sollte „nur ein Modell“ nicht als Mangel gelten, weil ein einzelnes Asset die Pipeline besser testet als fünf unfertige Varianten.
Der realistische Arbeitszuschnitt kann so aussehen: Woche 1 technischer Spike mit WebXR oder Unity-Entscheidung, Woche 2 Asset-Pipeline und Permission-Flow, Woche 3 beobachtbarer Nutzertest, Woche 4 Stabilisierung und Scope-Entscheidung. Diese 4 Wochen sind kein universeller Plan, sondern eine Planungsgrenze für ein erstes Risiko-Inkrement, weil danach genügend Evidenz vorliegen sollte, um zu stoppen, zu investieren oder radikal zu kürzen.
Der wichtigste PM-Satz lautet nicht „Wir bauen AR“, sondern „Wir kaufen Evidenz für eine Entscheidung“. Legen Sie morgen eine einseitige Scope-Tabelle an: Zielentscheidung, riskanteste Annahme, Testgerät, Asset-Budget, Messereignisse, Nicht-Ziele und Abbruchkriterium. Erst wenn diese Tabelle einen Besitzer und ein Datum hat, lohnt sich der nächste Prototyp.
