A new website is live. The design is in place, the flow has been reworked and the team is happy. One question stays with us: Has it actually become better for the people using it?
As a design lab, we want to be able to give a sensible answer. A beautiful design shows our intention. Actual use shows how well it holds up. We are interested in the places where someone gets stuck, expects something else or abandons an important step.
That question is why we are building Wayfold. We want to connect observations, tests and changes so that the work can continue after release. And we want to do so without creating persistent visitor profiles.
From a drop-off to a useful question
Suppose a website takes visitors through a multi-step enquiry process. Many start; considerably fewer reach the end. The completion count alone does not tell us where to focus.
In Wayfold, different views help us interpret this. Journeys show the paths people take. A funnel examines the defined sequence and where people leave it. A goal records the target action we want to observe. Campaigns and AI traffic help us understand how people reach the website.
For our enquiry process, this could lead us to examine a particular stage. We then become interested in interactions on the interface. Wayfold's aggregated heatmaps show clicks, movement and scroll depth, along with signals for rage clicks and dead clicks. Repeated clicks or clicks without a detected response can draw our attention to a place worth investigating.
We do not yet know why someone left. But we have a better question than “How do we get more completions?”. For example: Does this step request information visitors cannot provide at that moment? A specific question gives us something to work on.
Feedback belongs where the problem occurs
The team review starts here. It is easy to lose context at this transition. A screenshot sits in a chat, a comment lives in a ticket and the description of the state remains in the head of the person who found the problem.
That is why we built a protected Test Mode. Teams can place pins, comments and internal issues directly on the real website. The observation gains a location. Someone examining the flow later does not first have to reconstruct it from several messages.
In our example, the team could mark the input in question and record what is unclear. A specific change can follow: make the wording clearer, explain its purpose or move the question to a more appropriate point in the flow.
Regular analytics tracking is disabled in the test tab during this work. Our internal clicks should not enter the analysis as visitor behaviour.
A completed ticket has not yet answered our question
Once the change is implemented, the issue can be closed. Whether the change helped is still open. This is the connection we want to preserve.
Wayfold links issues with released changes and aggregated before-and-after data. For the enquiry process, we examine the same target action again after release. The original observation, the change and the later assessment remain connected.
Wayfold's own findings should also remain open to examination. They are based on defined rules and traceable evidence. We want to see which observation triggered a finding. The team can then discuss whether it is relevant to the current question.
The comparison may show that usage improved. Or perhaps little changed. That does not make the work worthless. We need to examine our assumption and understand whether we addressed the wrong cause. For us, that belongs to product work just as much as a result we are pleased with.
We want to be able to question our own success too
When a metric rises after a release, it is tempting to credit our own work. That would be pleasant. It would not be particularly careful.
Perhaps a new campaign ran at the same time. Perhaps different visitors arrived. Perhaps the comparison period was too short. A before-and-after comparison provides signals about impact; on its own, it is neither a randomised A/B test nor proof of causality.
We therefore consider traffic sources, periods, data volume and concurrent changes. Conversations and observed user tests complement the analysis where we need to understand why. We expect Wayfold to help us make better-founded decisions. That includes recognising the limits of our own conclusions.
How little do we need to know about people?
For us, this question belongs at the start of development. Wayfold's public visitor analytics works without cookies, fingerprinting or persistent visitor profiles. Events are connected within short-lived anonymous sessions. Recognising someone across later visits is not part of the model.
For heatmaps, we store no screenshots, DOM contents, text, selectors or exact cursor paths. The analysis shows aggregated patterns. Deliberately entered comments in protected Test Mode are separate. Data minimisation is a decision about the product and its architecture.
Wayfold does, of course, process data. But the public tracker does not place a visitor identifier in cookies or persistent browser storage. An explicitly set opt-out preference and storage in protected Test Mode are separate.
The platform is designed to operate without its own consent banner. Requirements for a particular website depend on its integration, other services and market.
We are building the tool we want to keep working with
Wayfold is our own product. We take responsibility for the interface, tracker, collection, analysis and operations. That requires us to carry the connection between what we promise and what the system does all the way through implementation.
AI supported research, concept alternatives and parts of development. We reviewed the architecture, privacy boundaries and code; the design team created the interface and visual elements. Our article about working with AI explains how we handle this.
As of September 2026, Wayfold is in closed beta. Initial external tests inform usability, stability and analysis as we prepare the public launch. If you would like to try it with your website, you can request beta access from us.
With TokenLab, we work on carrying design decisions consistently into implementation. Wayfold picks up from there. A release is a good reason to celebrate. Afterwards, we want to be able to answer what it improved.
