PM werden im KI-Zeitalter 10 | High-Fidelity zuerst: Ich habe seit sechs Monaten kein einziges Wireframe mehr gezeichnet
Letzte Woche war ich mit einem befreundeten Designer essen, und er erzählte, seine Gruppe habe den Schritt mit den Wireframes komplett gestrichen. Ich stutzte eine halbe Sekunde — und dann fiel der Groschen: Bei mir ist es genauso. Ich habe später in Figma nachgesehen, und das Board mit dem Namen „Low-Fidelity-Wireframe” habe ich in diesem halben Jahr kein einziges Mal geöffnet.
Nicht, weil ich fortschrittlicher geworden wäre. Sondern weil es nichts mehr bringt, sie zu zeichnen.
Wireframes sind billig, das ist ihr einziger Vorteil
Warum hat man Wireframes damals überhaupt gezeichnet? Weil „es wirklich bauen” zu teuer war.
Eine wirklich klickbare Seite zu bauen — der Designer entwirft, das Frontend setzt um, es gibt Runde um Runde Abstimmung — das dauert mindestens ein, zwei Wochen. So etwas Teures stimmt man natürlich erst mit einer groben Skizze aus grauen Kästen in der großen Richtung ab, bevor man weitergeht — damit man nicht umsonst schuftet. Das Low-Fidelity-Wireframe ist ein billiges Werkzeug zur „frühen Abstimmung”. Billig zu sein ist sein einziger Vorteil.
Heute ist „es wirklich bauen” nicht mehr teuer. Ein Satz, und Lovable, v0, Bolt oder Claude Code geben dir in wenigen Minuten eine Seite, die im Browser wirklich klickbar ist. Das Produktteam von n8n hat den Wireframe-Prozess kurzerhand komplett ersetzt; ein Director bei Delivery Hero hat in einer Stunde von Hand einen Prototypen zusammengebaut, ohne einen Engineer um Hilfe zu bitten. Bis Anfang 2026 hatten laut Branchenberichten 67 % der Designteams KI-Generierungstools in ihren Alltag integriert.
Wenn „eine echte Version bauen” und „eine falsche Version zeichnen” ungefähr gleich lange dauern, gibt es für die falsche Version keinen Grund mehr zu existieren.
Graue Kästen verstecken genau die Stellen, an denen es wirklich schiefgeht
Das Nervigste an Low-Fidelity ist, dass es einen ganzen Raum voller Leute dazu zwingt, sich über graue Kästen zu streiten.
Ich habe diese Erfahrung gemacht. Ein Wireframe liegt auf dem Tisch im Review, und alle starren auf ein Platzhalter-Rechteck und streiten, „ob dieser Button nicht zwei Spalten weiter nach rechts sollte”. Aber das ist ein grauer Kasten — keine echten Daten, kein Ladezustand, keine leere Liste, keine einzige Fehlermeldung. Genau die Stellen, an denen es später kracht, zeigt ein Wireframe kein bisschen. Wenn es dann wirklich gebaut ist, stecken die Probleme alle in genau den Zuständen, die es damals versteckt hat: Bei vielen Daten verrutschen die Zeilen, bei langsamem Netz dreht sich der Spinner bis in alle Ewigkeit, und der Nutzer landet beim ersten Besuch vor einer leeren Fläche und weiß nicht, was er tun soll.
Nach diesem Mal habe ich es verstanden: Statt alle vor einem falschen Bild fantasieren zu lassen, stelle ich lieber gleich das Echte hin und schaue ihm beim Laufen zu.
Ich baue heute direkt eine lauffähige Version
Low-Fidelity überspringen, direkt zu einer lauffähigen High-Fidelity-Version. „High-Fidelity” klingt anspruchsvoll, ist es aber gar nicht — es sind vier Dinge, die ich meist in dieser Reihenfolge angehe (keine Musterlösung, nur mein eigener bequemer Weg):
Erstens: echte Inhalte, kein Lorem ipsum. Platzhaltertext täuscht — ein Bildschirm voll falschem Latein sieht ganz ordentlich aus, aber mit echten langen Überschriften, echten Beträgen, echten Nutzernamen fällt das Layout sofort auf die Nase. Deshalb sage ich der KI direkt und deutlich, worum es geht:
„Bau eine Bestellliste. Nimm realistisch wirkende Daten: deutsche Produktnamen, echte Preisspannen, echte Zeitstempel, kein Lorem ipsum, kein item1/item2. Es muss einen extrem langen Produktnamen darin geben, teste damit, ob das Layout aus den Fugen gerät.”
Zweitens: alle Zustände vollständig. Laden, leer, Fehler, Erfolg — keinen einzigen weglassen. Das ist die Stelle, an der Low-Fidelity am meisten spart und dich am meisten reinlegt. Ich schiebe heute einen Satz nach: „Zeig mir auch, wie die leere Liste aussieht, wie der Ladezustand aussieht, wie ein fehlgeschlagener Request aussieht, ich will die einzeln durchklicken.”
Drittens: wirklich klickbar, nicht nur ein hübscher Screenshot. Man muss hineinklicken, zurückgehen, ein Formular ausfüllen und sehen können, wie es reagiert. Viele Probleme tauchen erst auf, wenn der Finger wirklich draufdrückt.
Viertens: einmal echt an dem Ort durchlaufen, an dem es hingehört. Was aufs Handy gehört, öffne ich auch auf dem Handy, statt es auf dem Rechner nur ungefähr anzuschauen. Ich bin schon mehr als einmal darauf reingefallen: „Auf dem Rechner top, aber auf dem echten Gerät lässt sich der Button nicht treffen.”
Eine Version in Minuten, also mache ich gleich drei, vier Richtungen
Früher war eine Prototyp-Version teuer, also habe ich im Kopf die Optionen erst auf die eine „beste” heruntergekocht, bevor ich loslegte — weil ein Fehler teuer war.
Heute dauert eine Version nur wenige Minuten, und diese Gewohnheit habe ich geändert. Sobald ich klar habe, was gelöst werden soll, lasse ich die KI kurzerhand drei, vier Richtungen auf einmal bauen und stelle sie nebeneinander: eine als Liste, eine als Karten, eine in einem Schritt, eine schrittweise geführt. Nebeneinander in den Browser gestellt und ein bisschen durchgeklickt, wird viel klarer, was sich gut anfühlt und was sich sperrig anfühlt, als jedes Grübeln im Kopf. Erst eine Richtung wählen und dann in die Tiefe gehen ist besser, als von Anfang an auf die eine richtige zu wetten.
Fünf Richtungen an einem Nachmittag ausprobieren — daran war in der Wireframe-Ära nicht zu denken.
Das Einzige, wovor ich durchgehend auf der Hut bin: Lauffähiges High-Fidelity ist zu echt, so echt, dass ich selbst bei der ersten Version denke „das ist es, los geht’s”. Aber es ist nur „klickbar” und noch Lichtjahre von „live gehen” entfernt — dazwischen liegen ein Haufen ungemachter Grenzfälle, Performance, Sicherheit, echte Datenmengen. Diese beiden Dinge habe ich schon mehrfach durcheinandergebracht, und der nächste Teil handelt genau davon.
Ich zwinge mich heute, nach der ersten Version noch zwei weitere zu bauen — nicht weil ich so diszipliniert wäre, sondern weil mich die erste Version schon zu oft reingelegt hat.
Diskussion