Nachdem sie CapCut verlassen hat, um ein eigenes Startup zu gründen, möchte sie ein gesamtes Design-Team in eine KI-Arbeitsplattform integrieren.

Wie GeekPark erfahren hat, hat Zhang Qizhi, ehemalige Leiterin von Jianying China, das Unternehmen verlassen, um ein Startup zu gründen: Sie gründete die Arbeitsplattform für KI-Produktprototypendesign OJO und schloss kürzlich eine erste Finanzierungsrunde in Höhe von fast 100 Millionen Yuan ab, die gemeinsam von Shunwei Capital und Lenovo Venture Capital investiert wurde, wobei Gaohe Capital als exklusiver Finanzberater fungierte.

Dies ist das erste Startup-Projekt von Zhang Qizhi nach ihrem Abschied von ByteDance. Sie trat 2017 als Produktmanagerin bei Mengyi ein, wechselte 2018 mit dem Team zu ByteDance und war danach lange Zeit an Produkten und Geschäften im Zusammenhang mit Jianying beteiligt.

In der Öffentlichkeit gilt ihre Erfahrung bei Jianying als wichtiger Hintergrund für das Verständnis dieses Startup-Vorhabens: Sie hat den vollständigen Prozess eines Werkzeugprodukts von 0 auf 1 und anschließend zu großem Wachstum bis zur Suche nach neuen Wachstumskurven miterlebt. Da Coding-Agenten wie Claude Code, Codex und Cursor die „Herstellung eines Produkts“ immer einfacher machen, richtet sie ihre Aufmerksamkeit auf einen weiteren unzureichend gelösten Bruchpunkt in der Produktionskette von Produkten: die Designbeurteilung und wie diese Beurteilung zwischen Produkt, Design und Entwicklung kontinuierlich übertragen werden kann.

OJO definiert sich selbst als „Design Agent Team Workspace“. Nutzer können in einer einzigen Arbeitsumgebung mit natürlicher Sprache Produktüberlegungen, Oberflächendesign, Iterationen und Codebereitstellung durchführen. Die Frage, die es beantworten möchte, lautet: Warum ist eine Arbeitsplattform, die Design und Entwicklung miteinander verbindet, weiterhin als eigenständiges Produkt wertvoll, nachdem UI-Generierung, Designbearbeitung und Design-zu-Code-Umwandlung allmählich verbreitet sind?

Die Antwort von Zhang Qizhi lautet: Je leistungsfähiger das Modell ist, desto mehr benötigt es ein System, das diese Fähigkeiten in spezifischen Szenarien einsetzt. OJO möchte Produktdefinition, visuelles Design, Interaktionsiteration und Codebereitstellung in einen kontinuierlichen Prozess einbinden, um zu vermeiden, dass Beurteilungen bei der Übergabe zwischen verschiedenen Rollen an Genauigkeit verlieren.

Das ist immer noch eine Antwort, die auf die Bestätigung durch den Markt wartet.

01. Abschied von Jianying – der Moment, in dem „sie selbst und die Technik bereit sind“

Vor 2025 verlief die berufliche Laufbahn von Zhang Qizhi bei ByteDance recht reibungslos. Obwohl sie lange Zeit im Geschäftsbereich von Jianying tätig war, stand sie ständig vor neuen Problemen: von Werkzeugprodukten bis zur Globalisierung, von Produktwachstum bis zu Umsatz und Nutzerbewusstsein. Die Veränderung trat 2025 ein: Nachdem das Geschäft in eine relativ stabile Phase eingetreten war, spürte sie zum ersten Mal deutlich, dass ihr eigener Input geringer als der Output wurde.

Daraus entstand die Idee für das Startup, aber sie war stets vorsichtig. In großen Unternehmen gibt es bereits ein ausgereiftes Organisationsnetzwerk, und die wichtigste Aufgabe einer Leitungskraft besteht darin, die Richtung und das Tempo des Fortschritts zu bestimmen. Ein Startup zu gründen bedeutet hingegen, die gesamte Organisation von Grund auf neu aufzubauen. Was sie wirklich erwartete, war das gleichzeitige Eintreten zweier Bedingungen: Sie war bereit, ein neues Team aufzubauen, und die Fähigkeiten der Modelle reichten aus, um die Zusammenarbeit zwischen Produkt und Design neu zu gestalten.

Bildquelle: OJO

Jianying gab ihr eine „Landkarte“ über das Ausmaß von Produkten. Ihrer Meinung nach sind die Zustände von 0 auf 1 und von 1 auf 100 zwei völlig unterschiedliche Dinge. Als Jianying die internationale Version CapCut und die PC-Version auf den Markt brachte, trafen viele Entscheidungen darauf zurück, dass das Team frühe Signale erkannte, schnell Prototypen erstellte, diese veröffentlichte und anhand des Feedbacks entschied, ob die Investitionen erhöht werden sollten. Der Schlüssel von 0 auf 1 liegt darin, die Geschwindigkeit an das Zeitfenster anzupassen und gleichzeitig die Kosten für Fehlversuche zu kontrollieren.

Nach dem Übergang von 1 auf 100 geht es nicht mehr nur um Geschwindigkeit. Mit der zunehmenden Reife des Geschäfts nehmen die Renditen der früher wirksamen Wachstumsmethoden ab, und das Team muss sich von kurzfristigem Funktionswettbewerb zu langfristigen Veränderungen von Inhaltsformen und Produktionsweisen wenden.

Diese Erfahrung machte sie sensibel für Zeitfenster, frühe Signale und Wachstumsengpässe. Der technische Meilenstein, der sie endgültig dazu brachte, die Richtung festzulegen, trat zwischen September und Oktober 2025 ein: Die neuen Fähigkeitsfortschritte von Gemini ließen sie zum ersten Mal stark spüren, dass die ehemals festen Grenzen zwischen Code und Ästhetik sich lockern.

Bei Code gibt es relativ klare Richtlinien für richtig und falsch, beim Design gibt es jedoch keine Standardantworten. Derselbe visuelle Stil kann in verschiedenen Kulturen, Branchen und Verbrauchsszenarien völlig unterschiedliche Wirkungen erzeugen. In der Vergangenheit bildete diese Unschärfe eine Mauer zwischen Design und Code.

Aber die Modelle verändern den Ausgangspunkt der Produktzusammenarbeit. Früher beschrieben Produktmanager ihre Ideen normalerweise zuerst in Anforderungsdokumenten, danach erstellten Designer statische Seiten in Figma, verknüpften Interaktionen und zeigten dynamische Effekte über eine Vorschau. Ob ein Konzept tragfähig ist, wurde oft erst im Design- oder sogar Entwicklungsphase wirklich überprüft.

Heutzutage können Produktmanager und Designer mithilfe von Modellen schnell ein ausführbares dynamisches Prototyp erstellen. Zhang Qizhi schaut sich zuerst die dynamischen Interaktionen an: Ihrer Meinung nach bedeutet dies, dass Produktmanager abstrakte Anforderungen zuerst in eine Version umwandeln können, die man anklicken, erleben und diskutieren kann, um die Produktstruktur und die Interaktionsrichtung im Voraus zu überprüfen, bevor sie es an Designer und Entwickler zur weiteren Ausarbeitung weitergeben.

Nicht nur die Effizienz hat sich verändert. Produktmanager können ihre Beurteilungen anhand eines umsetzbaren Ergebnisses ausdrücken, und Designer müssen nicht vollständig auf die Anforderungen der vorgelagerten Rollen warten. Jede Rolle kann die Aufgaben, die früher von nachgelagerten Rollen erledigt werden mussten, zuerst auf ein akzeptables Niveau bringen, bevor die professionelle Zusammenarbeit beginnt.

„Ich bin selbst bereit, und die Technik ist auch bereit“, sagte Zhang Qizhi. Im Gegensatz zu der Zeit bei Jianying muss dieses Mal nicht nur das Produkt von Grund auf neu gestaltet werden.

02. OJO möchte kein einzelnes Bild generieren, sondern ein Designteam simulieren

Das erste Konzept von OJO war nicht das heutige Agent Team.

In der frühen Phase des Startup suchte das Team zwei freiberufliche Designer für die Landing Page: Einer war gut in der Umsetzung, wollte aber nicht viel Zeit investieren, um die Marke zu verstehen. Der andere konnte über die Marke diskutieren, aber die visuelle Umsetzung entsprach nicht den Erwartungen. Viele Arbeiten landeten am Ende wieder in den Händen des Teams.

Durch diese Erfahrung verstand Zhang Qizhi die Designzusammenarbeit neu: Bei langkettigen Aufgaben fehlt es oft nicht an einem „Alleskönner-Designer“, sondern an einem Kooperationsmechanismus, der Marke, Visualität, Animation und Systemdesign je nach Aufgabe neu kombinieren kann.

Daher verwarf das Team die Idee, dass „ein einziger Agent den gesamten Prozess durchläuft“. Der Grund ist einfach: Es gibt keine einheitliche Antwort für Ästhetik, und Nutzer arbeiten auch nicht alle auf demselben Weg.

Einige Nutzer möchten von der Produktstrategie und Seitenstruktur bis zum hochauflösenden Prototyp gelangen, andere benötigen nur ein diskutierbares dynamisches Konzept und kehren danach zu Figma oder Code-Tools zurück. Hinter Typografie, Schriftarten, Animationen und Markenerzählungen stehen wiederum unterschiedliche fachliche Fähigkeiten. Wenn man einen Prozess im Voraus festschreibt, schränkt man die Nutzer nur ein.

Daher hat OJO nicht das Produktmodell übernommen, bei dem ein einziger Agent den gesamten Prozess durchläuft, sondern die Designaufgabe in kombinierbare Agent Teams und Skills unterteilt.

Die Einschränkung eines einzelnen Agenten liegt darin, dass er das Design leicht zu einer einzigen Frage und Antwort komprimieren kann. Aber echtes Design entsteht nicht in einem einzigen Generationsschritt: Jemand definiert das Problem und die Produktziele, jemand bestimmt die visuelle Richtung, jemand bearbeitet Typografie und Animationen, und jemand prüft ständig, ob das Ergebnis von den ursprünglichen Anforderungen abweicht. Das Designergebnis ergibt sich oft aus den Beurteilungen und Korrekturen verschiedener Rollen im Rahmen einer kontinuierlichen Zusammenarbeit.

OJO versucht, diesen Prozess mit Agent Team zu simulieren. Nutzer können Agenten auswählen, die unterschiedliche Aufgaben übernehmen, und ihnen über Skills spezifischere Fähigkeiten verleihen. Der Haupt-Agent ist dafür verantwortlich, zu beurteilen, wann welche Skill oder welches Tool aufgerufen wird, und den Kontext zwischen verschiedenen Phasen zu übertragen. Es soll erreicht werden, dass KI nicht nur direkt eine Antwort generiert, sondern einen gesamten Designprozess organisieren und vorantreiben kann.

Bildquelle: Offizielle Website von OJO

Diese Agenten werden als leicht verständliche Rollen wie Steve Jobs, Van Gogh und Leonardo da Vinci gestaltet. Die Rollennamen senken die Verständnisschwelle für Nutzer, aber das Produkt muss tatsächlich noch beweisen, ob die Arbeitsmethoden hinter den Rollen wesentliche Unterschiede aufweisen und ob die Zusammenarbeit mehrerer Rollen geeignetere und stabilere Ergebnisse liefern kann als ein einziger allgemeiner Agent.

In Bezug auf ästhetische Probleme vermeidet OJO derzeit offensichtliche Verzerrungen durch voreingestellte Skills und Tools und überlässt die höherstufige Stilbeurteilung den Nutzern. Zum Beispiel vermeidet das Team die unterschiedslose Verwendung von blau-violetten Farbverläufen oder hochgesättigten Farbschemata, aber der Schlüssel liegt nicht darin, einen bestimmten Stil zu verbieten, sondern zu beurteilen, ob er zur Marke, zu den Nutzern und zum Nutzungsszenario passt. Zukünftig plant das Team, das Agent Team und die Skills weiter zu öffnen, sodass verschiedene Designerfahrungen gespeichert, kombiniert und wiederverwendet werden können.

OJO zielt derzeit auch nicht auf professionelle Designer ab. Zhang Qizhi ist der Meinung: „Die Leute, die echten Designbedarf haben, sind keine Designer.“ Designer sind oft die Personen, die von vorgelagerten Rollen wie Produktmanagern, Marketingmitarbeitern und Gründern hinzugezogen werden, um Probleme zu lösen. Wenn man bei professionellen Designern ansetzt, landet das Produkt leicht bei reinen Effizienzoptimierungen. OJO möchte hingegen diejenigen bedienen, die einen starken Designbedarf haben, aber kein vollständiges professionelles Team zur Verfügung stellen können.

In der Betaphase erstellte ein Content-Betreiber ohne Designerfahrung in etwa einer Stunde eine persönliche Website mit komplexen Animationen. Ein anderer Nutzer wollte ursprünglich mit Codex direkt Frontend-Code schreiben, aber die Seite wich nach mehreren Überarbeitungen immer weiter von den Erwartungen ab. Er importierte das vorhandene Ergebnis in OJO, um die Visualität anzupassen, und kehrte danach zu Codex zurück, um den Code fertigzustellen. Das Projekt steht jetzt kurz vor der Veröffentlichung.

Diese Fälle zeigen, was OJO erreichen möchte: Die Verluste unscharfer Ideen zwischen Design und Entwicklung so weit wie möglich zu reduzieren.

Es gibt aber auch Probleme. Häufige Nutzer haben über Betriebsfehler berichtet, und einige konnten die Hauptlinie des Agent Teams nicht sofort verstehen. Das Team hatte zu viele Konzepte in die Oberfläche eingebaut, was zu Unübersichtlichkeit führte. Danach begann es, Elemente zu streichen, um das Gefühl zu verstärken, dass „ein Team für Sie arbeitet“.

Ein Produkt, das Probleme des Designausdrucks löst, muss zuerst dafür sorgen, dass Nutzer es selbst verstehen.

03. Der Wettbewerb um KI-Design-Tools nähert sich demselben Endpunkt

Als OJO auf den Markt kam, waren KI-Design-Tools nicht mehr selten.

Dieser Markt nähert sich demselben Endpunkt auf zwei Wegen: Der eine geht von Designplattformen aus und erstreckt sich auf Prototypen, Code und Bereitstellung. Der andere geht von Coding-Agenten aus und ergänzt um Fähigkeiten zur visuellen Bearbeitung, zu Designsystemen und zur Zusammenarbeit.

Produkte wie Figma, Google Stitch, Ardot von Tencent und Lovable erweitern alle ihre Grenzen. Figma Make und Stitch haben die Phase der interaktiven Prototypen erreicht. Ardot verbindet Designdokumente über MCP mit Tools wie Claude Code, Cursor und Codex. Lovable fügt neben ausführbaren Anwendungen weiterhin Funktionen zur visuellen Bearbeitung, zu Designsystemen, zu Skills oder zu mehreren Agenten hinzu.

Die Endpunkte der beiden Wege nähern sich immer mehr an: Die eine Seite wandelt Design in Code um, die andere Seite stattet Code mit Designfähigkeiten aus.

Das bedeutet, dass die „Fähigkeit, Seiten zu generieren“ kaum ein langfristiger Wettbewerbsvorteil sein kann. Es lohnt sich vielmehr zu vergleichen, ob das Produkt vorhandene Marken, Designsysteme, Codebibliotheken und historische Entscheidungen verstehen kann, ob es unter mehreren plausiblen Konzepten die Aufgabe am besten passende Beurteilung treffen kann und ob es in der langen Kette von Produktdefinition über Visualität, Code bis zur Veröffentlichung die vorherigen Entscheidungen so wenig wie möglich verliert.

Das ist auch der Unterschied zwischen KI-Design und KI-Codierung. Die Qualität von Code lässt sich eher nach „richtig oder falsch“ beurteilen, die Qualität von Design hingegen eher nach „passend oder unpassend“. Ersteres kann leichter von grundlegenden Modellen direkt verarbeitet werden, Letzteres hängt stärker von kontinuierlichen Beurteilungen in Szenarien, Marken und Zusammenarbeit ab.

Zhang Qizhi versteht diese Veränderung aber nicht so, dass Modelle die Anwendungen „verschlingen“. Ihrer Meinung nach wird nicht eine einzelne Produktform umgestaltet, sondern die ursprüngliche Industriestruktur der Branche. Nehmen wir Figma als Beispiel: Es hat in den letzten zehn Jahren der Koordinationslogik großer Internetunternehmen gedient: Design liegt zwischen Produkt, Entwicklung und anderen Phasen, Designdokumente sind sowohl Kreativwerkzeug als auch gemeinsame Sprache des Teams zur Informationsübertragung und Festlegung von Entscheidungen. Nachdem Modellfähigkeiten in die Arbeitsabläufe eingezogen sind, verändern sich zuerst diese Beziehungen zwischen den Phasen: Mehr Rollen können früher Prototypen erstellen und an visuellen Beurteilungen teilnehmen, und die bisher nach Funktionen getrennten Grenzen und Organisationsweisen lockern sich ebenfalls.

Das bedeutet nicht, dass Anwendungen verschwinden werden. Zhang Qizhi vergleicht Modelle mit Eisenbahnen: Die Infrastruktur bestimmt die Geschwindigkeit und die erreichbaren Ziele, aber sie entscheidet nicht über das Ziel, organisiert keine Routen und erbringt keine Dienstleistungen. Je leistungsfähiger das Modell ist