+33-9-7266-3068
contact@gdm-pixel.fr
TL;DRWas KI in einer Web-Erfahrung nicht ersetzen kann
Ein Kunde rief uns vor einigen Monaten an. Seine Web-Anwendung — eine Business-Plattform zur Verwaltung seiner Außendienstteams — brach zusammen, sobald die 4G-Verbindung schwächelte. Datenverlust. Nutzerfrustration. Massenhafter Abbruch. Dabei hatte er in ein schönes Design, ein solides Backend und flüssige Animationen investiert.
Was ihm fehlte, war eine Architektur, die für die reale Welt gedacht war.
Die reale Welt ist der Techniker im Keller ohne Signal. Es ist der Außendienstmitarbeiter in einem Funkloch, der trotzdem seinen Auftrag ausfüllen muss. Es ist der Handwerker unterwegs, der nicht warten kann, bis die Seite neu lädt.
Genau dort werden zwei Themen, die selten gemeinsam behandelt werden, untrennbar: die Local-First-Architektur und die menschliche UX-Strategie. Eines ohne das andere produziert eine Anwendung, die im Labor funktioniert, aber im Feld versagt.
Was ist Local-First-Architektur, konkret?
Das Prinzip ist einfach zu erklären, aber strukturell anspruchsvoll umzusetzen.
Eine klassische Anwendung arbeitet im Server-First-Modus: Jede Benutzeraktion löst eine Anfrage an einen entfernten Server aus. Keine Verbindung? Keine Antwort. Der Nutzer wartet, oder schlimmer, verliert seine Daten.
Local-First ist das Gegenteil.
Die Daten liegen zunächst auf dem Gerät des Nutzers. Die Anwendung funktioniert vollständig im Offline-Modus. Die Synchronisation mit dem Server erfolgt im Hintergrund, sobald eine Verbindung verfügbar ist. Und wenn zwei Nutzer dasselbe Datum gleichzeitig ändern? Das System löst den Konflikt automatisch über CRDT-Algorithmen (Conflict-free Replicated Data Type).
Das ist keine neue Technologie. Notion, Linear, Figma — die Tools, die Tech-Teams täglich nutzen — sind auf diesen Prinzipien aufgebaut. Neu ist, dass diese Architektur dank Bibliotheken wie ElectricSQL, PouchDB oder Automerge auch für Standard-Business-Anwendungen zugänglich wird.
Das konkrete Ergebnis für einen Nutzer: Die Anwendung antwortet sofort, auch ohne Verbindung. Änderungen werden lokal gespeichert und synchronisiert, sobald das Netz zurückkommt. Null Datenverlust. Null künstliche Wartezeit.
Für ein KMU, das ein Außendienst-Tool an seine Teams verteilt, ist das der Unterschied zwischen einem Tool, das man nutzt, und einem Tool, das man umgeht. Genau diese Art von Abwägung stellen wir bereits in der Konzeptionsphase eines Website- oder Web-App-Projekts — bevor überhaupt eine Technologie gewählt wird.
Warum dieses Thema jetzt relevant ist und was KI verändert hat
Hier wird es interessant.
In den letzten zwei Jahren haben KI-Tools die Geschwindigkeit der Interface-Produktion dramatisch erhöht. Eine React-Komponente generieren, ein Design-System erstellen, eine App in wenigen Stunden prototypisieren — das ist heute möglich. Wir haben es getan. Wir tun es weiterhin bei GDM-Pixel, und wir machen kein Geheimnis daraus.
Aber diese Beschleunigung hat einen gefährlichen blinden Fleck geschaffen.
Wenn man schnell generiert, generiert man oft Interfaces, die für ideale Bedingungen optimiert sind. Stabile Verbindung, geduldiger Nutzer, saubere Daten, linearer Anwendungsfall. KI produziert, was sie gelernt hat — und sie hat hauptsächlich an Beispielen gelernt, die gut funktionieren, nicht an Grenzfällen.
Das eigentliche Risiko ist nicht, dass KI den Designer oder Entwickler ersetzt. Es ist, dass KI funktionale Mittelmäßigkeit normalisiert, indem sie sie ästhetisch akzeptabel macht.
Ein schönes Interface, das abstürzt, wenn das Netz schwächelt, ist ein Interface, das seine Aufgabe verfehlt hat.
“Design ist nicht nur, wie etwas aussieht und sich anfühlt. Design ist, wie es funktioniert.” — Steve Jobs
Dieses Zitat war nie so treffend wie heute. Weil KI darin glänzt, Dinge zu produzieren, die zu funktionieren scheinen. Menschliches Handwerk bedeutet, Dinge zu produzieren, die wirklich funktionieren, unter realen Nutzungsbedingungen.
Die UX-Strategie als Schutzwall gegen KI-Commoditisierung
UX — User Experience — wird oft auf ihre visuelle Dimension reduziert. Schöne Farben, gute Typografie, gepflegte Animationen. Das ist notwendig, aber es ist nur die Spitze des Eisbergs.
Eine echte UX-Strategie ist ein Forschungs- und Entscheidungsprozess, der Fragen beantwortet, die KI nicht von sich aus stellt:
- Unter welchen physischen Bedingungen wird der Nutzer dieses Tool verwenden?
- Wie hoch ist sein Stresslevel im Moment der Interaktion?
- Was passiert, wenn ein Schritt fehlschlägt? Ist es wiederherstellbar?
- Wie lange kann er warten, bevor er abbricht?
Diese Fragen sind nicht abstrakt. Sie definieren reale technische Anforderungen. Und genau dort konvergieren Local-First und UX — eine Konvergenz, die wir in unserem Artikel über die Ingenieurskunst hinter maßgeschneiderten Web-Interfaces detaillieren.
Nehmen wir ein konkretes Beispiel aus unserer Praxis. Wir haben ein lokales Lieferunternehmen bei der Überarbeitung seines Tourenplanungstools begleitet. Die Fahrer nutzten die Anwendung von ihrem Telefon aus, in Bewegung, oft in Gebieten mit schlechter Netzabdeckung.
Die erste Version — schnell mit einem modernen Stack generiert — war unter normalen Bedingungen funktional. Sie stürzte ab, sobald das Signal abnahm. Die Fahrer verloren ihre Lieferscheine. Der Kundenservice war überwältigt.
Die Überarbeitung erzwang drei strukturelle Entscheidungen:
Entscheidung 1 — Lokale Architektur zuerst. Alle Tourndaten werden zu Beginn des Tages heruntergeladen. Änderungen werden lokal gespeichert und bei jeder Wiederverbindung synchronisiert.
Entscheidung 2 — Explizite Offline-Anzeige. Wenn der Offline-Modus aktiviert wird, signalisiert das Interface dies klar, ohne den Nutzer zu blockieren. Er arbeitet weiter; die App holt das Versäumte nach.
Entscheidung 3 — Einhand-Bedienung und großflächige Gesten. Die Fahrer haben die Hände voll. Jede kritische Aktion ist mit dem Daumen erreichbar, ohne präzise Gesten zu erfordern.
Ergebnis: Abbruchrate um 60 % reduziert. Kundenserviceanrufe durch 3 geteilt. Und Fahrer, die nicht mehr im Büro anrufen, um zu melden, dass “die App nicht funktioniert”.
Das ist kein Zauber. Es ist rigorose UX, angewandt auf reale Anforderungen, gekoppelt mit einer Architektur, die keine idealen Bedingungen voraussetzt.
Was sich in der Art, ein Web-Projekt zu bauen, ändert
Diese beiden Dimensionen von Anfang an zu integrieren verändert grundlegend die Art, wie ein Projekt konzipiert wird.
Die Frage lautet nicht mehr “Welche Technologie für dieses Projekt?”, sondern “Unter welchen realen Bedingungen wird dieses Tool genutzt?”
Diese Perspektivverschiebung hat praktische Konsequenzen für jede Projektphase.
In der Discovery-Phase
Bevor Figma geöffnet oder eine einzige Komponente generiert wird, kartieren wir die Nutzungsbedingungen. Wer sind die Nutzer? Wo befinden sie sich physisch? Wie hoch ist ihr technisches Know-how? Haben sie eine zuverlässige Verbindung? Diese Forschungsphase — auch wenn sie kurz und leichtgewichtig ist — verhindert kostspielige Überarbeitungen auf halbem Weg.
In der Architekturphase
Wir entscheiden explizit über das Datenmodell: Was muss absolut offline funktionieren? Was kann auf eine Verbindung warten? Diese Entscheidung strukturiert alles andere — die Framework-Wahl, das State-Management, die Cache-Strategie.
In der Design-Phase
Jeder Interface-Zustand muss gestaltet werden: Normalzustand, Ladezustand, Fehlerzustand, Offline-Zustand. Das ist kein Detail — das ist, was der Nutzer sieht, wenn etwas nicht wie erwartet läuft. Und genau dort gewinnt oder verliert eine Anwendung das Vertrauen ihrer Nutzer.
In der Testphase
Wir testen unter degradierten Bedingungen. Netzwerk-Throttling, simulierte Ausfälle, Wiederverbindungen. Wenn die Anwendung diese Tests nicht besteht, ist sie nicht bereit für den Einsatz.
Drei konkrete Entscheidungen, um Ihren Ansatz zu transformieren
Keine erschöpfende Liste. Drei Entscheidungen, die wirklich etwas verändern.
Erste Entscheidung: Reale Nutzungsbedingungen auditieren, nicht ideale.
Verbringen Sie vor Ihrem nächsten Projekt zwei Stunden mit echten Nutzern in ihrer realen Umgebung. Nicht im Besprechungsraum mit Glasfaser-Anschluss. Im Feld, mit ihren Anforderungen. Was Sie entdecken werden, wird Ihre technischen Prioritäten wahrscheinlich verschieben.
Zweite Entscheidung: Fehlerzustände vor Normalzuständen designen.
Das ist kontraintuitiv. Aber ein Interface, das Fehler gut handhabt, ist robuster als eines, das unter perfekten Bedingungen glänzt. Beginnen Sie mit “Was passiert, wenn das fehlschlägt?” und bauen Sie von dort aus.
Dritte Entscheidung: KI zum Beschleunigen nutzen, nicht zum Entscheiden.
KI generiert schnell. Sie trifft keine guten Entscheidungen über funktionale Anforderungen. Nutzen Sie sie, um Komponenten, Varianten und Texte zu produzieren — aber behalten Sie die Kontrolle über Architekturentscheidungen und UX-Entscheidungen. Dort ist der menschliche Wert unersetzbar, ein Punkt, den wir in unserer Reflexion über Design im KI-Zeitalter zwischen Transparenz und Zugänglichkeit vertiefen.
“Technologie muss dem Anwendungsfall dienen, nicht umgekehrt. Eine robuste Anwendung setzt nichts über die Bedingungen des Nutzers voraus.” — Prinzip, das wir bei GDM-Pixel seit unserer Prozessüberarbeitung 2023 anwenden.
Was es kostet, nicht darüber nachzudenken
Die Frage, die wir oft vermeiden zu stellen: Was kostet eine Anwendung, die unter realen Bedingungen nicht funktioniert?
Nicht in Bezug auf die technische Überarbeitung — das sieht jeder. Sondern in Bezug auf verlorenes Vertrauen, umgangene Geschäftsprozesse, gescheiterte Adoption. Eine Anwendung, die Außendienstteams nicht nutzen, weil sie “zu oft abstürzt” — das ist eine Investition mit null ROI, unabhängig von der Code-Qualität unter idealen Bedingungen.
In ganz Frankreich erwarten KMUs, die in digitale Tools investieren, eine messbare Rendite. Kein schönes Dashboard, das nur im Büro funktioniert.
Local-First-Architektur und rigorose UX-Strategie sind keine Zusatzkosten. Sie sind Absicherungen gegen das Scheitern im Einsatz.
Weiterführende Ressourcen
Wenn Ihr Projekt Außendienstnutzer, Gebiete mit schlechter Konnektivität oder kritische Geschäftsprozesse umfasst — die Frage der Local-First-Architektur verdient es, bereits in der Konzeptionsphase gestellt zu werden, nicht auf halbem Weg.
Bei GDM-Pixel haben wir diese Überlegung in unseren Discovery-Prozess integriert. Es ist nicht systematisch — manche Projekte brauchen es nicht. Aber wenn der Bedarf besteht, ihn nicht von Anfang an anzusprechen kostet immer mehr, als ihn von Beginn an zu behandeln.
Haben Sie ein Web-Projekt oder eine Business-Anwendung zu bauen? Lassen Sie uns über Ihre realen Anforderungen sprechen, bevor wir über Technologie reden. Dreißig Minuten ehrliche Konzeption sind mehr wert als drei Monate Überarbeitung.
Und wenn Sie das Local-First-Thema vertiefen möchten, sind die Ressourcen von localfirstweb.com ein guter Ausgangspunkt — die Community dokumentiert die Patterns und Tools, die diesen Ansatz in der Produktion wirklich zum Laufen bringen.
Soziale Netzwerke 
Mit KI analysieren 
