App-Prototyp mit KI erstellen: klickbar statt nur Mockup

App-Prototyp mit KI erstellen: klickbar statt nur Mockup

Ein KI-Builder kann einen App-Prototyp bauen, der nicht nur wie eine App aussieht, sondern funktioniert: Buttons reagieren, Bildschirme wechseln, Formulare behalten, was eingetippt wurde. Der Prototyp öffnet sich über einen Link auf jedem Handy, Sie können ihn also noch heute echten Menschen in die Hand geben. Hier steht, worin er sich vom Mockup unterscheidet, wie man ihn beschreibt und wo seine Grenzen liegen.

Was unterscheidet einen Prototyp von Design und Mockup?

Unter "App-Prototyp" verstehen Leute drei verschiedene Dinge. Es hilft, früh zu klären, welches Sie brauchen.

Suchanfragen wie "App-Design mit KI" meinen meist die erste Zeile. Ein Mockup beantwortet aber nur, ob das Aussehen gefällt. Ob Menschen verstehen, was zu tun ist, zeigt nur etwas, das sie antippen können. Ein KI-Builder, der Code schreibt, landet direkt in der dritten Zeile, und das kostet nicht mehr als Bildschirme von Hand zu zeichnen.

Wozu überhaupt ein Prototyp?

Um eine Idee zu prüfen, bevor man Entwickler bezahlt. Die typischen Fälle:

Sie wollen wissen, ob Menschen das benutzen würden. Fünf Leute, die auf dem eigenen Handy herumtippen, sagen mehr als jede Präsentation.

Sie müssen die Idee einem Mitgründer, Investor oder Auftraggeber zeigen. Ein Link zum Ausprobieren überzeugt mehr als Folien mit Screenshots.

Sie wollen eine Entwicklung beauftragen. Der Prototyp wird zum besten Lastenheft: Die Entwicklerin sieht Bildschirme, Übergänge und Formularfelder statt einer Nacherzählung im Dokument.

Was gehört in den Prompt?

Der klassische Fehler ist, die ganze künftige App mit allen Funktionen zu beschreiben. Ein Prototyp prüft eine Hypothese, also beschreiben Sie einen Hauptablauf.

Bewährt hat sich ein Briefing in fünf Teilen:

1. Wer der Nutzer ist. "Inhaberin einer kleinen Bäckerei."
2. Die Hauptaufgabe. "Vorbestellungen für morgen annehmen und sehen, wie viel wovon zu backen ist."
3. Bildschirme in Reihenfolge. "Produktliste, Warenkorb, Bestellung abschließen, Inhaberansicht mit Übersicht."
4. Welche Daten eingegeben werden und wo sie erscheinen. "Kunde gibt Name, Telefon und Abholzeit ein, die Inhaberin sieht die Bestellungen für morgen."
5. Wie es auf dem Handy aussieht. "Mobiles Layout, Tab-Leiste unten, große Buttons."

Der letzte Punkt ist wichtiger, als er wirkt. Fehlt er, kann der Prototyp für einen breiten Desktop-Bildschirm gebaut werden, während Sie ihn vor allem auf dem Handy zeigen. Allgemeine Tipps zum Briefing stehen im Beitrag über einen guten Prompt.

Schritt für Schritt zum Prototyp

1. Öffnen Sie zugo.dev und melden Sie sich mit Google, GitHub oder per E-Mail an. Die Start-Credits kommen sofort, eine Karte ist nicht nötig.
2. Schicken Sie das Briefing nach dem Schema oben.
3. Warten Sie auf den Build. Der Prototyp wird in einem Browser gestartet und geprüft, bevor er zu Ihnen kommt.
4. Gehen Sie den Hauptablauf selbst durch, wie ein Nutzer. Notieren Sie, wo Sie hängen bleiben.
5. Ändern Sie in normalen Worten: "Bestätigungsbildschirm nach der Bestellung ergänzen", "leeren Zustand zeigen, wenn es keine Bestellungen gibt".
6. Veröffentlichen Sie und schicken Sie den Link an die Leute, mit denen Sie die Idee testen.

Schritt fünf verdient Aufmerksamkeit. Leere Zustände, Eingabefehler und lange Produktnamen stehen fast nie im ersten Briefing, und genau dort bleiben echte Nutzer hängen.

Wie testet man den Prototyp mit Menschen?

Den Link zu verschicken reicht nicht, man muss ihn richtig zeigen. Geben Sie eine Aufgabe statt einer Führung: nicht "schau mal, was ich gebaut habe", sondern "bestell dir zwei Croissants für morgen um neun". Dann schweigen Sie und schauen zu. Das Wertvollste passiert in den Sekunden, in denen jemand einen Button sucht und nicht findet. Notieren Sie Handlungen statt Meinungen: "zweimal aufs Produktfoto getippt, weil er dort die Beschreibung erwartet hat" ist eine fertige Änderung für die nächste Runde. Fünf Personen genügen meist, um die Hauptprobleme zu sehen.

Wo liegen die Daten des Prototyps?

Hier gibt es eine ehrliche Grenze zwischen dem kostenlosen Start und dem Abo.

Beim kostenlosen Start wird ein Prototyp als einzelne Datei gebaut: Alles reagiert und funktioniert, aber eingegebene Daten bleiben im Browser der Person, die sie eingegeben hat. Um eine Oberfläche zu testen, reicht das, denn jeder Tester geht den Ablauf auf seinem eigenen Gerät durch.

Eine echte Plattform mit Nutzerkonten, gemeinsamer Datenbank und eigenen Seiten entsteht im Pro-Tarif. Dann liegen die Daten in Zugo Cloud, dem eingebauten Backend: Eine Bestellung des Kunden erscheint auf dem Bildschirm der Inhaberin, und Nutzer melden sich per E-Mail-Link ohne Passwort an. Mehr zu Apps mit Datenbank steht im Beitrag kann KI eine App mit Datenbank bauen.

Was kostet ein Prototyp?

Credits werden nur verbraucht, wenn Code geschrieben wird. Laut den Schätzungen auf der Preisseite liegt eine App von Grund auf bei etwa 2.200 Credits, eine mehrseitige Plattform beginnt bei 2.200 Credits, eine Änderung kostet etwa 980. Das sind Mittelwerte aus echten Builds.

Zum Start gibt es einmalig 1.450 Credits ohne Karte: genug für einen Prototyp in einer Datei. Für einen Prototyp mit gemeinsamer Datenbank und mehreren Änderungsrunden brauchen Sie Pro: $25 im Monat mit 20.000 Credits jeden Monat. Neue Mitglieder bekommen den ersten Monat Pro für $5, wenn sie ihn innerhalb von 12 Stunden nach der Registrierung abschließen.

Wird aus dem Prototyp eine richtige App?

Teilweise. Der Prototyp ist eine Web-App: Sie öffnet sich im Browser, lässt sich auf den Startbildschirm legen und reicht für viele Aufgaben lange aus. Ein Paket für Google Play oder den App Store entsteht daraus nicht von selbst. Dieser Weg ist im Beitrag Android-App mit KI erstellen beschrieben.

Bestätigt der Prototyp die Idee, gibt es zwei Wege. Sie verbessern ihn mit Änderungen weiter, bis er ein funktionierendes Produkt ist. Oder Sie exportieren im Pro-Tarif den Code nach GitHub und geben ihn einem Entwickler als Ausgangspunkt. Im zweiten Fall bekommt der Entwickler funktionierenden Code statt eines Bildes, und das spart die ersten Wochen.

Was sollte man von einem Prototyp nicht erwarten?

Er testet keine Last. Wenn Tausende Menschen die App gleichzeitig nutzen sollen, ist das ein eigenes Gespräch mit einem Entwickler.

Er ersetzt keine Designerin, wenn die Marke pixelgenau sitzen muss. Der Builder schlägt eine saubere Oberfläche vor, kennt Ihr Corporate Design aber erst, wenn Sie es beschreiben.

Und er sagt nicht, ob Menschen zahlen würden. Ein Prototyp zeigt, ob man versteht, was zu tun ist. Zahlungsbereitschaft prüft man getrennt: mit einer Vorbestellung, einer Warteliste oder einer direkten Frage. Was KI heute noch nicht bauen kann, steht im Beitrag was KI nicht bauen kann.

Kurz gesagt

Ein KI-Builder liefert statt Bildern von Bildschirmen einen funktionierenden Prototyp: Man tippt ihn an, gibt Daten ein und öffnet ihn per Link auf dem Handy. Beschreiben Sie einen Hauptablauf, zählen Sie die Bildschirme in Reihenfolge auf und verlangen Sie ausdrücklich ein mobiles Layout. Kostenlos entsteht ein Prototyp in einer Datei mit Daten im Browser des Testers, eine Plattform mit gemeinsamer Datenbank und Nutzer-Login im Pro-Tarif. Zeigen Sie den Link fünf Menschen aus Ihrer Zielgruppe, und Sie lernen über die Idee mehr als in einem Monat Diskussion.