Waarom toegankelijkheid in 2025 een topprioriteit moet zijn

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% correct.

Hannah Clark: Ik denk dat het tijd is om toe te geven dat praten over toegankelijkheid ons vaak ongemakkelijk maakt. In een productcontext geven we doorgaans prioriteit aan functies met de grootste impact en het grootste percentage gebruikers. Wanneer we het hebben over bouwen voor toegankelijkheid, voelt dat daarom als een beladen onderwerp. Waar op de roadmap passen we functies in die een grote impact hebben voor een relatief klein percentage gebruikers? Hoe weten we hoe toegankelijkheid eruit moet zien voor ons product wanneer toegankelijkheid voor verschillende mensen verschillende dingen betekent? En hoe doen we dit allemaal zonder aannames te doen of de gebruikers die we proberen te ondersteunen onbedoeld te beledigen?

Mijn gast vandaag is Prerna Ramachandra, Principal Product Manager bij Yahoo. Voordat ze bij Yahoo kwam, was Prerna Senior Product Manager bij Slack, waar ze een belangrijke rol speelde bij het controleren en ontwikkelen van toegankelijke functies voor de diverse gebruikersgroep van het product. Wat je nu gaat horen is deels casestudy en deels praktische handleiding over de zakelijke argumenten voor toegankelijkheid en de meest efficiënte en ethische manieren om je product gastvrijer te maken voor iedereen. Laten we beginnen.

Welkom terug bij de podcast van The CPO Club. Vandaag zijn we hier met Prerna Ramachandra.

Prerna, heel erg bedankt dat je in je drukke agenda tijd hebt vrijgemaakt om vandaag bij ons te zijn.

Prerna Ramachandra: Heel erg bedankt dat je me hebt uitgenodigd. Fijn om hier te zijn.

Hannah Clark: Kun je ons iets vertellen over je achtergrond en hoe je bent gekomen waar je nu bent?

Prerna Ramachandra: Momenteel ben ik Principal Product Manager bij Yahoo. Ik werk hier nu ongeveer anderhalf jaar. Daarvoor werkte ik bij Slack, vlak voordat het bedrijf werd overgenomen door Salesforce en gedurende de overname door Salesforce. Bij Slack leidde ik voornamelijk het team voor toegankelijkheid en ontwerpsystemen, voordat ik overstapte naar het werken aan de kernervaringen van de desktopapplicatie.

Mijn werk binnen het ene team liep op een bepaalde manier over in mijn werk binnen het andere team; daar zou ik later vandaag graag dieper op ingaan. Daarvoor werkte ik bij The Washington Post, waar ik de herinrichting van de homepage en de herplatforming van de artikelpagina-ervaring leidde. Ik heb dus ervaring in de media en bij grote technologiebedrijven.

Ik zeg graag dat mijn interesse in productontwikkeling specifiek aansluit bij het snijpunt van product, technologie en storytelling. En bij de manieren waarop mensen verhalen gebruiken om met elkaar te communiceren en hoe technologie daarvoor een effectief hulpmiddel kan zijn.

Hannah Clark: Dat is perfect, aangezien je hier vandaag je verhaal vertelt.

Het is duidelijk iets waar we allebei gepassioneerd over zijn: storytelling. Vandaag richten we ons op iets dat misschien wat specialistischer is, maar absoluut een onderwerp waarvan ik denk dat we er niet genoeg over praten: toegankelijkheid, en specifiek het snijvlak van toegankelijkheid en het inwerken van gebruikers.

Om te beginnen: waarom zou je, op basis van je ervaring in dit vakgebied, zeggen dat toegankelijkheid vaak als een bijzaak wordt behandeld? En wat is het zakelijke argument om toegankelijkheid vanaf het begin in te bouwen?

Prerna Ramachandra: Zeker. Ik begin graag met een uitspraak waarin ik echt, echt geloof: we leven in een tijd waarin ik niet meer geloof dat technologie een luxe is.

Ik ben opgegroeid in de jaren negentig, waarmee ik mezelf hier een beetje prijsgeef, toen technologie nog een nieuwigheid was. Het internet was nog een nieuwigheid. Niet iedereen had er toegang toe en niet iedereen had die toegang nodig, maar we leven nu in een tijd waarin elk van onze essentiële diensten op de een of andere manier is gedigitaliseerd. Dat betekent dat iedereen ter wereld die diensten gemakkelijk moet kunnen gebruiken.

Mensen met een beperking worden in onze samenleving over het algemeen als een bijzaak behandeld. Ik denk dat veel van onze diensten niet voldoende toegankelijk zijn, maar technologie verkeert in de unieke positie dat toegankelijkheid relatief eenvoudig kan worden ingebouwd in wat ze doet. Technologie verkeert ook in de unieke positie dat ze het leven van iedereen, ook van mensen met een beperking, veel gemakkelijker kan maken.

Daarom denk ik dat dit een van de belangrijkste redenen is, vanuit een moreel en ethisch standpunt, om er prioriteit aan te geven. Waarom het als een bijzaak wordt behandeld, komt eerlijk gezegd doordat de meeste organisaties het zakelijke argument ervoor niet volledig begrijpen. Dat is nummer één. Nummer twee is volgens mij dat mensen denken dat toegankelijkheid diepgaande technische expertise vereist.

Daardoor voelen ze niet altijd dat ze over die expertise beschikken of denken ze er niet altijd aan. Het zit niet ingebakken in onze processen. Als gevolg daarvan negeren we het totdat iemand bang is dat er een rechtszaak komt of dat ze een klant verliezen die toegankelijkheidseisen heeft.

En plotseling proberen je teams uit te zoeken wat er mis is en hoe ze dit kunnen inbouwen. Om het tweede deel van je vraag te beantwoorden — wat is het zakelijke argument voor toegankelijkheid? — ik noemde dit al in mijn eerste punt. De realiteit is dat je, om technologie succesvol te laten zijn, meer gebruikers wilt hebben. De meesten van ons worden immers meer betaald naarmate ons product meer wordt gebruikt.

En meer mensen gebruiken het wanneer ze er toegang toe hebben. Op een fundamenteel niveau is toegankelijkheid dus simpelweg belangrijk omdat meer mensen je producten kunnen gebruiken. Wanneer meer mensen je producten gebruiken, verdien je meer geld. De andere kant van het verhaal is dat je niet aangeklaagd wilt worden. Als je wordt aangeklaagd, bestaat de kans dat je veel geld moet betalen.

Vanuit beide perspectieven is er dus een zakelijke onderbouwing voor toegankelijkheid. Ik wil daar nog iets aan toevoegen, waar ik later uitgebreider op inga en waar ik persoonlijk binnen het toegankelijkheidsveld erg gepassioneerd over ben: we beperken het idee van toegankelijkheid vaak tot ervoor zorgen dat iets met schermlezers bruikbaar is en dat je toetsenbordnavigatie kunt gebruiken.

Maar ik denk dat we verder moeten gaan dan die definitie van toegankelijkheid. We moeten echt nadenken over hoe we ervoor zorgen dat iedereen, in elke omstandigheid, het product kan gebruiken. Je gebruikers moeten het product in iedere situatie kunnen gebruiken, omdat we toegankelijkheid vaak niet zien als iets dat situationeel en afhankelijk van omstandigheden kan zijn.

Een voorbeeld dat ik altijd graag geef, zijn spraakopdrachten of het gebruiken van je stem om je product te bedienen. We denken vaak dat dit gemakkelijker is wanneer je slecht zicht hebt. Mijn vader is bijvoorbeeld veel ouder en kan kleine tekst op zijn scherm misschien niet goed zien, dus gebruikt hij graag zijn stem om veel dingen op zijn telefoon te bedienen.

Maar als je rijdt, kun je je handen ook niet gebruiken en gebruik je je ogen op een andere manier niet. Je kunt dan nog steeds spraakopdrachten gebruiken. Wanneer je over toegankelijkheid nadenkt, kun je dit dus zien als iets dat een situatie omvat in plaats van een individu of individueel probleem. Dat verbreedt je definitie en laat je beseffen dat je een enorme use case en een enorme gebruikersgroep laat liggen.

Dat is waarschijnlijk niet goed voor je bedrijf. Er is dus een praktisch zakelijk argument om vanaf het allereerste begin prioriteit te geven aan toegankelijkheid.

Hannah Clark: Dat vind ik heel treffend. Volgens mij geldt dit voor toegankelijkheid van zowel digitale als fysieke producten en ruimtes. Ik vind het een mooie manier om te kijken naar toegankelijkheid voor een situatie in plaats van voor een specifieke use case. Ik heb dat zelf ervaren toen ik een kinderwagen voortduwde en merkte hoeveel ruimtes waren ontworpen voor één voetganger, in een soort enkele rij.

Je realiseert je dan dat er zoveel verschillende contexten zijn waarin iemand een toegankelijkheidsfunctie of aanpassing nodig kan hebben, of waarin iets met toegankelijkheid in gedachten ontworpen moet zijn. Dat is namelijk toepasbaar op zoveel leeftijden, levensfasen en omstandigheden. Ik vind die manier van denken dus erg interessant en wil daar zo meteen graag wat dieper op ingaan.

Je zei dat je iets meer wilt vertellen over je ervaring bij Slack. Ik zou graag ingaan op enkele projecten waar je toen aan werkte, en dan vooral op workflows voor het inwerken van gebruikers door de lens van toegankelijkheid.

Kun je me uitleggen hoe je een analyse van de bestaande situatie hebt aangepakt om te beoordelen wat de huidige toegankelijkheidsstatus van het product was en hoe je daarna verder bent gegaan?

Prerna Ramachandra: Zeker. Toen ik bij Slack begon, was een van de eerste projecten waar ik aan werkte het vaststellen hoe toegankelijk het product was en wat we konden doen om precies te bereiken wat jij beschreef.

Welke soorten kaders hadden we om de situatie van het product te analyseren? Toen ik bij Slack kwam, hadden we helemaal niets. Slack bevond zich op dat moment in een fase waarin het bedrijf zich sterk richtte op grote zakelijke klanten, nadat het goed had gepresteerd in de markt voor kleine en middelgrote bedrijven. Toen Slack zich op die grote zakelijke klanten richtte, werd duidelijk dat er voor hun leveranciers zeer strenge regelgeving op het gebied van toegankelijkheid gold.

Het eerste wat ik deed, was daarom een interne normenset ontwikkelen die we de toegankelijkheidsnormen van Slack noemden. Die maakte gebruik van bestaande normen, zoals WCAG, maar hield ook rekening met de unieke producten van Slack en met wat toegankelijkheid voor die producten betekende. We stelden een kader op waarmee je het product kon doorlopen en kon analyseren of het aan bepaalde criteria voldeed.

Op basis van die analyse kenden we verschillende functies binnen het product een beoordeling toe, zoals A, B of C, om te analyseren hoe toegankelijk ze waren. Dit was een combinatie van kwantitatieve en kwalitatieve analyse. We hadden een lijst met criteria. Sommige waren heel eenvoudig en hadden bijvoorbeeld betrekking op taakuitvoering: is alles toegankelijk met het toetsenbord?

Is alles toegankelijk met een schermlezer? Andere aspecten waren wat minder tastbaar. Slack is bijvoorbeeld een communicatieproduct. Een van de dingen die het erg goed doet, zijn meldingen. Je moet op de hoogte worden gebracht, maar dit speelde tijdens de pandemie. Veel mensen werkten vanuit huis en op afstand. We hoorden daarom van klanten dat er sprake was van een overvloed aan meldingen. Dat had specifiek invloed op mensen die zichzelf als neurodivergent identificeerden, omdat ze zich overweldigd voelden en hun taken niet goed konden uitvoeren.

Dat was wat minder tastbaar. Het is niet iets wat je in veel toegankelijkheidsrichtlijnen terugziet. We namen dit allemaal op in het kader. We gebruikten het kader om elk functiegebied te beoordelen. De beoordelingen waren volledig gebaseerd op de vraag of iemand de taak kon uitvoeren en hoe snel dat kon.

Zo kregen we inzicht in de urgentie van problemen en in wat het belangrijkst was en wat niet. Dat was het eerste wat we deden. We gebruikten het kader voor een analyse van de productstatus en gingen vervolgens naar de leiding met de boodschap: dit is het volledige product, dit is de verdeling binnen het beoordelingsbereik en dit zijn de problemen die volgens ons onmiddellijk moeten worden opgelost, omdat het product door het ontbreken hiervan fundamenteel niet werkt voor een groep klanten.

Het mooie aan dit kader was ook dat het niet alleen op bestaande producten werd toegepast. Als je nieuwe producten ontwikkelde, kon je het kader toepassen om te bepalen wat je moest afvinken voordat je het product kon lanceren.

Je kon het ook gebruiken voor toekomstige producten en om vooruit te denken. Dat was dus het eerste wat we deden. Daarna verrichtte ik veel werk met afzonderlijke teams om hen aan de hand van dit kader te helpen bepalen waaraan ze prioriteit moesten geven.

Iedereen heeft een roadmap. Niemand wil zijn roadmap volledig omgooien om aan iets nieuws te voldoen. Iedereen heeft een reeks zaken waaraan hij zich heeft gecommitteerd. Ik werkte daarom met afzonderlijke teams zodat ze precies wisten welke punten voor hen cruciaal waren. Op die manier konden we, wanneer we gezamenlijk naar de leiding gingen met de boodschap dat dit geprioriteerd en opgelost moest worden, een heel duidelijk plan voorleggen.

We konden ook aangeven wat de afwegingen waren: hoeveel inspanning was nodig om elk onderdeel op te lossen, wat zou er uit de roadmap worden verschoven om dit mogelijk te maken en wat zou de impact zijn? Ik geloof altijd dat je bij toegankelijkheid — en dat geldt voor veel zaken binnen productontwikkeling — de balans moet begrijpen tussen samenwerken met het afzonderlijke team dat verantwoordelijk is voor het functiegebied en het navigeren door de manier waarop je de leiding erbij betrekt om steun te krijgen voor het prioriteren van dit werk.

Ik had het geluk dat de leiding van Slack zich sterk inzette om dit werk prioriteit te geven en het goed te doen. Wat ze van ons nodig hadden, was duidelijke informatie: hoeveel inspanning is vereist, wat is de tijdlijn, wat zijn de afwegingen en wat is de impact? Dat konden we hun geven.

Het was dus veel werk op het gebied van mensenmanagement en ook veel technisch werk met engineers om de benodigde analyse te leveren.

Hannah Clark: Dit is ontzettend belangrijk. Volgens mij is draagvlak cruciaal om ervoor te zorgen dat deze functies daadwerkelijk worden uitgebracht. Zoals je zei, moet je het goed doen.

Ik zou graag wat specifieker ingaan op de afweging die je noemde. Hoe ziet zo'n afweging eruit? Als je een voorbeeld zou geven van hoe dat wordt gepresenteerd, hoe zou je het dan formuleren om alles in context te plaatsen en de omvang van het project uit te leggen, evenals de plek ervan op de lijst met cruciale punten?

Prerna Ramachandra: Het team dat volgens mij het meest werd geraakt door ons werk, was het team dat werkte aan het kernonderdeel voor berichten. Dat kwam doordat zij het grootste oppervlak beheerden. Ze waren verantwoordelijk voor alles, van het moment waarop iemand een bericht typt en verzendt tot het ontvangen van een bericht in het volledige berichtenportaal.

Ze hadden ook teamleden die verantwoordelijk waren voor kanalen. Als je Slack gebruikt, weet je dat dit de kern van de Slack-ervaring is. Het was dus logisch dat zij het grootste aantal punten moesten aanpakken. Ze beheerden niet alleen het grootste oppervlak, het was ook het meest kritieke oppervlak.

Slack bestaat doordat mensen berichten verzenden en ontvangen. Het was dus het meest kritieke oppervlak en bevatte de meest impactvolle toegankelijkheidsproblemen die moesten worden opgelost. Om een heel concreet voorbeeld te geven: toen we met deze lijst van problemen naar hen toe gingen, geef ik hier geen specifieke aantallen maar gebruik ik enkele hypothetische aantallen.

Ik gebruik 100, omdat percentages dan gemakkelijker zijn. Ik ging naar hen toe met bijvoorbeeld een lijst van 100 problemen en zei: dit alles moet worden aangepakt om ervoor te zorgen dat je product op zijn minst bruikbaar is voor iedereen die een schermlezer of toetsenbordnavigatie gebruikt of zich identificeert als iemand met een beperking.

Het eerste wat ik deed, was met de productmanager gaan zitten en zeggen: dit is de lijst met problemen die we aan de hand van ons kader hebben vastgesteld. Dit was een zeer belangrijke stap, omdat de productmanager met mij kon bespreken: ik begrijp waarom je zegt dat deze honderd punten kritiek zijn, maar ik denk dat slechts 80 procent ervan kritiek is.

Dit is namelijk de gebruikersdata en gebruikersinformatie die we hebben over hoe mensen dit gebruiken. Als je denkt dat deze specifieke workflow heel belangrijk is, gebruiken mensen die in werkelijkheid op een andere manier. Er zijn alternatieve routes en oplossingen voor. Die eerste analyse was dus belangrijk, omdat we de lijst van 100 konden terugbrengen naar 80.

Ik denk dat het voor elke organisatie met een centrale toegankelijkheidsafdeling belangrijk is om dat gesprek te voeren met de productmanager van het product zelf. Die persoon kent de gebruikers immers het best. We konden de lijst daardoor behoorlijk inkorten. Vervolgens bekeken we welke problemen betrekking hadden op product- of functiegebieden die binnenkort opnieuw ontworpen of uitgefaseerd zouden worden.

Dat hielp ons om te zeggen: als dit specifieke gebied opnieuw wordt ontworpen, zorgen we ervoor dat het in het nieuwe ontwerp toegankelijk is en hoeven we het probleem nu niet op te lossen. Als dit specifieke gebied wordt uitgefaseerd, hoeven we het probleem nu evenmin op te lossen. Zo verdwenen er nog eens ongeveer tien problemen.

We hielden toen ongeveer 70 problemen over die we met het team moesten aanpakken. We gingen met hun engineers zitten. Hierbij is het heel belangrijk om ten minste één interne toegankelijkheidsexpert te hebben. Wij hadden het geluk dat we een zeer goede engineer met die expertise hadden. Hij kon met het engineeringteam samenwerken om voor elk van die 70 problemen een inschatting van de benodigde inspanning te maken.

Daarna gingen we met de productmanager zitten en vroegen: hoeveel van deze 70 problemen kunnen jullie in de huidige of komende sprint binnen dit kwartaal prioriteren zonder dat er iets hoeft uit te lopen? Hoeveel kunnen jullie gewoon inpassen? De meeste teams hebben doorgaans enige buffer, vooral wanneer ze werken aan een product dat al is uitgebracht en ze binnenkomende bugs en problemen moeten beheren.

Dit kon in die workflow worden opgenomen. Zij zeiden: waarschijnlijk kunnen we er 20 doen zonder grote gevolgen voor de roadmap. Daar hoefden we dus niet eens de leiding bij te betrekken. We hielden vervolgens ongeveer de helft over. We konden de lijst dus sterk verkleinen. Voor de resterende, laten we zeggen 50 problemen, moesten we kijken welke grote productgebieden dit kwartaal eventueel konden worden uitgesteld als al deze problemen prioriteit kregen.

Op dat moment moest de leiding helpen om te bepalen en te onderhandelen wat we moesten doen. Er was een functie die het team dat kwartaal zou uitbrengen en die belangrijk was voor een grote klant. Diezelfde grote klant vroeg ons echter ook om deze toegankelijkheidsproblemen binnen een bepaalde termijn op te lossen.

We konden daarom naar de leiding gaan en zeggen: dit is de afweging waarmee we werken. Vervolgens konden we hun hulp gebruiken, samenwerken met de accountmanagers van die klant, naar de klant gaan en zeggen: dit is onze huidige situatie; wat zouden jullie graag zien?

Het belangrijkste is volgens mij dat je op je eigen niveau, als individuele medewerker en op het niveau van senior productmanager, principal productmanager of groepsproductmanager, zoveel mogelijk werk verricht om al het werk dat je creatief binnen je team kunt uitvoeren te prioriteren. Betrek de leiding pas wanneer er echt grote gebieden aan de orde zijn.

In dit geval hielp het dat dezelfde klant door beide sets problemen werd geraakt. We konden dus met die klant onderhandelen over wat eerst moest gebeuren en wat later kon komen. Op basis daarvan konden we zeggen: laten we deze tien problemen dit kwartaal oplossen, zodat de andere functie niet al te veel vertraging oploopt. De volgende tien lossen we het volgende kwartaal op.

Dit was het eerste kwartaal waarin we dit allemaal deden. In de daaropvolgende kwartalen konden we tijdens de kwartaalplanning met de teams vaste tijd reserveren voor toegankelijkheid.

Daarbij is het belangrijk om de hele organisatie te betrekken. We konden speciale sprintweken voor toegankelijkheid organiseren. Die lieten we samenvallen met de Global Accessibility Awareness Day wanneer dat binnen het kwartaal paste. Iedereen in het team en alle verschillende engineeringteams werkten dan samen aan toegankelijkheidsproblemen voor die sprint. Het zorgde ook voor een prettige gemeenschapsomgeving.

We organiseerden daarnaast workshops waarin we teams over toegankelijkheid vertelden. Het werkte dus erg goed, maar ik kan zeggen dat er in het begin veel hard werk nodig is. Vooral wanneer er grote afwegingen tussen functies zijn, moet je de leiding erbij betrekken om te helpen bepalen wat wanneer prioriteit krijgt.

Hannah Clark: Dit is echt interessant. Ik vind het geweldig om te horen hoe de hele organisatie samenkomt om specifiek prioriteit te geven aan toegankelijkheid en er tijd voor vrij te maken. Het bleek bovendien een heel positieve samenwerkingservaring te zijn. Dat klinkt geweldig.

Nu we het toch over samenwerking hebben en over werken als één team over verschillende teams heen: hoe werkt dit wanneer je samenwerkt met een organisatie die misschien meerdere producten in de portefeuille heeft en waarin meerdere teams toegankelijkheidsproblemen in verschillende producten en functies proberen aan te pakken?

Hoe werk je samen tussen productteams om in hetzelfde tempo te werken en de hoeveelheid inspanning en communicatie die nodig is om deze producten uit te brengen zo klein mogelijk te maken?

Prerna Ramachandra: Dat is een goede vraag. Ik denk dat er twee verschillende manieren of twee pijlers zijn om dit probleem aan te pakken.

De eerste pijler is structureel. Als de organisatie een centrale toegankelijkheidsafdeling heeft — en ik denk dat de meeste organisaties tegenwoordig in zekere vorm zo'n afdeling hebben — waar bevindt die afdeling zich dan binnen de organisatie? Als ze binnen één verticale afdeling zit, wordt het erg moeilijk om organisatorische silo's te doorbreken en met andere teams samen te werken.

Je moet er dus echt voor zorgen dat je team op de juiste plek staat. Als dat niet zo is, moet jij als productmanager het werk doen om contact op te nemen met al die andere teams, hun roadmaps te begrijpen en hen te leren kennen, zodat je goed kunt samenwerken. Dat is het eerste punt. Het tweede punt is ervoor zorgen — en ook dat bestaat uit twee delen — dat zowel de persoon die de centrale toegankelijkheidsafdeling beheert en leidt als de productmanagers van de afzonderlijke functieteams voortdurend communiceren over hun roadmaps.

Als je weet wat eraan komt, is dat van groot belang. Dit was volgens mij een van de grootste uitdagingen voor ons team en tegelijk een van de grootste kansen toen ik bij Slack aan toegankelijkheid werkte. Later, toen ik aan het desktopproduct ging werken, ging ik plotseling van het centrale toegankelijkheidsteam naar een van die functieteams zelf.

Het belangrijkste is dat je bij het plannen van de roadmap vanaf het begin de toegankelijkheidsexperts betrekt die je moet betrekken. Het begint al bij het planningsproces en loopt door tot het ontwerpproces. Ik zeg graag dat toegankelijkheid eigenlijk niet bij de engineers begint, ook al is technische expertise nodig.

Soms begint het bij de ontwerper. Als je tools zoals Figma gebruikt, beschikken die over een goede set hulpmiddelen om toegankelijke ontwerpen of een specifieke toegankelijkheidsworkflow binnen je ontwerp te maken. Onze ontwerper was vanaf het begin bij het productontwikkelings- en ontwerpproces betrokken en vroeg: hoe zorg je ervoor dat de ontwerpen die je maakt toegankelijk zijn? Wat werkt wel en wat werkt niet?

Hier komt toekomstgericht denken van pas, zowel voor nieuwe functies als voor bestaande problemen. Als je al een reeks toegankelijkheidsproblemen binnen je product hebt geïdentificeerd, was het kader bijzonder nuttig. Toen ik bij de centrale afdeling werkte, kon ik onmogelijk elke verandering, elke wijziging in de roadmap en alles wat elk team deed bijhouden.

Omdat we deze gecentraliseerde kaders hadden, die iedereen kende, konden productmanagers van functieteams ernaar verwijzen. Ze konden het kader aan de ontwerper geven, het aan hun engineer geven of het zelf bekijken en zeggen: deze toegankelijkheidsbug is op basis van dit kader kritiek, gemiddeld of laag geprioriteerd. Vervolgens konden ze bepalen of ze het probleem onmiddellijk of later moesten prioriteren.

Die centrale normen waren dus zeer nuttig. Ze zorgden ervoor dat iemand zonder die expertise toch iets had om naar te verwijzen wanneer bugs binnenkwamen en konden helpen bij de prioritering. Ze voorkwamen ook dat één persoon voortdurend alle problemen moest coördineren.

Ik wilde voorkomen dat ik als een schooldirecteur moest zeggen wat iedereen moest doen. Niemand wil dat. We zijn allemaal volwassenen. Ik geloof bovendien dat iedereen die erbij betrokken is hier daadwerkelijk om geeft.

Niemand met wie ik sprak zei: ik wil dit niet doen. Iedereen zei: ik vind dit belangrijk en wil ervoor zorgen dat ons product toegankelijk is. Ik weet alleen niet hoe, of ik weet niet of we de bevoegdheid krijgen om dit te prioriteren of tijd krijgen om het te doen. Dat probeerden we op te lossen.

Als je een productmanager van een functieteam bent die zijn product toegankelijk wil maken, kijk dan of je een kader kunt ontwikkelen of met iemand binnen je organisatie kunt samenwerken om een kader te ontwikkelen waar jij en anderen naar kunnen verwijzen. Je hoeft dan niet voortdurend te wachten tot iemand antwoord geeft op de vraag of iets belangrijk is.

Je weet het zelf. Je krijgt meer bevoegdheden. En wanneer je iets nieuws creëert of een nieuw product bouwt, moet je ervoor zorgen dat je vanaf het begin contact kunt opnemen met de mensen met de juiste expertise en toegankelijkheid in het ontwerpproces inbouwt. Zo voorkom je dat deze bugs later binnenkomen en je plotseling moet haasten om ze te prioriteren. Je weet dan dat het product vanaf de lancering toegankelijk zal zijn.

Hannah Clark: Dit is heel interessant. Ik wil nog wat meer praten over implementatie en iteratie. Het is één ding om de functies die je hebt te analyseren en verbeteringen aan de bestaande versie van het product te prioriteren en implementeren, of aan wat je zakelijke klanten vragen. Maar na verloop van tijd worden nieuwe functies geïntroduceerd en raken functies verouderd of worden ze vervangen door updates.

Hoe integreer je dat analyseproces? Wat is de proactieve aanpak om ervoor te zorgen dat toekomstige functies die aan de roadmap worden toegevoegd vanaf dag één toegankelijk zijn?

Prerna Ramachandra: Dat is ook een goede vraag. Ik geef een heel specifiek voorbeeld. Omdat je het inwerken van gebruikers in het begin specifiek noemde: wanneer je je roadmap maakt, moet je naar elke functie en alles wat er gebeurt kijken, evenals naar alles wat je nieuw bouwt, en beseffen dat je over toegankelijkheid moet nadenken.

Als productmanager moet je dat iedere keer in gedachten houden. Je moet ook weten wanneer je iets moet onderzoeken. Dat is deels productmanagerintuïtie die zich in de loop van de tijd ontwikkelt en deels het bekijken van echte data. Je moet weten welke klanten binnen je klantenbestand je kunnen helpen bepalen of iets toegankelijk is.

Als productmanagers vertrouwen we sterk op gebruikersonderzoek om te bepalen wat we moeten bouwen. We vergeten echter vaak dat er klanten en mensen zijn die ons product gebruiken op manieren die vereisen dat ze gebruikers met een beperking zijn en deze toegankelijkheidsfuncties gebruiken. Zorg er dus voor dat je hen vanaf het begin bij je gebruikersonderzoek betrekt.

Als je vooruitkijkt, is het voorbeeld dat ik zou geven het inwerken van gebruikers. Een ander functiegebied dat we tijdens onze eerste analyse binnen Slack vonden, was de onboardingervaring. Daarin zaten toegankelijkheidslacunes die we wilden aanpakken. We wisten echter ook dat het onboardingteam van Slack bezig was met een grote herinrichting van de onboardingervaring, omdat het product sinds de eerste versie was geëvolueerd en gegroeid.

Ze wilden ervoor zorgen dat alles werd meegenomen. We konden daarom vanaf het begin met dat team samenwerken om ervoor te zorgen dat de kernflow voor het inwerken van gebruikers die ze opnieuw ontwierpen toegankelijk was. We deden dat door vanaf het begin nauw betrokken te zijn bij hun roadmapplanning.

Dit was een groot project. Juist bij grote projecten is het volgens mij heel belangrijk om de juiste experts te betrekken. Onze ontwerper was gedurende het hele ontwerpproces betrokken. Tijdens gebruikersonderzoek, gebruikerstests en het maken van ontwerpen in Figma stelde hij parallel aan het team de toegankelijkheidsspecificaties voor die ontwerpen op, zodat alles vanaf het begin toegankelijk was.

Dat was hetzelfde proces dat we bij Slack gebruikten toen we de desktopapp opnieuw ontwierpen. Daarnaast zagen we een echte kans voor een onboardingervaring die specifiek rond toegankelijkheid was opgebouwd voor de gebruikers die dat nodig hadden.

Het beste voorbeeld hiervan is volgens mij Apple. De producten van Apple zijn naar mijn mening heel sterk op het gebied van toegankelijkheid. Wanneer je een nieuwe Mac koopt, kun je ervoor kiezen om een onboardingworkflow te doorlopen waarin specifiek wordt getoond waar de verschillende toegankelijkheidsfuncties zich bevinden, hoe je ze gebruikt enzovoort.

Ons team — het toegankelijkheidsteam — bouwde daarom die kernervaring voor het inwerken van gebruikers. Zodra je de app opent en aan de gewone onboardingflow begint, vragen we of toegankelijkheid belangrijk voor je is. Als je ja zegt, leiden we je stap voor stap door een workflow waarin wordt getoond waar de verschillende hulpmiddelen zich bevinden, hoe je toetsenbordnavigatie gebruikt, welke opdrachten er zijn enzovoort.

We konden ook de data gebruiken. Wanneer iemand aangeeft geïnteresseerd te zijn in toegankelijkheid, leiden we die persoon door de workflow. Vervolgens konden we strategisch verschillende tooltips in het product tonen, zodat die persoon de toegankelijkheidsreis kon voortzetten.

Dat werd allemaal mogelijk doordat we eerst zagen dat er een groot gat was: er was geen onboardingervaring voor toegankelijkheid. Daarna spraken we met veel klanten. We spraken met klanten die toegankelijkheidsbugs bij ons meldden en ons hielpen te begrijpen hoe toegankelijk het product was.

Veel van hen zeiden: er was niets dat me hielp begrijpen hoe ik door Slack moest navigeren. Ik moest het zelf uitzoeken. De meesten zijn dat helaas gewend, omdat veel van onze producten dit niet voor hen doen. Naar mijn mening is het nog steeds niet de ideale workflow.

Wanneer je dus vooruitkijkt en nadenkt over welke producten je wilt bouwen en hoe je product eruitziet, moet je sterk vertrouwen op gebruikersonderzoek. Ik weet niet waarom hier in onze sector niet meer over wordt gesproken, maar je moet met je klanten praten. Niets vervangt dat. Ik denk niet dat AI je gaat vertellen wat je moet bouwen. Dat zijn de mensen die het gebruiken.

Je moet met hen praten. Tegenwoordig zijn er bedrijven en hulpmiddelen die daarbij helpen. Als je bijvoorbeeld een groot bedrijf bent en je klanten zakelijke klanten zijn, kan ik je garanderen dat zij een personeelsnetwerk of een soortgelijke werknemersgroep hebben met werknemers met een beperking. Ik ben ervan overtuigd dat die groep zeer actief zal zijn bij het controleren van hun leveranciers.

Dat is een bron die je kunt benutten. Een andere bron is een bedrijf waarmee we samenwerkten, Fable. Dat bedrijf werft specifiek gebruikers met een beperking voor gebruikerstests op het gebied van toegankelijkheid. Het is vergelijkbaar met usertesting.com, maar dan specifiek voor toegankelijkheid. Werk dus met dergelijke partijen en organisaties samen om te begrijpen wat je bouwt en hoe je het bouwt.

Wanneer je met het ontwerpproces en het iteratieproces begint, moet je iemand betrekken. Laat je ontwerper een cursus volgen over ontwerpen voor toegankelijkheid of betrek vanaf het ontwerpproces iemand met expertise op het gebied van toegankelijkheid. Zorg ervoor dat je ontwerpen toegankelijkheidsspecificaties hebben.

Daar zullen je engineers naar verwijzen wanneer ze bepalen hoe ze iets moeten bouwen. Zorg ervoor dat de ontwerpers en toegankelijkheidsexperts betrokken zijn bij het testen. Zo zorg je ervoor dat alles wat je bouwt ook in de toekomst toegankelijk blijft, in plaats van later opnieuw te moeten beginnen.

Hannah Clark: Iedereen die al langer naar deze show luistert, weet dat ik van voorschrijvend advies houd, met heel specifieke details. Bedankt dus voor deze concrete aanbevelingen. Om alles af te ronden, want we gaan zo meteen afsluiten, wil ik nog zorgen dat we analytics bespreken.

We hadden het niet zo lang geleden over data. Ik wil terugkomen op de vraag hoe we het succes meten van onze toegankelijkheidsfuncties en van alles wat we met zoveel gezamenlijke inspanning hebben geïmplementeerd. Wanneer je bijvoorbeeld de activatiegraad of andere belangrijke adoptie-indicatoren meet voor de algemene bevolking, kijk je waarschijnlijk naar een heel ander proces, of op zijn minst naar een enigszins ander proces, om te segmenteren hoe effectief je toegankelijkheidsfuncties zijn.

Het is een vraag met meerdere onderdelen. Ten eerste: hoe segmenteer je wat je meet om ervoor te zorgen dat je het succes van de toegankelijkheidsfuncties meet die je hebt gebouwd, in plaats van alleen het product als geheel? Zijn er hulpmiddelen die je daarvoor zou gebruiken? Heb je daarnaast nog andere tips om ervoor te zorgen dat je dit soort data in toekomstige iteraties kunt integreren?

Prerna Ramachandra: Zeker. Ik ga een antwoord geven waar veel productmanagers waarschijnlijk ongemakkelijk van worden. Het is ook iets waar ik me ongemakkelijk bij voel: je kunt niet vertrouwen op kwantitatieve data om te begrijpen of je toegankelijkheidsfuncties werken en of je product toegankelijk is.

Dat komt deels doordat je gebruikers moreel en ethisch gezien niet echt kunt segmenteren op basis van toegankelijkheid. Je probeert dan aannames te doen over de vraag of iemand een beperking heeft. Zelfs als je meet hoeveel gebruikers toetsenbordnavigatie gebruiken of hoeveel gebruikers schermlezeropdrachten hebben ingeschakeld, sluit je mogelijk een grote groep van de bevolking uit.

Denk bijvoorbeeld aan neurodivergentie. Kunnen mensen met neurodivergentie je product gebruiken of is het te overweldigend? Daar zijn bepaalde specifieke functies voor. In Slack en veel andere producten met enige vorm van animatie kun je die animatie uitschakelen, omdat deze bij sommige mensen epileptische aanvallen kan veroorzaken. Ook dat is moeilijk te meten.

Je kunt dus maar zoveel halen uit kwantitatieve metingen. Het is moeilijk om gebruikers te segmenteren op de manier waarop je dat normaal zou doen, omdat je dan veel aannames over iemand maakt die je doorgaans niet wilt maken. Bovendien is het waarschijnlijk niet erg effectief. Er zijn ook verborgen beperkingen en je houdt geen rekening met de situationele aspecten waar ik aan het begin van de aflevering over sprak.

Wat volgens mij het beste werkt om toegankelijkheid te meten en te bepalen of je product toegankelijk is, is teruggaan naar je gebruikers en het hun gewoon vragen. Kwalitatief onderzoek is naar mijn mening de beste manier om het succes van toegankelijkheid te meten. Dat is ook gebaseerd op wat ik in het verleden en nu tijdens mijn werk aan toegankelijkheid heb gezien.

Ik geef nog een heel specifiek voorbeeld. Een andere toegankelijkheidsfunctie die we bij Slack bouwden, was in feite een API die door veel verschillende teams kon worden gebruikt om eenvoudig toetsenbordnavigatie in hun product te bouwen. Toetsbordnavigatie vereist namelijk gespecialiseerde kennis.

De API moest het voor teams gemakkelijker maken. In dat geval maten we succes door te kijken hoeveel teams de API gebruikten. Het was niet verplicht; teams konden proberen dit zelf te bouwen. We zeiden daarom: als je team deze API gebruikt, betekent dat dat wij als toegankelijkheidsteam succesvol waren in het bouwen van iets dat jullie konden gebruiken en waarvan we weten dat het goed werkt.

Dat was dus minder een gebruikersmeting en meer een interne teammeting. Zoals ik zei, maten we succes voor onze gebruikers vooral door het hun te vragen. Toen we de onboardingworkflow lanceerden, kregen we wel kwantitatieve data over hoeveel gebruikers voor de onboardingervaring voor toegankelijkheid kozen.

Voor het grootste deel hadden we echter hard gewerkt om groepen gebruikers samen te stellen met wie we over toegankelijkheid konden praten. Bij iedere lancering doe je waarschijnlijk kwalitatief onderzoek om de impact te begrijpen. Wij zorgden ervoor dat die groepen gebruikers bevatten die naar toegankelijkheid hadden gevraagd, toegankelijkheidsfuncties gebruikten enzovoort.

Het ging voor een groot deel om gesprekken, kwalitatieve metingen en kwalitatief onderzoek. Je wilt namelijk niet alleen weten of iemand je product gebruikt, maar ook of iemand het goed kan gebruiken om de taken uit te voeren die hij of zij wil uitvoeren.

Als je product het kwantitatief heel goed doet bij de meerderheid van de gebruikers, geeft dat al een indicatie van de vraag of je product toegankelijk is. Als je echter met specifieke gebruikers over toegankelijkheid wilt praten, moet je die gebruikers vinden en specifiek kwalitatief onderzoek en analyse uitvoeren om te controleren of alles werkt zoals je wilt.

Ik weet dat dit geen geweldig antwoord is, omdat je als productmanager op zoek bent naar cijfers en data. Ik denk echter dat het deel van je werk als productmanager is om je comfortabel te voelen met dat niveau van onzekerheid. En ik wil hieraan toevoegen dat je nooit perfect zult zijn.

Geen enkel product zal elk vakje op het gebied van toegankelijkheid perfect kunnen afvinken. Veel ervan is immers situationeel. Daarom is het zo belangrijk om met je gebruikers in gesprek te blijven gaan. Vooral gebruikers die toegankelijkheid belangrijk vinden, zullen zich luid laten horen, omdat ze niet gewend zijn dat ze de dingen krijgen die ze nodig hebben om hun werk gewoon te doen.

Ze moeten zich dus laten horen om te kunnen overleven en hun werk goed te kunnen doen. Ik denk dat je daar een enorme bron hebt. Iets wat ik in mijn loopbaan als productmanager beter dan ooit heb moeten leren, is dat ik tijdens mijn werk aan toegankelijkheid echt het belang van praten met en luisteren naar gebruikers begreep. Zij kunnen je de beste informatie geven over hoe je product presteert.

Er wordt niet genoeg gesproken over het belang van kwalitatief onderzoek en die menselijke verbinding. Ik denk echter dat dit je echt zal vertellen of je product werkt. En als het om toegankelijkheid gaat, is het heel belangrijk om met mensen te praten.

Hannah Clark: Daar ben ik het helemaal mee eens. Dit is inderdaad een show die sterk voor gebruikersonderzoek pleit. We hebben een tijdje geleden een aflevering gemaakt met Steve Portigal over hoe je gebruikers interviewt. Dat is een van onze favoriete afleveringen ooit, omdat het allemaal draait om met mensen praten, hen hun authentieke ervaring laten vertellen, het gesprek niet proberen te sturen en je eigen vooroordelen uit te schakelen. Dat is zo belangrijk voor een productontwikkelingsproces.

Bedankt, dit was een ontzettend leuk gesprek. Ik waardeer je perspectief op dit onderwerp enorm. Je vertelde zulke specifieke verhalen over een bekend product, waardoor we allemaal goed kunnen begrijpen hoe deze functies tot leven komen.

Ik waardeer dit echt. Waar kunnen mensen je werk online volgen of contact met je opnemen?

Prerna Ramachandra: Ik ben te vinden op LinkedIn. Het is gewoon mijn voor- en achternaam: Prerna Ramachandra. Je kunt ook contact met me opnemen via mijn website: PrernaRamachandra.me.

Hannah Clark: Geweldig. Heel erg bedankt dat je hier was.

Prerna Ramachandra: Heel erg bedankt, Hannah. Dit was geweldig.

Hannah Clark: Bedankt voor het luisteren. Abonneer je voor meer geweldige inzichten, praktische handleidingen en beoordelingen van hulpmiddelen op onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit beluisteren door je te abonneren op The CPO Club, waar je je podcasts ook beluistert.