case study voor FareHarbor

Synthetic user research: UX-validatie zonder lab

Een prototype voor FareHarbor. AI-gegenereerde personas die designs toetsen voordat een echte gebruiker ze ziet. Geen vervanging van echt user-onderzoek. Wel een manier om honderd keer sneller te iteraren op de voorkant van je designproces.

Klant

FareHarbor (Booking.com groep)

Rol

Prototype en research-tool

Tooling

AI-gegenereerde personas

Output

Snellere designiteraties

De opdracht

FareHarbor bedient tour operators wereldwijd, van grote themaparken tot kleine boottochtjes. Een designkeuze die werkt voor de ene groep kan voor de andere catastrofaal zijn. Normaal toets je dat met echte gebruikers. Maar real user-research is duur, traag, en laat zich slecht inzetten voor de tien kleine keuzes die je per week maakt.

De vraag: kunnen we een manier bouwen om designs *voordat* ze naar echte gebruikers gaan al tegen een bredere doelgroep te toetsen? Niet om real-user-onderzoek te vervangen, maar om de hypothesen scherper te krijgen voordat we echte mensen vragen.

Onze aanpak

We bouwden een prototype dat synthetische gebruikers genereert op basis van echte demografische en gedrags-patronen uit FareHarbor's bestaande data. Iedere persona heeft een profiel, doelen, frustraties en gedragspatronen. Daarna voer je een design aan en kijkt hoe die persona het zou proberen te gebruiken.

Een typische persona ziet er zo uit:

persona.json

{
  "persona_id": "tour_operator_small_01",
  "profile": {
    "business_type": "kleine boot-excursie in Amsterdam",
    "employees": 3,
    "tech_savvy": "low",
    "primary_device": "mobile",
    "time_per_task": "rushed — between tours"
  },
  "goals": [
    "nieuwe boekingen aannemen zonder aan de telefoon te zitten",
    "groepsplanning in één oogopslag zien"
  ],
  "frustrations": [
    "formulieren met veel velden op mobile",
    "moet tussen meerdere apps wisselen"
  ],
  "test_behavior": {
    "attention_span_seconds": 15,
    "gives_up_after_errors": 2
  }
}

Je geeft deze persona een taak en een design. Het systeem simuleert wat zou gebeuren, en geeft gestructureerde feedback terug:

feedback.json

{
  "persona": "tour_operator_small_01",
  "task": "nieuwe boeking handmatig invoeren",
  "completed": false,
  "time_to_give_up_seconds": 22,
  "friction_points": [
    {
      "step": "groepsgrootte selecteren",
      "issue": "dropdown met 12 opties, te veel scrollen op mobile",
      "severity": "high"
    },
    {
      "step": "bevestigingsscherm",
      "issue": "primaire CTA onderaan, buiten viewport op kleine schermen",
      "severity": "medium"
    }
  ],
  "summary": "Deze persona haakt af voordat de boeking rond is. Simplificeer groepsselectie en zet CTA bovenaan."
}

Resultaat

Het team kon honderden design-variaties in uren toetsen in plaats van weken. Gaps in de UX werden eerder zichtbaar. Real user-research ging vervolgens over slimmere vragen en diepere hypothesen, niet over basics.

Wat we onderweg leerden:

Synthetic UX is géén vervanging voor echte gebruikers. Het vindt voor-de-hand-liggende problemen en missers, niet de subtiele dingen die je alleen ziet als je iemand naast je hebt zitten.
De personas zijn zo goed als de data waarmee je ze genereert. Slechte aannames in je data = slechte synthetic users. Bias verdwijnt niet vanzelf.
Sneller iteraties werkt goed in vroege designfases. In latere polish-fases wordt het minder waardevol. Dan wil je juist de nuance van echte mensen.
Transparantie is cruciaal. Iedereen in het team moet weten dat ze met synthetic users praten. Anders sluipt er valse zekerheid in.

UX-cycles die te traag zijn?

Als je team veel design-keuzes maakt en weinig tijd heeft voor real user-research, is een synthetic-UX-pipeline vaak onderschat waardevol. We denken graag mee.

Brainstorm met ons