Web3 UX — Warum die Adoption stockt und was wir dagegen tun

Vor ein paar Wochen saß ich bei einem User-Test neben einer Testperson — nennen wir sie Sabine, 34, Projektmanagerin, technisch versiert, nutzt Online-Banking und diverse SaaS-Tools täglich. Die Aufgabe: Verbinden Sie Ihre Wallet mit unserer dApp und stimmen Sie über einen Governance-Proposal ab. Sabine hatte MetaMask bereits installiert. Sie klickte auf „Connect Wallet“. Es passierte — nichts. Kein Pop-up, kein Hinweis, keine Fehlermeldung. Nach zehn Sekunden Stille fragte sie: „Ist das kaputt?“

Es war nicht kaputt. MetaMask hatte das Pop-up geöffnet, aber es war hinter dem Browserfenster verschwunden. Ein Klassiker, den jeder Web3-Entwickler kennt — und den kein normaler Nutzer je herausfinden würde. Sabine brauchte meine Hilfe, um das Pop-up zu finden. Danach sollte sie eine Transaktion signieren. Die Wallet zeigte ihr eine Reihe von Hex-Werten und fragte nach Bestätigung. Sie schaute mich an und sagte: „Was genau bestätige ich hier eigentlich?“

Gute Frage. Und eine, die wir als Branche beantworten müssen, wenn Web3 jemals über die Nische hinauskommen soll.

Das Wallet-Problem

Die Wallet ist das Tor zu Web3 — und gleichzeitig die größte Einstiegshürde. Für Menschen, die an „Login mit Google“ oder „Anmelden mit E-Mail“ gewöhnt sind, ist das Konzept einer Browser-Extension, die als Identität, Zahlungsmittel und Schlüsselbund gleichzeitig fungiert, schlicht überfordernd. Dazu kommen die Seed Phrase (12 oder 24 Wörter, die man sicher aufbewahren muss, aber nicht in einer Cloud speichern soll — wo dann?), die Netzwerkauswahl (Mainnet? Goerli? Polygon? Warum muss ich das wissen?) und die Tatsache, dass ein falscher Klick irreversibel sein kann.

In unserer Erfahrung scheitern etwa 30% der Erstnutzenden bereits an der Wallet-Verbindung. Nicht, weil sie dumm wären — sondern weil die UX es ihnen nicht leicht macht. Das ist kein Nutzerproblem. Das ist ein Designproblem.

Gas Fees: Unsichtbare Kosten, unverständliche Logik

Stellen Sie sich vor, Sie wollen online etwas kaufen. Sie legen den Artikel in den Warenkorb, gehen zur Kasse — und dort steht: „Versandkosten: zwischen 0,50 Euro und 47 Euro, abhängig davon, wie viele andere Leute gerade etwas kaufen.“ Das ist im Wesentlichen die Gas-Fee-Experience auf Ethereum. Und es wird noch schlimmer: Wenn die Transaktion fehlschlägt (was durchaus vorkommt), zahlen Sie die Gas Fee trotzdem. Versuchen Sie, das jemandem zu erklären, der es gewohnt ist, dass fehlgeschlagene Überweisungen kostenlos sind.

Layer-2-Lösungen wie Arbitrum und Optimism haben die Gas-Kosten drastisch gesenkt — auf wenige Cent pro Transaktion. Aber die UX um Gas Fees herum ist immer noch verwirrend. Nutzende müssen verstehen, dass sie ETH auf dem richtigen Netzwerk brauchen, um Gas zu bezahlen. Sie müssen ihre Wallet auf das richtige Netzwerk umschalten. Und sie müssen akzeptieren, dass der Preis einer Transaktion variabel ist — ein Konzept, das es im Web2 nicht gibt.

Fehlermeldungen aus der Hölle

Mein persönlicher Favorit unter den Web3-UX-Katastrophen sind die Fehlermeldungen. Wenn eine Transaktion fehlschlägt, sieht die Nutzerin Folgendes: Error: execution reverted: ERC20: transfer amount exceeds balance (0x08c379a0...). Das ist eine technisch korrekte Fehlermeldung. Für einen Entwickler ist sie sogar hilfreich. Für Sabine ist sie Kauderwelsch.

Das Problem ist strukturell: Smart Contracts geben Fehlermeldungen in einem Format zurück, das für Maschinen gedacht ist, nicht für Menschen. Die dApp-Ebene könnte diese Fehler abfangen und in verständliche Nachrichten übersetzen — aber das erfordert Aufwand, und viele Projekte investieren ihn nicht. Das Ergebnis: Nutzende stehen vor kryptischen Hex-Werten und fühlen sich hilflos.

Das fehlende Onboarding

Die meisten Web3-Anwendungen haben kein Onboarding. Sie setzen voraus, dass Nutzende bereits wissen, was eine Wallet ist, wie Gas Fees funktionieren, was ein Token-Approval bedeutet und warum eine Transaktion manchmal Minuten dauert. Das ist, als würde eine Banking-App voraussetzen, dass Nutzende die Funktionsweise von SWIFT-Überweisungen verstehen.

In der Web2-Welt ist gutes Onboarding längst Standard. Neue Features werden mit Tooltips erklärt, komplexe Prozesse werden in Schritte aufgeteilt, und wenn etwas schiefgeht, gibt es verständliche Fehlermeldungen und klare nächste Schritte. Im Web3 werden Nutzende dagegen oft ins kalte Wasser geworfen — und wir wundern uns dann, dass sie nicht schwimmen.

Was wir dagegen tun

Bei Just Tech Solutions haben wir einige Prinzipien entwickelt, die unsere Web3-Frontends leiten. Sie sind nicht revolutionär — aber sie machen einen spürbaren Unterschied.

Wallet-Abstraktion wo möglich

Nicht jede Interaktion erfordert eine Wallet-Verbindung. Leseoperationen — also das Anzeigen von Proposals, Treasury-Ständen oder Voting-Ergebnissen — funktionieren ohne Wallet. Wir zeigen diese Informationen zuerst und fordern die Wallet-Verbindung erst dann an, wenn sie wirklich nötig ist (zum Beispiel zum Abstimmen). Das senkt die Einstiegshürde erheblich.

Menschliche Fehlermeldungen

Wir fangen Contract-Fehler ab und übersetzen sie. Aus ERC20: transfer amount exceeds balance wird: „Sie haben nicht genug Tokens für diese Transaktion. Ihr aktuelles Guthaben beträgt X.“ Aus execution reverted wird: „Die Transaktion konnte nicht ausgeführt werden. Möglicher Grund: [kontextbasierte Erklärung].“ Das erfordert Mehraufwand bei der Entwicklung, aber es ist der Unterschied zwischen einer Anwendung, die Nutzende frustriert, und einer, die ihnen hilft.

Progressive Disclosure

Wir zeigen technische Details erst, wenn Nutzende sie sehen wollen. Die Standard-Ansicht einer Transaktion zeigt: „Sie stimmen mit Ja für Proposal #42: Budget für Q3 erhöhen.“ Die Details (Contract-Adresse, Funktionssignatur, Parameter) sind hinter einem Aufklappmenü versteckt — sichtbar für Power User, unsichtbar für alle anderen.

Gas-Fee-Schätzungen in Euro

Niemand weiß instinktiv, was 0,0003 ETH sind. Wir zeigen Gas-Kosten in der lokalen Währung an und geben eine klare Einordnung: „Geschätzte Transaktionskosten: ~0,12 Euro“. Das ist eine simple Änderung, die einen enormen Unterschied für die Verständlichkeit macht.

Die strukturelle Herausforderung

All diese Maßnahmen helfen — aber sie behandeln Symptome, nicht die Ursache. Das fundamentale Problem ist, dass Web3 eine neue Technologieschicht über das Internet legt und erwartet, dass Nutzende diese Schicht verstehen. Das Web2 hat das nicht getan. Niemand muss HTTP verstehen, um eine Website zu besuchen. Niemand muss wissen, was TLS ist, um Online-Banking zu nutzen. Die Komplexität wird abstrahiert.

Web3 muss denselben Weg gehen. Die Blockchain, die Transaktionen, die Gas Fees — all das sollte für Endnutzende unsichtbar sein. Die gute Nachricht: Account Abstraction (ERC-4337) und verwandte Standards gehen genau in diese Richtung. Sie ermöglichen Wallets, die sich wie normale Accounts verhalten: Login mit E-Mail, Gas-Sponsoring durch die Anwendung, automatische Netzwerkauswahl. Wir experimentieren bereits mit diesen Technologien und sind optimistisch, dass sie die UX-Landschaft im Web3 grundlegend verändern werden.

Fazit

Sabine hat den User-Test am Ende erfolgreich abgeschlossen — mit meiner Hilfe. Aber sie hätte es allein schaffen müssen. Solange Web3-Anwendungen die Hilfe eines Entwicklers erfordern, um grundlegende Aufgaben zu erledigen, werden wir keine breite Adoption sehen. Die Technologie ist bereit. Die UX ist es nicht. Und das ist ein Problem, das wir als Entwicklerinnen und Entwickler lösen können — und müssen.