Eine neue Website ist online. Die Gestaltung sitzt, der Ablauf wurde überarbeitet, das Team ist zufrieden. Uns lässt dann eine Frage nicht los: Ist es für die Menschen, die das alles benutzen, tatsächlich besser geworden?
Als Design Lab wollen wir darauf eine vernünftige Antwort geben können. Ein schöner Entwurf zeigt unsere Absicht. Erst die Nutzung zeigt, wie gut sie trägt. Dafür interessieren uns die Stellen, an denen jemand nicht weiterkommt, etwas anderes erwartet oder einen wichtigen Schritt abbricht.
Aus dieser Frage heraus bauen wir Wayfold. Wir wollen Beobachtungen, Tests und Änderungen so miteinander verbinden, dass nach dem Release weitergearbeitet werden kann. Und wir wollen dafür keine dauerhaften Besucherprofile anlegen.
Vom Abbruch zu einer brauchbaren Frage
Angenommen, eine Website führt Besucher durch einen mehrstufigen Anfrageprozess. Viele beginnen, deutlich weniger kommen am Ende an. Die Abschlusszahl allein sagt uns noch nicht, wo wir ansetzen sollen.
In Wayfold helfen unterschiedliche Sichten bei der Einordnung. Journeys zeigen eingeschlagene Wege. Ein Funnel betrachtet die definierte Abfolge und die Stellen, an denen Menschen sie verlassen. Ein Goal hält fest, welche Zielhandlung wir beobachten wollen. Kampagnen und AI-Traffic helfen, den Zugang zur Website einzuordnen.
Bei unserem Anfrageprozess könnten wir dadurch eine bestimmte Stufe genauer untersuchen. Anschliessend interessieren uns die Interaktionen auf der Oberfläche. Wayfolds aggregierte Heatmaps zeigen dafür Klicks, Bewegung und Scrolltiefe sowie Hinweise auf Rage Clicks und Dead Clicks. Wiederholte Klicks oder Klicks ohne erkannte Reaktion können uns auf eine Stelle aufmerksam machen, die wir prüfen sollten.
Wir wissen damit noch nicht, warum jemand abgebrochen hat. Aber wir haben eine bessere Frage als «Wie bekommen wir mehr Abschlüsse?». Etwa: Verlangt dieser Schritt eine Angabe, die Besucher gerade gar nicht machen können? Mit einer konkreten Frage lässt sich arbeiten.
Feedback gehört dorthin, wo das Problem auftritt
Jetzt beginnt die gemeinsame Prüfung. Genau an diesem Übergang geht leicht Kontext verloren. Ein Screenshot liegt im Chat, ein Kommentar in einem Ticket, und die Beschreibung des Zustands steckt im Kopf der Person, die das Problem gefunden hat.
Deshalb haben wir einen geschützten Test Mode gebaut. Teams können Pins, Kommentare und interne Issues direkt auf der echten Website erfassen. Die Beobachtung erhält einen Ort. Wer den Ablauf später untersucht, muss ihn nicht erst aus mehreren Nachrichten rekonstruieren.
Im Beispiel könnte das Team die fragliche Eingabe markieren und festhalten, was daran unklar ist. Daraus lässt sich eine konkrete Änderung ableiten: die Frage verständlicher formulieren, ihren Zweck erklären oder sie an einen passenderen Punkt im Ablauf verschieben.
Das reguläre Analytics-Tracking ist währenddessen im Test-Tab deaktiviert. Unsere internen Klicks sollen schliesslich nicht als Verhalten der Besucher in die Auswertung eingehen.
Ein erledigtes Ticket beantwortet unsere Frage noch nicht
Nach der Umsetzung lässt sich das Issue schliessen. Ob die Änderung geholfen hat, ist damit weiterhin offen. Genau diese Verbindung wollen wir erhalten.
Wayfold verknüpft Issues mit ausgelieferten Changes und aggregierten Vorher-nachher-Daten. Für den Anfrageprozess betrachten wir nach dem Release wieder dieselbe Zielhandlung. Die ursprüngliche Beobachtung, die Änderung und die spätere Auswertung bleiben aufeinander bezogen.
Auch Wayfolds eigene Hinweise sollen untersuchbar bleiben. Sie beruhen auf definierten Regeln und nachvollziehbarer Evidenz. Wir wollen sehen können, welche Beobachtung einen Hinweis ausgelöst hat. So lässt sich im Team darüber sprechen, ob er für die aktuelle Frage relevant ist.
Der Vergleich kann zeigen, dass sich die Nutzung verbessert hat. Vielleicht hat sich aber auch wenig verändert. Dann ist die Arbeit nicht wertlos gewesen. Wir müssen unsere Annahme prüfen und verstehen, ob wir die falsche Ursache bearbeitet haben. Das gehört für uns genauso zur Produktarbeit wie ein Ergebnis, über das wir uns freuen.
Wir wollen auch unseren eigenen Erfolg hinterfragen können
Wenn eine Kennzahl nach einem Release steigt, ist die Versuchung gross, sie der eigenen Arbeit zuzuschreiben. Das wäre angenehm. Es wäre nur nicht besonders sorgfältig.
Vielleicht lief gleichzeitig eine neue Kampagne. Vielleicht kamen andere Besucher. Vielleicht war der Vergleichszeitraum zu kurz. Ein Vorher-nachher-Vergleich liefert Hinweise zur Wirkung; er ist allein weder ein randomisierter A/B-Test noch ein Beweis für Kausalität.
Deshalb betrachten wir Herkunft, Zeiträume, Datenmenge und parallele Änderungen mit. Gespräche und beobachtete Nutzertests ergänzen die Auswertung dort, wo wir das Warum verstehen müssen. Unsere Erwartung an Wayfold ist, solche Entscheidungen besser zu begründen. Dazu gehört auch, die Grenzen der eigenen Schlussfolgerung zu sehen.
Wie wenig müssen wir dafür über Menschen wissen?
Diese Frage gehört für uns an den Anfang der Entwicklung. Wayfolds öffentliche Besucheranalyse arbeitet ohne Cookies, Fingerprinting und dauerhafte Besucherprofile. Ereignisse werden innerhalb kurzlebiger anonymer Sessions zusammengeführt. Eine Person über spätere Besuche hinweg wiederzuerkennen gehört nicht zum Modell.
Für die Heatmaps speichern wir keine Screenshots, DOM-Inhalte, Texte, Selektoren oder exakten Cursorverläufe. Die Auswertung zeigt aggregierte Muster. Bewusst erfasste Kommentare im geschützten Test Mode sind davon getrennt. Datensparsamkeit ist hier eine Entscheidung über das Produkt und seine Architektur.
Wayfold verarbeitet selbstverständlich Daten. Der öffentliche Tracker legt aber keine Besucherkennung in Cookies oder dauerhaftem Browser-Speicher ab. Eine ausdrücklich gesetzte Opt-out-Präferenz und die Speicherung im geschützten Test Mode sind davon getrennt.
Die Plattform ist für den Betrieb ohne eigenen Consent-Banner konzipiert. Welche Anforderungen für eine konkrete Website gelten, hängt von ihrer Einbindung, den übrigen Diensten und dem Markt ab.
Wir bauen das Werkzeug, mit dem wir selbst weiterarbeiten wollen
Wayfold ist unser eigenes Produkt. Wir verantworten das Interface, den Tracker, die Erfassung, die Auswertung und den Betrieb. Das zwingt uns, die Verbindung zwischen dem, was wir versprechen, und dem, was das System tut, bis in die Umsetzung zu tragen.
AI hat uns bei Recherche, Konzeptvarianten und Teilen der Entwicklung unterstützt. Die Architektur, die Privacy-Grenzen und der Code wurden von uns geprüft; das Interface und die visuellen Elemente entstanden im Designteam. Wie wir das handhaben, erzählen wir im Beitrag über unsere Arbeit mit AI.
Stand September 2026 ist Wayfold in der Closed Beta. Erste externe Tests fliessen in die Bedienung, Stabilität und Auswertungen ein, während wir den öffentlichen Launch vorbereiten. Wenn du es mit deiner Website testen möchtest, kannst du bei uns einen Beta-Zugang anfragen.
Mit TokenLab arbeiten wir daran, Designentscheidungen konsistent in die Umsetzung zu bringen. Wayfold setzt danach an. Der Release ist ein guter Anlass, sich zu freuen. Die Frage, was dadurch besser geworden ist, wollen wir anschliessend beantworten können.
