Das Wichtigste auf einen Blick
- KI-Generierung ist nur eine Funktion innerhalb eines umfassenderen Authoring-Produkts.
- Eingaben, Prüfstatus, Bearbeitungsschritte und Ausgabeformate brauchen klare Definitionen.
- Ein grobes UX- und Architekturkonzept legt verborgene Komplexität offen, bevor die Entwicklung beginnt.
- Eine klar begrenzte Discovery-Phase senkt das Entwicklungsrisiko und ermöglicht eine belastbare Aufwandsschätzung.
Prototypen zuerst führen zu reiner Demo-Software
KI-Authoring-Projekte beginnen oft mit der sichtbarsten Funktion: ein Dokument hochladen, ein Modell aufrufen und einen Kurs generieren. Das Ergebnis kann schon nach wenigen Tagen beeindruckend aussehen. Gleichzeitig kann es all die Entscheidungen verdecken, die darüber bestimmen, ob das System nach dem Launch tatsächlich nutzbar ist.
Für wachsende Startups ist das besonders relevant, denn internes Wissen ist selten sauber strukturiert oder dauerhaft stabil. Richtlinien ändern sich, Produktwissen liegt bei Spezialisten, und neue Mitarbeitende brauchen konkrete Orientierung statt einer allgemeinen Zusammenfassung. Ein KI-gestützter Prozess zur Kurserstellung muss deshalb mehr leisten, als Quellenmaterial in Text zu verwandeln. Er muss festlegen, was als verlässliche Eingabe gilt, wer generierte Inhalte prüft, wie Fachexperten sie bearbeiten und wo das freigegebene Ergebnis veröffentlicht wird.
Ohne diese Leitplanken beantwortet ein Prototyp nur, ob ein Modell irgendetwas generieren kann. Er beantwortet nicht, ob das Unternehmen das Produkt betreiben, pflegen und ihm vertrauen kann. So wird aus einer überzeugenden Demo ein teures System, für das sich niemand verantwortlich fühlt.
Die Produktdefinition schafft einen umsetzbaren Rahmen
Das erste Ergebnis der Produkt-Discovery für KI-Authoring sollte eine klar abgegrenzte Produktdefinition sein. Sie ist weder ein langes Anforderungsdokument noch ein isoliertes technisches Konzept. Sie bündelt die Entscheidungen, die das kleinste sinnvolle Produkt, sein Betriebsmodell und die nötigen Kompromisse für die Umsetzung festlegen.
Eine belastbare Produktdefinition für ein EdTech-Produkt sollte sechs Bereiche klar benennen:
- Nutzende und ihre Aufgaben, darunter Content-Verantwortliche, Prüfer, Redakteure, Administratoren und Lernende.
- Eingaben wie Dokumente, bestehende Trainings, Experteninterviews, strukturierte Daten oder unternehmensinterne Wissensdatenbanken.
- Generierte Lernbausteine, darunter Lektionen, Wissenschecks, Szenarioübungen, Zusammenfassungen, Karten und rollenspezifische Lernpfade.
- Menschliche Kontrollmechanismen, darunter Sichtbarkeit der Quellen, Prüfstatus, Freigaberechte, Versionsverlauf und Eskalationsregeln.
- Veröffentlichung und Bereitstellung, darunter webbasiertes Lernen, mobile Komponenten, LMS-Export oder die direkte Bereitstellung über die Plattform.
- Technische Grenzen, darunter Identitäten, Berechtigungen, Integrationen, Content-Speicherung, Modellzugriff und Datenverarbeitung.
Diese Entscheidungen schaffen ein gemeinsames Verständnis davon, was Erfolg bedeutet. Gleichzeitig verhindern sie, dass das Team jede denkbare Funktion in Version eins packt. Für Gründerteams mit begrenztem Budget ist dieser Rahmen oft wertvoller als ein schneller Prototyp: Er macht aus einer vagen Ambition eine Entscheidung über Umfang, Kosten und Risiken.
Der Workflow ist das Produkt
Die zentrale Designaufgabe ist nicht der Prompt für die Generierung, sondern das Statusmodell darum herum. Ein Lernbaustein kann sich vom importierten Quellenmaterial über einen Entwurf, die Prüfung durch Fachexperten, die redaktionelle Überarbeitung, Freigabe und Veröffentlichung bis zur späteren Aktualisierung bewegen. Jeder Status braucht eine verantwortliche Person, eine erlaubte Aktion und einen klaren Verlauf der Änderungen.
Hier zeigt sich der Wert grober UX-Arbeit. Ein einfacher Ablauf kann früh schwierige Fragen sichtbar machen: Kann ein Prüfer eine einzelne Quizfrage freigeben und den Rest eines Moduls zurückgeben? Unterbricht die Bearbeitung generierten Texts die Verbindung zur Quelle? Kann ein Administrator freigegebene Bausteine in mehreren Onboarding-Pfaden verwenden? Was passiert, wenn sich das zugrunde liegende Richtliniendokument ändert?
Die Antworten prägen Oberfläche, Berechtigungsmodell und Datenstruktur. Sie entscheiden auch darüber, ob Fachexperten das System annehmen. Wenn Prüfung und Überarbeitung mehr Aufwand verursachen als das Erstellen von Grund auf, hat die Automatisierung den eigentlichen Engpass nicht beseitigt.
Good to know
Wie lange sollte eine Discovery-Phase für KI-Authoring dauern?
Sie sollte kurz und klar begrenzt sein, aber ausreichend Zeit bieten, um Entscheidungen zu klären, die den Umfang verändern. Es geht nicht um eine vollständige Spezifikation, sondern um einen nutzbaren Produktumfang, eine grobe Architektur und eine Aufwandsschätzung als Grundlage für eine Investitionsentscheidung.
Kann ein Startup stattdessen mit einem Prototyp starten?
Ja, wenn der Prototyp eine klar eingegrenzte Unsicherheit prüft, etwa die Extraktion aus Quellen oder die Fragengenerierung. Er sollte nicht mit Produkt-Discovery verwechselt werden. Ein Prototyp ersetzt keine Entscheidungen zu Prüfung, Verantwortlichkeiten, Bearbeitung, Veröffentlichung und Integration.
Welche Teams sollten an der Definitionsphase beteiligt sein?
Beteiligt den Business-Verantwortlichen, die vorgesehenen Administratoren, Fachexperten, eine technische Leitung und Vertretende der Zielgruppe der Lernenden. Eine kleine Gruppe mit klaren Entscheidungsrechten ist hilfreicher als ein großer Workshop, für den sich niemand verantwortlich fühlt.
Die Ausgaben definieren die Integrationsgrenze
Ein generierter Kurs ist nicht nur ein einziges Ausgabeformat. Ein Unternehmen braucht vielleicht Mobile-first-Onboarding-Module für neue Mitarbeitende, ein anderes wiederverwendbare Lernbausteine innerhalb einer bestehenden Plattform. Manche Teams benötigen eine direkte Lernumgebung. Andere brauchen Pakete oder strukturierte Inhalte, die sie in ihr LMS übertragen können. Die Entwicklung eines LMS-Produkts darf nicht als Exportaufgabe behandelt werden, die erst am Ende hinzukommt. Anforderungen an die Ausgabe beeinflussen das Design der Bausteine von Anfang an.
Die Produktdefinition sollte festlegen, welche Formate erforderlich sind, welche Metadaten jeder Baustein mitbringt, wie Abschluss- und Bewertungsdaten verarbeitet werden und welches System die führende Datenquelle ist. Sie sollte auch klar benennen, wo das Produkt endet. Ein kleines internes Authoring-Tool muss nicht zu einem vollständigen Learning Management System werden, nur weil es Trainings erstellt.
Diese Entscheidungen bilden die Architektur der Lerntechnologie. Sie zeigen, ob das Produkt ein Content-Repository, eine Workflow-Engine, eine Integrationsschicht, rollenbasierte Zugriffsrechte oder eine separate Anwendung für Lernende braucht. Eine grobe Architektur reicht in dieser Phase aus, solange sie Abhängigkeiten und Aufwand sichtbar macht.
Plant das Authoring-Produkt, bevor ihr die Entwicklung finanziert.
PlanenDiscovery macht aus Ambition eine technische Entscheidung
App-Learning versteht Authoring-Discovery als Produktarbeit vor der Umsetzung. Wir erheben Anforderungen, definieren den Funktionsumfang, bilden die wichtigsten Nutzerabläufe ab, skizzieren das Modell für Lernbausteine, setzen technische Grenzen und übersetzen das Ergebnis in eine praktische Aufwandsschätzung. So erhalten Gründerteams eine Grundlage, um zu entscheiden, was sie jetzt bauen, was sie verschieben und was außerhalb des Produkts bleiben sollte.
Das Ergebnis ist kein Versprechen, dass KI jedes Wissensproblem löst. Es ist ein testbarer Plan für ein Produkt, das Unternehmenswissen in pflegbare Lerninhalte verwandeln kann. Wenn Eingaben, Prüfmechanismen, Bearbeitungsabläufe, Bereitstellungsformate und Architektur zuerst definiert sind, kann die Umsetzung auf ein reales Betriebssystem zielen statt auf den nächsten beeindruckenden Screen.
