Swoop als Produktsystem gestalten.
Swoop begann mit einem Kundenbedürfnis, nicht mit einer KI-Lösung. Die eigentliche Herausforderung war nie das Generieren von Folien — sondern aus einzelnen KI-Fähigkeiten ein Produkt zu machen, das versteht, welche Aufgabe jemand tatsächlich erledigen will.
Director of Product Design & Research — in diesem Projekt Strategin und Hands-on-IC zugleich. Ich habe das Problem definiert, die beiden Experimente durchgeführt und das Intent-Modell sowie die Agentenarchitektur selbst gestaltet.
Zwei Experimente, in der Reihenfolge, die die Evidenz verlangte — beide als funktionsfähige, KI-integrierte Prototypen, nicht als Folien. Das erste testete die Generierung; seine Erkenntnisse richteten das zweite auf eine Forschungsfrage aus: Woher wissen wir, was jemand tatsächlich braucht? Dabei habe ich durchgehend gemeinsam mit Engineering Code in Produktion gebracht.
Nicht „eine Prezi erstellen“, sondern die Komplexität von Inhalt, Kontext und Ziel der Nutzer verstehen — und dann die richtige Präsentation für genau diese Situation erstellen. Ein breiterer Job als der, für den das Produkt gebaut war.
Swoop wurde öffentlich als KI-Kommunikationsagent von Prezi gelauncht — auf Basis des hier beschriebenen Intent- und Kontextmodells.
Die exportierten Decks pro aktivem Nutzer haben sich in den zwei Monaten nach dem Launch nahezu verdreifacht (0,76 → 2,52), während Generierungsqualität und Onboarding reiften.
Das Spannungsfeld, das ich vor der KI entdeckte.
Menschen mussten kommunizieren. Eine Prezi brauchten sie nicht immer.
Ich habe ein Spannungsfeld im Produkt identifiziert: Nutzer kamen, um mit Präsentationen zu kommunizieren, doch das Prezi-Format war nicht immer die Antwort. Viele wollten klassische lineare Folien oder mussten ein PPT oder PDF exportieren, um es weiterzugeben.
Als Job to be Done formuliert, bediente das Produkt einen engeren Job als den, für den Menschen es eigentlich nutzten. Der Job war nicht eine Prezi erstellen, sondern die richtige Präsentation für diese Situation erstellen — wobei „richtig“ vom Publikum, vom Anlass und vom Dateiformat abhängt, das die Gegenseite erwartet. Nach nichts davon fragte das Produkt.
Diese Rahmung hat später die eigentliche Arbeit geleistet, denn sie hat verhindert, dass das Projekt zu „KI in den Editor einbauen“ wurde. Wenn der Job darin besteht, eine fertige, situationsgerechte Präsentation zu liefern, ist Generierung nur eine Fähigkeit unter mehreren — und die interessanten Probleme liegen um sie herum, nicht in ihr.
Als generative KI das autonome Erstellen von Folien möglich machte, starteten wir erste Experimente auf Basis einer strategischen Intuition: dass sich das Produkt davon wegbewegen könnte, Menschen Werkzeuge zum Erstellen in die Hand zu geben — hin dazu, gemeinsam mit ihnen eine fertige Präsentation zu erstellen.
Zwei Experimente, in der richtigen Reihenfolge.
Generierung war das offensichtliche Problem. Intent war das eigentliche.
Experiment eins — Generierung
Ich begann mit einem Projekt, das detailliert festlegte, wie die Generierung funktionieren sollte: wie ein gutes Deck aussieht, was das System entscheidet und was beim Nutzer bleibt. Es beantwortete die Frage, die wir gestellt hatten.
Experiment zwei — Intent
Es brachte aber auch das darunterliegende Problem zutage — eine Forschungsfrage, noch bevor es eine Designfrage ist: Woher wissen wir, was der Nutzer tatsächlich braucht?
Echte Produktgespräche zeigten denselben Job in sehr unterschiedlichen Formulierungen. Manche kamen mit einem bereits ausgearbeiteten, detaillierten Briefing. Andere schrieben eine Handvoll Wörter und erwarteten, dass das Produkt den Rest übernimmt.
Ein einziger Klärungsflow konnte nicht beiden gerecht werden. Einem vollständig gebrieften Nutzer unnötige Fragen zu stellen, erzeugt Reibung; einem Nutzer mit spärlichem Input gar keine zu stellen, hinterlässt ihn mit einem generischen Deck. Ein Standardflow für alle hätte keinem von beiden gedient. Durch diese Erkenntnis wurde Klärung von einem Screen zu einer Entscheidung, die das System jedes Mal treffen muss.
Nur fragen, wenn die Antwort das Ergebnis verändern würde.
Drei Zustände, eine Regel.
Daraus entstand ein Guard-Agent-Modell. Zweck, Zielgruppe und Länge werden jeweils als explizit, ableitbar oder tatsächlich unbekannt eingestuft. Das System fragt nur, wenn die fehlende Information das Ergebnis wesentlich verändern würde — nicht immer dann, wenn ein Feld leer ist.
- Explizit — vom Nutzer angegeben. Wird sofort übernommen und nie erneut abgefragt.
- Ableitbar — aus dem hochgeladenen Material oder dem Gespräch erschließbar. Wird genutzt, aber sichtbar gemacht, damit es korrigiert werden kann.
- Tatsächlich unbekannt — und folgenreich. Nur in diesem Fall ist eine Frage gerechtfertigt.
Erst diese Regel macht daraus eine Produktentscheidung statt eines Prompts: Sie legt fest, wann das System die Aufmerksamkeit des Nutzers beanspruchen darf.
Von Fähigkeiten zu einem Experience-System.
Die Karte war keine Vorhersage. Sie machte Abhängigkeiten sichtbar.
Aus diesen Erkenntnissen habe ich eine übergeordnete Vision des End-to-End-Erlebnisses entworfen und eine Architektur kollaborierender Agenten skizziert — die Intent und Kontext mit Orchestrierung, spezialisierten Fähigkeiten, Qualitätskontrollen und Feedback verbindet.
Dieses frühe Systemmodell war nicht die finale Produktionsarchitektur. Sein Wert lag woanders: Es gab Product, Design und Engineering eine gemeinsame Sprache, um darüber zu diskutieren, wie das Erlebnis funktionieren sollte und was dahinter passieren musste. Es zeigte, welche Signale wir beobachten konnten, was das System sicher ableiten durfte, was eine Bestätigung erforderte und wo Kontext über das gesamte Erlebnis hinweg geteilt werden musste.
Kontext weitertragen — ohne riskante Annahmen.
Kontext muss dem Job folgen, nicht der Funktion.
Das übergreifende Problem dieser Architektur bestand darin, die einzelnen Phasen zu verbinden, ohne dass Nutzer die Agenten oder Modelle darunter verstehen müssen. Kontext musste dem Job über die gesamte Journey folgen, statt von jeder Funktion neu erzeugt zu werden — und das, ohne dass das System stillschweigend Dinge über jemanden entscheidet.
Deshalb habe ich Kontext danach getrennt, was er ist und wie sehr man ihm vertrauen kann:
- Wer der Nutzer ist — Rolle, Branche, Organisation.
- Was seine kreative Identität ausmacht — Marke, Tonalität, visuelle Richtung.
- Wie er bevorzugt arbeitet — Struktur, Dichte, wiederkehrende Szenarien.
Jede Ebene hat eine andere Berechtigung. Explizite Informationen können sofort übernommen werden. Abgeleitete Präferenzen erfordern eine Bestätigung. Wiederkehrende Muster können dauerhaft werden. Und universelle Regeln — Barrierefreiheit, Sicherheit, Datenintegrität — kann keine davon außer Kraft setzen, egal wie stark das Signal ist.
Was sich dadurch an der Arbeit verändert hat.
Ich habe aufgehört, nur Screens zu gestalten.
Das Designmaterial hat sich verändert. Ich definierte nicht mehr Screens und Flows — sondern Entscheidungslogik, Kontextgrenzen, Tool-Berechtigungen, Recovery-Verhalten und Bewertungskriterien.
Nichts davon taucht in einem Mockup auf. Nutzer sehen ein Eingabefeld und ein fertiges Deck. Das Produkt ist das Regelwerk darunter: wann das System selbstständig handelt, wann es innehält, um nachzufragen, und was es niemals über jemanden annehmen darf.