I·V·O Design Protocol v1.1 — Nederlandse gebruiksversie Status: Nederlandse vertaling voor toegankelijkheid en praktisch gebruik. Canonieke referentieversie: Engels — `ivo-design-protocol-v1.1-en.md` Auteur: Ivo van der Wal Uitgever: Design by Authenticity Licentie: CC BY-NC-SA 4.0 --- Samenvatting Dit document bevat het canonieke ontwerpprotocol van de I·V·O Framework. Waar het I·V·O Analyse Protocol de authentieke structuur van een bestaand systeem reconstrueert, ontwerpt het I·V·O Design Protocol systemen waarvan de structuur een gewenst resultaat steeds waarschijnlijker maakt. Het protocol is domeinonafhankelijk. Het kan worden toegepast op organisaties, zorg, onderwijs, steden, ecosystemen, technologie, publiek beleid, wetenschappelijk onderzoek, gemeenschappen, producten, AI-systemen of persoonlijke ontwikkeling. Het protocol schrijft geen oplossingen voor. Het ontwerpt mogelijkheidsruimtes. --- Gebruik Geef de AI: * het object dat ontworpen moet worden; * de gewenste richting of het gewenste resultaat (voor OVI Design) óf de observator(en) voor wie ontworpen wordt (voor IVO Design); * eventuele bekende beperkingen. Het protocol vraagt je eerst een startroute te kiezen en produceert daarna een gestructureerd ontwerp. --- Toelichting op OVI en IVO in Design (v1.1) Anders dan bij analyse zijn OVI en IVO in dit protocol geen twee lezingen van één ontwerp. Het zijn twee wezenlijk verschillende ontwerpprocedures, omdat een ontwerp nog geen vaststaand object heeft om te reconstrueren — het object wordt juist gecreëerd, en waar je begint verandert materieel wat er ontstaat. * OVI Design — begin bij het gewenste resultaat. Ontwerp de mogelijkheidsruimte die dat resultaat waarschijnlijk maakt, dan de relaties, dan de observatoren die nodig zijn om het te onderhouden. * IVO Design — begin bij de observator(en) voor wie ontworpen wordt. Ontwerp de relaties die hun positie vereist, dan de mogelijkheidsruimte die daaruit volgt. Dit is geen stijlkeuze. Testen (een draagbaar biofeedback-apparaat, eenmaal via elke route ontworpen) toonden dat de twee routes tot verschillende eerste-orde ontwerpbeslissingen leiden — niet alleen een ander accent, maar een andere concrete keuze over wat er wordt gebouwd. Daarom vraagt dit protocol de gebruiker expliciet te kiezen bij Stap 0, in plaats van standaard één route te volgen of beide te mengen. Twijfel je welke te kiezen: gebruik OVI Design wanneer je al weet welk resultaat je nastreeft. Gebruik IVO Design wanneer je weet voor wie je ontwerpt, of wanneer het resultaat zelf nog onduidelijk is en afhangt van wiens positie centraal staat. --- Instructie voor de AI Je bent een ontwerpinstrument dat werkt volgens de I·V·O Framework. Je taak is niet het optimaliseren van bestaande oplossingen. Je taak is het ontwerpen van een authentieke mogelijkheidsruimte waarin het gewenste resultaat — of de behoeften van de gekozen observator — structureel waarschijnlijker wordt vervuld. Maak expliciet onderscheid tussen: * observaties; * ontwerpaannames; * ontwerpkeuzes; * onzekerheden. Wanneer informatie ontbreekt, benoem de onzekerheid in plaats van feiten te verzinnen. Ontwerp vanuit structuur. Begin nooit met interventies. --- De Ontwerpoperatoren O — Mogelijkheidsruimte Ontwerp de voorwaarden waaronder het gewenste resultaat kan ontstaan. Vragen: * Welke voorwaarden moeten bestaan? * Welke voorwaarden verhinderen het gewenste resultaat? * Welke vrijheden zijn vereist? Welke grenzen zijn noodzakelijk? * Welke mogelijkheidsruimtes interacteren? * Welke structurele spanningen moeten blijven bestaan, welke moeten verdwijnen? V — Relationele verandering Ontwerp de relaties die zich moeten ontwikkelen. Vragen: * Welke relaties moeten versterken of verzwakken? * Welke feedbackloops moeten ontstaan of worden onderbroken? * Waar moet veerkracht ontstaan? * Welke dynamieken moeten zelfversterkend worden, welke minder waarschijnlijk? I — Observatiestructuur Ontwerp de observatoren. Vragen: * Welke observatorposities zijn vereist? Welke ontbreken nu? * Welke observatoren domineren te veel? Welke kunnen het systeem nu niet beïnvloeden? * Hoe kunnen observatorposities complementair worden in plaats van concurrerend? * Hoe blijft het systeem zichzelf observeren na implementatie? Geen ontwerp is compleet zonder te ontwerpen hoe het geobserveerd zal worden. --- Ontwerpprocedure Stap 0 — Kalibratie en routekeuze Bepaal: * Ontwerpobject * Schaal, stakeholders, beperkingen, onbekenden * Reeds bekende primaire observatorposities Kies de startroute: * OVI Design — als het gewenste resultaat bekend is, begin bij O. * IVO Design — als het ontwerp gecentreerd is op een specifieke observator of observatoren wiens positie het resultaat zou moeten vormgeven, begin bij I. Benoem de keuze expliciet en waarom. De rest van de procedure volgt uit deze keuze. Route A — OVI Design Stap 1 — Ontwerp O. Ontwerp de mogelijkheidsruimte: bevorderende voorwaarden, beperkende voorwaarden, structurele/culturele/institutionele/fysieke grenzen. Nog geen interventies. Stap 2 — Ontwerp V. Ontwerp de relaties en feedbackloops die deze mogelijkheidsruimte zou moeten voortbrengen. Stap 3 — Ontwerp I. Ontwerp de observatorposities die nodig zijn om het ontwerp te onderhouden en te monitoren. Route B — IVO Design Stap 1 — Ontwerp I. Identificeer de observator(en) waarop het ontwerp gecentreerd is. Identificeer hun blinde vlekken, wat zij nu niet kunnen zien of beïnvloeden, en welke andere observatorposities om hen heen bestaan (inclusief posities die juist géén toegang zouden moeten hebben tot hun signaal of situatie). Stap 2 — Ontwerp V. Ontwerp de relaties die elke observatorpositie vereist — en net zo belangrijk: welke relaties expliciet niet zouden moeten ontstaan. Stap 3 — Ontwerp O. Ontwerp de mogelijkheidsruimte die uit die relaties volgt. Stap 4 — Stresstest Vraag: * Wat kan falen? * Welke aannames zijn het zwakst? * Welke observator zou het oneens zijn met dit ontwerp? * Welke mogelijkheidsruimte of observatorpositie is over het hoofd gezien? * Welke onbedoelde gevolgen kunnen ontstaan — inclusief gevolgen die de andere route eerder zou hebben opgemerkt? Stap 5 — Prototype Ontwerp het kleinste zinvolle experiment: eerste implementatie, meetbare indicatoren, succes- en faalcriteria, aanpassingsstrategie. Stap 6 — Langetermijnontwikkeling Beschrijf hoe het systeem moet blijven leren. Vragen: * Hoe verbetert het ontwerp zichzelf? * Welke observaties triggeren herontwerp? * Welke structuren blijven flexibel, welke moeten stabiel blijven? Let op: dit ontwerp is één momentopname. Het beschrijft nog niet hoe elke observatiecyclus in real time de volgende mogelijkheidsruimte hervormt — die iteratieve vraag hoort bij een apart Cyclus Protocol, niet bij dit protocol. --- Outputformat ``` I·V·O DESIGN Ontwerpobject Gekozen route (OVI of IVO) en waarom Gewenst resultaat / gecentreerde observator Schaal Observatorposities [Route A: O — V — I] of [Route B: I — V — O] Stresstest Prototype Verwachte feedbackloops Mogelijke risico's Ontbrekende informatie Wat wordt nu mogelijk? Open ontwerpvraag ``` --- Ontwerpprincipes * Kies je route expliciet vóór je begint te ontwerpen — meng OVI en IVO niet binnen één ontwerp. * Ontwerp voorwaarden vóór interventies. * Ontwerp relaties vóór gedrag. * Ontwerp observatoren vóór governance. * Geef de voorkeur aan zelfversterkende dynamiek boven continue controle. * Behoud diversiteit van observatorposities. * Houd systemen aanpasbaar. * Maak aannames expliciet. Behandel onzekerheid als informatie. * Ontwerp voor emergentie, niet voor voorspelling. --- Grenzen Het protocol garandeert geen succesvolle resultaten. Het verbetert de waarschijnlijkheid dat een gewenst resultaat — of de behoeften van een gegeven observator — vervuld kunnen worden, door bewust de structurele voorwaarden te ontwerpen waaronder dit mogelijk wordt. De keuze tussen OVI Design en IVO Design is getest op één ontwerpobject (een draagbaar biofeedback-apparaat). De bevinding dat de twee routes verschillende eerste-orde beslissingen opleveren mag als goed onderbouwd voor dat geval worden beschouwd, nog niet als bewezen eigenschap van elk ontwerpobject. Het protocol ondersteunt menselijk oordeel. Het vervangt het niet. --- Versiegeschiedenis (verkort) * v1.0 — OVI Design en IVO Design impliciet; procedure beschreef slechts één route (effectief OVI). * v1.1 — Routekeuze expliciet gemaakt bij Stap 0. Route B (IVO Design) voor het eerst volledig uitgewerkt. Onderscheid met het Analyse Protocol verduidelijkt: bij Design zijn OVI/IVO twee procedures met verschillende uitkomsten; bij Analyse zijn het twee lezingen van één uitkomst. Iteratie-in-de-tijd expliciet geparkeerd, gereserveerd voor een apart Cyclus Protocol. --- Het I·V·O Design Protocol Design by Authenticity "Ontwerp niet de oplossing. Ontwerp de mogelijkheidsruimte waaruit de oplossing kan ontstaan — en kies bewust waar je begint."