Einen funktionierenden App-Prototyp mit KI erstellen und Menschen vorlegen

Warum ein funktionierender Prototyp mehr verrät als ein Mockup

Statische Screens testen, ob Menschen das Aussehen mögen. Ob sie damit umgehen können, testen sie selten, denn die Testperson muss sich vorstellen, was nach jedem Tippen passiert, und wer die Sitzung leitet, erzählt am Ende das Produkt nach. Ein klickbarer App-Prototyp, der wirklich reagiert, macht dieses Erzählen überflüssig. Die Testperson tippt in ein echtes Feld, sieht eine echte Summe sich ändern und bekommt einen echten leeren Zustand, wenn sie den letzten Eintrag löscht. Ihre Verwirrung betrifft dann Ihr Design, nicht die Lücken des Prototyps.

Auch die Fragen, die Sie stellen können, ändern sich. Bei einem Mockup fragen Sie „Würden Sie das nutzen?“, und die Antworten fallen höflich aus. Bei etwas, das funktioniert, können Sie eine Aufgabe stellen („Tragen Sie die Schicht am nächsten Dienstag ein und sehen Sie, was das mit Ihren Wochenstunden macht“) und beobachten, wo jemand zögert.

Legen Sie fest, was der Prototyp beweisen soll

Schreiben Sie, bevor Sie irgendetwas beschreiben, die ein oder zwei Fragen auf, die der Test beantworten soll. So bleibt der Build klein und die Sitzungen fokussiert. Typische Fragen:

• Verständnis: Wissen die Leute innerhalb weniger Sekunden, wofür der Hauptbildschirm da ist?
• Die Kernaufgabe: Können sie die eine Aufgabe, für die das Produkt existiert, ohne Hilfe erledigen?
• Der heikle Moment: Was passiert an dem Rand, bei dem Sie unsicher sind: eine leere Liste, ein Fehler, der rückgängig gemacht werden muss, ein langer Name, der umbricht?
• Bereitschaft: Würden sie nach der Nutzung ihre bisherige Tabelle, ihr Notizbuch oder ihre App dagegen tauschen?

Alles, was diesen Fragen nicht dient, kann wegbleiben oder simuliert werden. Eine Einstellungsseite, die in einer zwanzigminütigen Sitzung niemand öffnet, ist vergeudete Mühe, so leicht sie sich auch erzeugen lässt.

So beschreiben Sie ihn für Anticode

Beschreiben Sie in wenigen Sätzen die Person, die Aufgabe und die Screens, und sagen Sie, wie die Beispieldaten aussehen sollen. Zum Beispiel: „Ein Prototyp einer App zum Schichttausch für ein Café-Team. Screens: der Dienstplan dieser Woche, eine Anfrage zum Tausch einer Schicht und eine Liste offener Tauschanfragen. Acht Beispiel-Mitarbeitende und eine realistische Woche verwenden. Alles als Demodaten kennzeichnen.“ Der Architect antwortet mit einem kurzen Plan (Name, Screens, Stil, Funktionen) und stellt eventuell bis zu drei Fragen, bei denen die Antwort den Build verändert, jeweils mit vorgeschlagenen Antworten zum Antippen.

Wenn Sie Build it wählen, schreibt das Modell die ganze App als ein HTML-Dokument, und Sie können zusehen, wie der Code hereinläuft. Neue App-Builds können außerdem in einem Headless-Browser in Handy- und Laptop-Breite geöffnet, per Screenshot festgehalten und durchgeklickt werden, wobei Fehler zur Behebung zurückgemeldet werden, sofern dieser Prüfdienst verfügbar ist.

Machen Sie die simulierten Teile ehrlich

Anticode-Apps laufen in einer Sandbox ohne Netzwerk, daher wird alles, was normalerweise einen Server bräuchte, innerhalb der Seite simuliert: Andere Nutzer sind Beispielpersonen, „gesendete“ Nachrichten landen in einer lokalen Liste, und ein Anmeldebildschirm akzeptiert jede Eingabe. Die App kennzeichnet das dort, wo es wichtig ist, als Demodaten. Lassen Sie diese Kennzeichnung während der Tests sichtbar. Testpersonen, die glauben, ein echtes System zu benutzen, treffen andere, riskantere Entscheidungen als Testpersonen, die wissen, dass es ein Modell ist, und in dieser Phase wollen Sie die Rückmeldungen der zweiten Art.

Erhalten bleibt alles, was die App im eigenen Browser der Testperson speichert. Wenn jemand drei Einträge hinzufügt, den Tab schließt und morgen zurückkommt, sind die Einträge auf diesem Gerät noch da. Das reicht für eine Tagebuchstudie über eine Woche, solange jede Testperson bei einem Handy oder Laptop bleibt.

Sitzungen durchführen und den Build anpassen

1. Veröffentlichen Sie den Prototyp unter seiner anticode.dev-Adresse und schicken Sie den Testpersonen den Link. Es muss nichts installiert werden.
2. Schicken Sie Stakeholdern stattdessen einen Link zur Kundenfreigabe: Sie können die aktuelle Vorschau ohne Konto öffnen und Kommentare zu einzelnen Abschnitten hinterlassen. Die Links laufen standardmäßig nach 14 Tagen ab, und Sie können sie widerrufen.
3. Bitten Sie nach jeder Runde in einfachen Worten um Änderungen („den Tausch-Button auf jede Schichtkarte setzen“). Die letzten Speicherstände bleiben im Versionsverlauf erhalten (bis zu einer Anzahl, die Ihr Tarif festlegt), sodass Sie Runde eins und Runde drei nebeneinander zeigen oder zurückgehen können.

Was ein Prototyp für einen einzelnen Browser nicht testen kann

Seien Sie sich über die Grenze im Klaren. Ein Prototyp in der Sandbox läuft immer nur auf einem Gerät, daher kann er Folgendes nicht testen:

• Alles zwischen Menschen: echte Benachrichtigungen, geteilte Listen, zwei Testpersonen, die die Änderungen der anderen sehen.
• Echte Anmeldung, Berechtigungen oder Kontowiederherstellung.
• Live-Daten von außen, Zahlungen oder KI-Funktionen innerhalb der App (diese lassen sich nur mit festen Beispielantworten nachahmen).
• Leistung bei echten Datenmengen oder langsamen Netzen.

Wenn die Idee den Test übersteht, ist der Next.js-Export der Schritt hin zu einem echten Produkt. Er gilt für App-Builds und liefert ein Standardprojekt mit App Router in TypeScript, mit Postgres über Prisma, Anmeldung per E-Mail, Rollen für Kunden und Mitarbeitende und einem Admin-Bereich. Das ist ein Ausgangspunkt, den ein Entwickler ausbaut, keine fertige Mehrbenutzer-App, und Sie können ihn in ein GitHub-Repository Ihrer Wahl pushen. Der Ratgeber zum Export nach Next.js erklärt, was enthalten ist. Wenn Sie Mehrbenutzerfunktionen für den Produktivbetrieb ohne eigenen Code brauchen, passt ein No-Code-Werkzeug mit Backend womöglich besser als beides.

Häufige Fragen

Ist das ein KI-Generator für App-Prototypen oder ein Design-Tool?

Es erzeugt funktionierenden Code, keine Frames auf einer Zeichenfläche. Sie erhalten eine echte App im Browser, die sich für Usability-Tests eignet; wenn Ihr Designteam pixelgenaue Designdateien braucht, nutzen Sie zusätzlich ein Design-Tool.

Können Testpersonen ihn auf dem Handy nutzen?

Ja. Die veröffentlichte App ist eine Webseite, die im Handybrowser funktioniert, und alles, was sie speichert, bleibt auf diesem Handy.

Kann ich sehen, was Testpersonen eingegeben haben?

Nicht, was sie in der App gespeichert haben; das bleibt auf ihrem Gerät. Wenn Sie ein Feedback- oder Kontaktformular hinzufügen, erreichen Sie diese Einsendungen per E-Mail und im Dashboard.

Wird aus dem Prototyp die echte App?

Er kann der Ausgangspunkt werden. Der Next.js-Export macht daraus ein Projekt mit Datenbank und Anmeldung, auf dem ein Entwickler aufbauen kann.