Convergentie & Peer Review | Spatial Anchor

03Voorbereiding op Convergentie

3.1 Status: Divergentie afgerond

De drie alternatieven zijn uitgewerkt en bestudeerd. Elk alternatief is vanuit de theorie door mij geanalyseerd, met interactieve flows en storyboards.

De volgende stap is convergentie, maar niet op basis van deze tabel. Daar worden de peers voor ingezet.

3.2 Vergelijkingsmatrix: Trade-offs per alternatief

Let op: dit is mijn eigen analyse

Onderstaande matrix is mijn eigen theoretische verkenning vanuit het divergentieproces. Tijdens de expert review met Frans werd duidelijk dat deze analyse niet als basis mag dienen voor het convergentiebesluit want ik kan niet mijn eigen rechter zijn (ookal onderbouw ik vanuit bewezen theorie). De matrix blijft staan als context voor de peers, maar de definitieve voor- en nadelen worden vastgesteld door de peers.

Onderstaande matrix vat de theoretische trade-offs samen zoals ik ze tijdens het divergeren heb geïdentificeerd.

Criterium	A — Pin op Kaart	B — Panorama Tap	C — Foto & Tag
Gulf of Execution	Groot 3D→2D	Klein panorama	Klein foto = actie
Recognition	Indirect kaart	Direct 360°-foto	Direct foto
Flow-behoud	Laag scherm	Medium kort scherm	Laag-Med camera
Privacy	Geen issue stil	Geen issue stil	Medium foto zichtbaar
Tech complexiteit	Laag plattegrond	Medium 360° viewer	Zeer laag camera API
Sociale frictie	Laag normaal	Laag normaal app	Med-Hoog fotograferen
Terugkijken thuis	Plattegrond + pins 2D kaart	360° + ankers ruimtelijk + visueel	Foto-galerij visueel rijk
Ruimtelijke verankering	Indirect pin	Direct panorama-anker	Indirect kamer-tag

04Peer Review: Convergeren door Externen

4.1 Waarom peer review?

„Wij van WC Eend vinden WC Eend geweldig." — Frans (expert review)

Frans veegde mijn eerste aanpak (zelf zo'n matrix invullen en de theorethische winnaar kiezen) vrij direct van tafel. Hoe hard ik het ook objectief probeer aan te vliegen, als ontwerper heb ik blinde vlekken en wil ik stiekem toch dat mijn favoriet wint.

Dus ik liet het beoordelen over aan drie peers. Zij kennen de UX-theorie, maar hebben geen emotionele binding met mijn alternatieven. Zij scoren, en ik gebruik hún data voor mijn defintieve keuze.

Geen 'Design by Committee'

Ik ga ze niet vragen: "welke vind je mooier?". Ik stel gerichte theorievragen. Hun antwoorden geven richting, maar ik blijf degene die de ontwerpkeuzes maakt.

4.2 & 4.3 De theorie meetlat

Ik heb drie peers (Bas, Mick en Raoul) de 3 alternatieven voorgelegd met daarnaast een beoordelingsformulier.

Mijn peers zijn geen eindgebruikers op een woningmarkt, dus hen vragen wat "lekker werkt" is onzin. Wat peers wél heel goed kunnen, is analytisch oordelen of een concept theorethisch hout snijdt. Daarom dwingt dit formulier hen om mijn ontwerpen puur af te rekenen op de cognitieve belasting (de mentale hoofdpijn tijdens een bezichtiging) via vier harde pijlers:

Gulf of Execution: Hoeveel stappen of vertaalslagen kost een actie?
Recognition vs. Recall: Herkennen ze thuis direct wat er mis was, of is het nadenken?
Mapping: Spiegelt de digitale interface lekker met de fysieke ruimte?
Mental Models: Voelt het dekkend met wat ze al kennen?

4.4 De vragen

Ze krijgen per alternatief theorievragen gesteld, afgesloten met de vergelijkingsvragen: welk concept wint én zagen ze slimme manieren om sterke aspecten met elkaar te combineren?

05Uitvoering

De sessies zijn met aparte invulformulieren uitgevoerd en hun antwoorden zijn verzameld.

📝 Bekijk Formulier: Bas 📝 Bekijk Formulier: Mick 📝 Bekijk Formulier: Raoul

06Convergentiebesluit

6.1 Wat zeiden de peers?

Geen enkel alternatief kreeg zomaar een gouden medaille. Ze hadden allemaal een theorethisch lakpuntje. Toch was het beeld verrassend helder, omdat Bas, Mick en Raoul onafhankelijk van elkaar tegen precies dezelfde zaken aanliepen.

Alternatief	Gulf of Execution	Recognition vs. Recall	Mapping	Mental Models	Eindoordeel Peers (Ranking)
A - Pin op Kaart	Zwaar (Veel 3D→2D stappen)	Recall (Kaart mist visueel detail)	Sterk (Plattegrond spiegelt ruimte)	Herkenbaar (Maps-achtig, maar onnatuurlijk in bezichtiging)	Raoul (#1), Bas (#2), Mick (#3)
B - Panorama Tap	Medium (Stoeien met view)	Recognition (Hoge context)	Sterk (360° = directe ruimtelijke spiegel)	Nieuw (Geen bestaand referentiekader bij gebruiker)	Mick (#2), Raoul (#3), Bas (#3)
C - Foto & Tag	Licht (Snel fotograferen)	Recognition (Letterlijk beeld)	Zwak (Foto mist ruimtelijk overzicht)	Vertrouwd (Camera-app = veilig mental model)	Bas (#1), Mick (#1), Raoul (#2)

De pijnpunten op theorie volgens de peers:

• 2D-Plattegrondlezen leidt te veel af (A):
Mick wees op de veel te zware Gulf of Execution: "Je moet best wel veel vertaalslagen maken... die vertaalslag van 3D naar 2D haalt je er teveel uit." Raoul zag dit ook: de abstracte denkslag kost mentale kracht in het moment.
• Simpel fotograferen wínt de race (C):
Als ik theorethisch de cognitieve load in de tour zélf wil verlagen, dan moet ik C hebben. Mick: "Minste tegenwerking... Het mental model van de camera app is een veilige handeling." En Bas: "Snel. Goede flow-behoud." Iedereen kent dit principe.
• Maar "alleen" C levert thuis tóch chaos op:
Zo vloeiend als C is tijdens de bezichtiging, is de Mapping dat naderhand thuis niet. Raoul: "Mist het ruimtelijke overzicht in de hele woning." Mick zei: "Chaos achteraf."
En even voor de duidelijkheid waarom het theorethisch tóch chaos is (wat ik me zelf ook even afvroeg): bij C label je weliswaar in welke kamer (bijv. "Woonkamer") je de foto neemt, maar thuis zit je met een lijst van 25 foto's. Waar was slaapkamer 1 ook alweer ten opzichte van noord? En wáár in de woonkamer zat die specifieke vlek precies? Door het gebrek aan een visuele macrolaag (wat Plattegrond A wél heeft) verlies je de ruimtelijke context. De gebruiker moet zélf de kamergeografie weer reconstrueren in zijn hoofd, wat betekent dat cognitief de zware Recall weer dominant wordt in plaats van Recognition.

6.2 Mijn besluit: De "Onzichtbare Plattegrond" (C + A hybride)

De antwoorden stuurden me allemaal dwingend in The Only Right Direction: Pak de output-structuur van de Plattegrond (A) maar bedien hem met de snelheid van de Camera (C).

Dit zijn de quotes die meehielpen in de beslissing:
Mick: "Ik zou de snelheid van C (camera) koppelen aan het format van A. Dat de user op één knop drukt, maar dat de applicatie de foto automatisch vastprikt op die plattegrond."
Bas: "De plattegrond van 1 en de foto's van 3 combineren."
Raoul: "De ruimtelijke context van A combineren met de visuele bewijsvoering van C."

⚖️ Mijn Ontwerpbesluit: Camera als Input, Plattegrond als Output

De kern: De koper mag tijdens het bezichtigen niet worden afgeleid door een plattegrond, maar heeft die kaart 's avonds wél nodig voor het overzicht.

Ik ga het concept nu opsplitsen in drie simpele belevingen:

Tijdens de bezichtiging (Input): De koper gebruikt de app eigenlijk als een hele normale, simpele camera (Alternatief C). Fotootje klikken en letterlijk weer direct door. Geen denkwerk, nul afleiding.
Het Prikken: Op de achtergrond snapt de app waar de foto genomen is, en hangt deze blind aan de juiste kamer op de plattegrond. De koper heeft daar tijdens de rondleiding geen omkijken naar.
Thuis op de bank (Output): Als je in alle rust thuiskomt, krijg je de Plattegrond-view (Alternatief A) te zien. Maar dan compleet ingevuld met jouw specifieke foto's van de gebreken per kamer. Direct ruimtelijk overzicht.

Ontwerpen voor de realiteit: Wat als het even niet lukt?

Dat de app op de achtergrond 100% foutloos weet of jij in Slaapkamer 1 of Slaapkamer 2 staat met de camera, klinkt leuk. Maar we weten allemaal dat technologie ook in de toekomst wel eens hapert of het simpelweg even niet weet.

Daarom ga ik in het uitwerken niet uit van dat het altijd maar goed gaat. Ik wil nadrukkelijk ook de Fallback ontwerpen voor als het systeem twijfelt. Bijvoorbeeld: dat na het maken van de foto er héél simpel gevraagd wordt "In welke kamer is dit?" met een handig knopje. Een snelle noodoplossing die voorkomt dat de gebruiker gefrustreerd raakt, maar die het ontwerp meteen een flink stuk realistischer maakt om later ook echt te bouwen.

6.3 Volgende stap

De ontwerpalternatieven voor de kern-interactie zijn geconvergeerd naar een hybride richting. De interactieve flows per alternatief zijn al uitgewerkt (zie Alt A, B en C). Nu is de volgende stap: de hybride richting gedetailleerd gaan ontwerpen in concrete schermen.

Volgens het C7 College Interaction Design en Ontwerp Studies werk ik dat in lagen uit:

Laag 1 — De hybride kern-flow in schermen: De geconvergeerde flow (camera-input + plattegrond-output, inclusief de Fallback) uitwerken in concrete wireframes en wireflows. Hoe ziet elk scherm er precies uit?
Laag 2 — Navigatie & ruimtelijk ontwerp: Hoe navigeert de bezoeker door de app? Hoe ga je van het camera-scherm naar het plattegrond-overzicht? De structuur en het ruimtelijke (spatial & transitional) ontwerp.
Laag 3 — Details: De finishing touch: UX Copy (welke teksten staan er?), micro-interacties (animaties, feedback) en UI Animation.

Het eindresultaat moet concreet, onderbouwd en te ervaren zijn. Het hoeft voor deze herkansing niet met gebruikers in de gebruikscontext geëvalueerd te worden.

Planning: drie expertmomenten met Frans

Bezoek 1 (afgerond): Drie ontwerpalternatieven (A, B, C) met uitgewerkte flows voorgelegd. Frans stuurde mij naar externe peer reviews. Resultaat: convergentie naar het hybride model. (BC 7.2.3)
Bezoek 2: De hybride kern-flow uitgewerkt in concrete schermen (laag 1) en verkenningen van navigatie en ruimtelijk ontwerp (laag 2). Feedback van Frans ophalen en verwerken. (BC 7.2.3 + BC 7.2.2)
Bezoek 3: Het volledige, ervaarbare experience prototype voorleggen (laag 1 + 2 verwerkt met Frans' feedback, laag 3 — micro-interacties en details — erop) aan Frans voor feedback. (BC 7.2.2)