Een productdemonstratie eerlijk begrenzen

Elke demo bevat drie beloftes: dit bestaat, dit werkt zo, en dit krijg jij ook. Een gesimuleerd scherm schendt meestal de derde. Begin daarom met één zin die je kunt toetsen: 'Deze demo toont X, uitgevoerd in omgeving Y, met als voorwaarde Z.' Lukt die zin niet, dan is de demo nog niet klaar voor publicatie.

Onderscheid drie soorten materiaal. Een live-uitvoering draait op het moment van tonen in een echte omgeving. Een opname toont iets wat echt gebeurde, maar op een ander moment. Een simulatie is nagebouwd of geregisseerd. Alle drie mogen, zolang de kijker weet welke hij ziet. Het probleem ontstaat wanneer een simulatie de uitstraling van een live-resultaat krijgt, bijvoorbeeld door een klok die doet alsof het nu is, een melding die 'net binnenkomt' of cijfers zonder context.

Maak vóór je opneemt of presenteert een inventaris. Dat kost een uur en voorkomt later discussies.

1. Lijst elke functie die in beeld komt, ook de kleine zoals een filter, een export of een automatisch ingevuld veld.
2. Noteer per functie waar die beschikbaar is: welk pakket, welke gebruikersrol, welke instelling. Weet je dat niet zeker, schrijf dan 'te bevestigen door de productverantwoordelijke' en toon de functie niet voordat het antwoord er is.
3. Noteer de benodigdheden: koppelingen met andere diensten, bestaande accounts, aangeleverde data, installatie en de tijd van een medewerker.
4. Noteer de beperkingen: wat de functie niet doet en wat handmatig blijft.
5. Voer de demo uit in een schone omgeving en vergelijk wat je ziet met je lijst. Alles wat in beeld staat maar niet op de lijst, is een onbedoelde belofte.
6. Laat iemand die de demo niet maakte de lijst lezen en in eigen woorden zeggen wat hij zou verwachten te krijgen. Elk verschil met jouw bedoeling is een onduidelijkheid.

Gebruik onderstaande tabel per element in je demo. Bij twijfel kies je de kleinste belofte die nog klopt.

Zet het label in de gesproken of geschreven tekst, niet alleen in een hoek van het scherm. Een label dat na twee seconden verdwijnt, telt niet als begrenzing.

Veel demo's tonen iets wat bij een ander account anders uitpakt. Het helpcentrum van LinkedIn op https://www.linkedin.com/help/linkedin laat dat zien: de zichtbaarheid van berichten en betrokkenheid kan variëren met de zichtbaarheidsoptie die de auteur koos, en na opzegging van een Premium-abonnement vervalt de toegang tot Premium-functies aan het einde van de factureringscyclus. Voor jouw demo betekent dat dat een scherm met bereik, reacties of een betaalde functie bij een ander account of andere instelling anders kan uitpakken. Controleer dat per geval.

Pas dit toe op je eigen situatie. Vraag je bij elk element: hangt dit af van een instelling van de gebruiker, van een abonnement of van het platform zelf? Een helppagina is een uitgangspunt, geen bewijs voor het account van je klant. Laat de beheerder van het betrokken account controleren wat daar echt beschikbaar is, en noteer de datum van die controle. Platforms wijzigen functies, dus een demo uit het verleden kan achterhaald zijn zonder dat iemand het merkt.

Een begrenzing die niet iedereen kan lezen, begrenst niets. De tutorials van het W3C op https://www.w3.org/WAI/tutorials/ beschrijven hoe je webinhoud toegankelijk maakt voor mensen met een beperking, onder meer voor afbeeldingen en tabellen. Dat is bruikbaar voor een demo-pagina vol schermafbeeldingen. De suggesties hieronder zijn deels redactionele voorstellen en niet allemaal letterlijk uit de bron.

• Geef elke schermafbeelding een tekstalternatief dat zegt wat er te zien is én of het een voorbeeld of een live-scherm is.
• Zet voorwaarden en beperkingen als gewone tekst naast of onder de afbeelding, niet alleen erin.
• Bouw een vergelijking tussen pakketten als echte tabel met kopcellen, zodat een schermlezer de relatie tussen functie en pakket kan volgen.
• Voeg bij video een tekstversie toe van wat er gebeurt en welke voorwaarden gelden.

Test dit met iemand die je pagina met alleen toetsenbord of schermlezer doorloopt. Dat blijft een eigen controle: de bron biedt richtlijnen, geen certificering van jouw pagina.

Fictief voorbeeld (alleen invoer en controles). Je maakt een demo van een dienst die berichten plant en reacties in één overzicht toont. Invoer: een planningsscherm met drie berichten, een koppeling met een bedrijfspagina en een rapportagescherm met voorbeeldcijfers. Verwachte controles: (1) bevestig bij de productverantwoordelijke in welk pakket planning en rapportage zitten; (2) noteer dat de koppeling een bestaand account en toestemming van de beheerder vraagt; (3) label het rapport als 'voorbeelddata'; (4) schrijf op dat reacties van andere kanalen alleen verschijnen als die kanalen gekoppeld zijn; (5) laat een collega de lijst lezen en terugzeggen wat hij verwacht.

Geef sales en support daarna één blad mee met vier kolommen: functie, status (live, opname, simulatie), voorwaarden en beperkingen. Wie vragen krijgt, antwoordt vanuit dat blad en niet vanuit het geheugen van de maker.

Wil je ook zien welke publieke signalen je website geeft over functies en voorwaarden? Bekijk ze via Marketing Scan. Een publieke scan meet alleen zichtbare signalen en bewijst geen volledige technische of inhoudelijke juistheid.