Hvorfor tilgjengelighet må ha høyeste prioritet i 2025

Les transkripsjonen:

Vi prøver ut transkribering av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom roboten ikke er korrekt 100 % av tiden.

Hannah Clark: Jeg tror det er på tide at vi innrømmer at det ofte gjør oss ukomfortable å snakke om tilgjengelighet. I en produktsammenheng prioriterer vi vanligvis funksjoner med størst effekt og høyest andel brukere. Når vi derfor snakker om å bygge for tilgjengelighet, kan det føles som et betent tema. Hvor på veikartet skal vi plassere funksjoner som har stor betydning for en relativt liten andel brukere? Hvordan vet vi hvordan tilgjengelighet bør se ut for produktet vårt når tilgjengelighet betyr forskjellige ting for forskjellige mennesker? Og hvordan gjør vi alt dette uten å trekke antakelser eller utilsiktet fornærme brukerne vi prøver å støtte?

Min gjest i dag er Prerna Ramachandra, ledende produktsjef hos Yahoo. Før hun begynte i Yahoo, var Prerna senior produktsjef i Slack, der hun hadde en sentral rolle i å kartlegge og utvikle tilgjengelige funksjoner for produktets mangfoldige brukerbase. Det du skal høre nå, er delvis en casestudie og delvis en veiledning om forretningsgrunnlaget for tilgjengelighet og de mest effektive og etiske måtene å gjøre produktet ditt mer inkluderende for alle på. La oss sette i gang.

Velkommen tilbake til The CPO Club-podkasten. I dag er vi her sammen med Prerna Ramachandra.

Prerna, tusen takk for at du tok deg tid fra den travle timeplanen din til å være med oss i dag.

Prerna Ramachandra: Tusen takk for invitasjonen. Det er flott å være her.

Hannah Clark: Kan du fortelle oss litt om bakgrunnen din og hvordan du kom dit du er i dag?

Prerna Ramachandra: Jeg er for tiden ledende produktsjef hos Yahoo. Jeg har vært her i omtrent halvannet år nå. Før Yahoo jobbet jeg i Slack, og jeg var der rett før selskapet ble kjøpt opp av Salesforce og videre gjennom oppkjøpet. I Slack ledet jeg hovedsakelig teamet for tilgjengelighet og designsystemer før jeg gikk over til å jobbe med kjerneopplevelsene i skrivebordsappen deres.

Arbeidet mitt i de to teamene hang på en måte sammen, og det vil jeg gjerne komme nærmere inn på senere i dag. Før Slack jobbet jeg i Washington Post, der jeg ledet redesignet av hjemmesiden deres og overgangen til en ny plattform for artikkelsiden. Jeg har altså erfaring fra mediebransjen og fra store teknologiselskaper.

Jeg pleier å si at interessen min for produktarbeid særlig ligger i skjæringspunktet mellom produkt, teknologi og historiefortelling – og i måtene mennesker bruker historier til å kommunisere med hverandre på, samt hvordan teknologi kan være et effektivt verktøy for dette.

Hannah Clark: Det passer jo perfekt, siden du er her i dag for å fortelle historien din.

Det er tydeligvis noe vi begge brenner for, nemlig historiefortelling, og i dag skal vi fokusere på noe som kanskje er litt mer spesialisert, men som definitivt er et tema jeg mener vi ikke snakker nok om: tilgjengelighet – og mer spesifikt skjæringspunktet mellom tilgjengelighet og brukerintroduksjon.

La oss begynne med dette: Basert på erfaringen din fra dette feltet, hvorfor vil du si at tilgjengelighet ofte blir behandlet som noe man tenker på i etterkant? Og hva er forretningsgrunnlaget for å bygge det inn fra starten av?

Prerna Ramachandra: Jeg vil begynne med en påstand jeg virkelig tror på: Vi lever i en tid der jeg ikke lenger mener at teknologi er en luksus.

Jeg vokste opp på nittitallet – jeg avslører alderen min litt her – da teknologi fortsatt var en nyhet. Internett var fortsatt en nyhet. Ikke alle hadde tilgang til det, og ikke alle trengte det, men vi lever i en tid der alle de grunnleggende tjenestene våre på en eller annen måte er digitalisert. Det betyr at alle mennesker i verden bør kunne bruke dem på en enkel måte.

Mennesker med funksjonsnedsettelser blir generelt behandlet som en ettertanke i samfunnet vårt. Mange av tjenestene våre er ikke særlig tilgjengelige, men teknologi har en unik mulighet til å bygge inn tilgjengelighet i det den gjør – ofte ganske enkelt. Teknologi kan også gjøre livet mye enklere for alle, inkludert mennesker med funksjonsnedsettelser.

Derfor mener jeg at dette er en av hovedgrunnene til at det er viktig å prioritere tilgjengelighet ut fra et moralsk og etisk perspektiv. Når tilgjengelighet behandles som en ettertanke, er det helt enkelt fordi de fleste organisasjoner ikke fullt ut forstår forretningsgrunnlaget. For det første. For det andre tror jeg det skyldes at folk oppfatter tilgjengelighet som noe som krever svært dyp teknisk ekspertise.

De føler derfor ikke alltid at de har den kompetansen, eller de tenker ikke på tilgjengelighet. Det er ikke bygget inn i prosessene våre. Resultatet er at vi ignorerer det helt til noen blir bekymret for å bli saksøkt eller for å miste en kunde med tilgjengelighetsbehov.

Plutselig må teamene dine skynde seg for å finne ut hva som er galt, og hvordan det kan bygges inn. Når det gjelder den andre delen av spørsmålet ditt – hva som er forretningsgrunnlaget for tilgjengelighet – var jeg inne på dette i det første poenget mitt. For at teknologi skal lykkes, ønsker du flere brukere, ikke sant? De fleste av oss tjener mer jo mer produktet vårt blir brukt.

Flere bruker produktet når de får tilgang til det. På et grunnleggende nivå er tilgjengelighet viktig fordi flere kan bruke produktene dine, og når flere bruker produktene dine, tjener du mer penger. På den andre siden ønsker du ikke å bli saksøkt, for da kan du ende opp med å måtte betale store summer.

Det finnes altså et forretningsgrunnlag for tilgjengelighet fra begge perspektiver. Jeg vil også legge til noe jeg skal gå nærmere inn på, og som jeg personlig brenner for innen tilgjengelighetsfeltet: Vi begrenser ofte ideen om tilgjengelighet til å sikre at produktet kan brukes med skjermlesere eller at man kan navigere med tastaturet.

Men jeg mener vi må gå videre enn denne definisjonen og virkelig tenke på hvordan vi sikrer at alle, i enhver situasjon, kan bruke produktet. Vi tenker ofte ikke på tilgjengelighet som noe som kan være situasjons- og avhengighetsbetinget.

Et eksempel jeg ofte bruker, er talekommandoer eller det å bruke stemmen til å styre produktet. Vi tenker gjerne at dette er enklere hvis man har nedsatt syn. Faren min er for eksempel mye eldre og kan ha problemer med å se liten tekst på skjermen, så han liker å bruke stemmen til å styre mange ting på telefonen.

Men hvis du kjører bil, har du heller ikke hendene tilgjengelig, og du bruker ikke synet på samme måte. Da kan du fortsatt bruke talekommandoer. Når du tenker på tilgjengelighet, kan du altså se på det som noe som omfatter en situasjon, snarere enn et individ eller et individuelt problem. Det utvider definisjonen din og gjør deg oppmerksom på at du lar et stort bruksområde og en stor brukergruppe ligge ubrukt.

Det er sannsynligvis ikke bra for virksomheten din. Derfor finnes det et praktisk forretningsgrunnlag for å prioritere dette helt fra begynnelsen.

Hannah Clark: Det treffer virkelig. Jeg tror dette gjelder tilgjengelighet i digitale produkter så vel som i fysiske produkter og fysiske rom. Jeg liker innrammingen av å være tilgjengelig i en situasjon, snarere enn for et bestemt bruksområde. Jeg opplevde selv dette da jeg trillet en barnevogn og la merke til hvor mange steder som var utformet for én enkelt fotgjenger, på rekke og rad.

Da innser man at det finnes så mange ulike situasjoner der noen kan ha behov for en tilgjengelighetsfunksjon eller tilrettelegging, eller for at noe er utformet med tilgjengelighet i tankene. Dette gjelder på tvers av mange aldre, livsfaser og situasjoner. Jeg liker virkelig denne måten å tenke på, og jeg vil gjerne gå litt dypere inn i det om litt.

Du nevnte at du ville snakke mer om erfaringen din fra Slack. Jeg vil gjerne gå inn på noen av prosjektene du jobbet med der, særlig arbeidsflyter for brukerintroduksjon sett gjennom et tilgjengelighetsperspektiv.

Kan du beskrive hvordan du gikk fram for å analysere situasjonen og vurdere produktets daværende tilgjengelighet, og hvordan dere gikk videre derfra?

Prerna Ramachandra: Da jeg begynte i Slack, var et av de første prosjektene mine faktisk å finne ut hvor tilgjengelig produktet var, og hva vi kunne gjøre med det du nettopp beskrev.

Hvilke rammeverk hadde vi for å analysere produktets tilstand? Da jeg begynte i Slack, hadde vi ingenting. Slack var på et stadium der selskapet satset stort på bedriftskunder etter å ha gjort det godt i markedet for små og mellomstore virksomheter. I jakten på disse store bedriftskundene innså man at det fantes strenge krav til leverandørene når det gjaldt tilgjengelighet.

Det første jeg gjorde, var derfor å utvikle et internt sett med standarder som vi kalte Slacks tilgjengelighetsstandarder. De bygde på eksisterende standarder som WCAG, men tok også hensyn til Slacks særegne produkter og hva tilgjengelighet ville bety for disse produktene. Vi satte sammen et rammeverk som gjorde det mulig å gå gjennom produktet og analysere om det oppfylte bestemte kriterier.

Som et resultat av analysen ga vi ulike funksjoner i produktet en karakter – A, B eller C – for å vurdere hvor tilgjengelige de var. Dette var både en kvantitativ og kvalitativ analyse. Vi hadde en liste med kriterier. Noen var basert på svært enkle ting, som oppgavehåndtering: Kan alt brukes med tastaturet?

Kan alt brukes med skjermleser? Andre ting var litt mer uhåndgripelige. Slack er for eksempel et kommunikasjonsprodukt, og noe av det produktet gjør svært godt, er varsler. Du må få varsler, men dette var under pandemien, da mange jobbet hjemmefra.

Mange jobbet eksternt, og vi fikk tilbakemeldinger fra kunder om at det var for mange varsler. Dette påvirket særlig personer som identifiserte seg som nevrodivergente, fordi de kunne føle seg overveldet og få problemer med å utføre oppgavene sine. Det var litt mer uhåndgripelig.

Det er ikke noe man vanligvis ser i mange av retningslinjene for tilgjengelighet. Derfor tok vi alt dette inn i rammeverket. Vi brukte rammeverket til å gi karakterer til hvert funksjonsområde, og karakterene var utelukkende basert på om brukerne kunne utføre oppgaven, og hvor raskt de kunne gjøre det.

Det hjalp oss med å markere hvor presserende problemene var, hva som var viktigst, og hva som ikke var det. Dette var det første vi gjorde. Vi brukte analysen til å kartlegge produktets tilstand, og gikk deretter til ledelsen og sa: «Dette er hele produktet. Slik fordeler det seg. Dette er problemene vi mener må løses umiddelbart, fordi de i praksis gjør produktet grunnleggende ubrukelig for en gruppe kunder.»

Det fine med dette rammeverket var også at det ikke bare ble brukt på eksisterende produkter. Hvis du utviklet nye produkter, kunne du bruke det samme rammeverket til å forstå hva som måtte kontrolleres før lansering.

Det var også noe man kunne bruke i framtidig planlegging og for framtidige produkter. Etter dette gjorde jeg mye arbeid for å samarbeide med de enkelte teamene, slik at de visste hva de skulle prioritere basert på rammeverket.

Alle har et veikart. Ingen ønsker å rive opp veikartet sitt for å håndtere noe nytt som dukker opp. Alle har forpliktet seg til en rekke oppgaver. Jeg jobbet derfor med de enkelte teamene slik at de visste nøyaktig hvilke punkter som var kritiske. Da vi gikk til ledelsen samlet og sa «Dette må prioriteres. Dette må løses», kunne vi presentere en tydelig plan og forklare avveiningene.

Hva ville innsatsen for å løse hvert punkt være? Hva måtte skyves ut av veikartet for å få plass til dette? Og hvilken effekt ville det ha? Jeg mener alltid at når det gjelder tilgjengelighet – og dette gjelder mye innen produktarbeid – må du forstå balansen mellom å samarbeide med teamet som har ansvar for funksjonsområdet, og å finne ut hvordan du skal samarbeide med ledelsen for å få støtte til å prioritere arbeidet.

Jeg var heldig, for ledelsen i Slack var svært opptatt av å prioritere dette arbeidet og gjøre det riktig. Det de trengte fra oss, var tydelig informasjon: Hva er innsatsen? Hva er tidslinjen? Hva er avveiningene? Og hvilken effekt får det? Det var dette vi kunne presentere.

Det krevde mye arbeid med mennesker og ledelse, samt mye teknisk samarbeid med utviklerne for å gi dem analysen de trengte.

Hannah Clark: Dette er utrolig viktig. Det finnes ikke noe mer avgjørende for å sikre at disse funksjonene faktisk blir levert, enn å få støtte – og som du sier, gjøre det riktig.

Jeg vil gjerne gå litt mer i detalj på avveiningene du nevnte. Hvordan kan en slik avveining se ut? Hvis du skulle gi et eksempel på hvordan dette kan presenteres, hvordan ville du formulert det for å sette alt i sammenheng og forklare prosjektets omfang og hvor det havner på listen over kritiske oppgaver?

Prerna Ramachandra: Teamet som etter min vurdering ble mest påvirket av arbeidet vårt, var teamet som jobbet med selve meldingsfunksjonen. De eide det største området – alt fra opplevelsen av å skrive og sende en melding, til å motta en melding i hele meldingsområdet.

De hadde også medlemmer som eide kanaler. Hvis du bruker Slack, vet du at dette er kjernen i Slack-opplevelsen. Det var derfor naturlig at de hadde flest punkter å håndtere. De eide ikke bare det største området, men også det mest kritiske området.

Slack eksisterer fordi folk sender og mottar meldinger. Det var derfor det mest kritiske området, og det hadde flest problemer med stor innvirkning på tilgjengeligheten.

For å gi et helt konkret eksempel vil jeg bruke hypotetiske tall. Jeg gikk til dem med en liste på 100 problemer og sa at dette var alt som måtte håndteres for å sikre at produktet i det minste var brukbart for alle som bruker skjermleser, navigerer med tastatur eller har en funksjonsnedsettelse.

Det første jeg gjorde, var å sette meg ned med produktsjefen og si: «Dette er listen over problemer vi har identifisert basert på rammeverket vårt.» Dette var et kritisk steg, fordi produktsjefen kunne samarbeide med meg og si: «Jeg forstår hvorfor du mener at disse 100 punktene er kritiske, men jeg mener faktisk bare at 80 prosent er kritiske.»

De hadde brukerdata og informasjon om hvordan folk brukte produktet. Hvis vi mente at en bestemt arbeidsflyt var kritisk, kunne de forklare at brukerne faktisk gjorde det på en annen måte, og at det fantes omveier og løsninger. Den første analysen var derfor viktig, fordi vi kunne redusere listen fra 100 til 80.

For alle som har en sentral tilgjengelighetsorganisasjon, er det svært viktig å ha denne samtalen med produktsjefen for selve produktet. De kjenner brukerne best. Vi kunne derfor redusere listen ganske mye.

Deretter så vi på hvilke problemer som lå i produkt- eller funksjonsområder som snart skulle redesignes eller avvikles. Hvis et bestemt område skulle redesignes, kunne vi sørge for at det ble tilgjengelig i det nye designet, uten å måtte løse problemet umiddelbart. Hvis området skulle avvikles, trengte vi heller ikke å løse problemet nå. Dermed forsvant kanskje ytterligere ti problemer.

Da satt vi igjen med rundt 70 problemer. Vi satte oss ned med utviklerne i teamet. Her er det svært viktig å ha minst én intern ekspert på tilgjengelighet. Vi var heldige og hadde en svært dyktig utvikler med denne kompetansen. Han kunne samarbeide med utviklingsteamet og hjelpe dem med å beregne innsatsen for hvert av de 70 problemene.

Deretter satte vi oss ned med produktsjefen og spurte hvor mange av de 70 problemene som kunne prioriteres i den pågående eller kommende sprinten i løpet av kvartalet, uten at noe måtte skyves på. Hvor mye kunne de få plass til? De fleste team har vanligvis litt buffer, særlig team som jobber med et allerede lansert produkt og må håndtere innkommende feil og problemer.

Dette kunne derfor inngå i den eksisterende arbeidsflyten. Teamet sa kanskje at de kunne håndtere 20 av problemene uten stor påvirkning på veikartet. Da trengte vi ikke å ta dette opp med ledelsen. Vi satt igjen med omtrent halvparten.

For de resterende 50 problemene måtte vi spørre hvilke større produktområder som kunne bli utsatt eller forsinket dersom alle problemene ble prioritert. Det var da vi trengte ledelsen for å hjelpe oss med å navigere og forhandle om hva som skulle gjøres.

Det fantes et funksjonsområde med en funksjon teamet skulle lansere i løpet av kvartalet. Den var viktig for en stor kunde, men den samme kunden var også den som ba oss løse tilgjengelighetsproblemene innen en bestemt tidsramme.

Vi kunne derfor gå til ledelsen og si: «Dette er avveiningen vi står overfor.» Med deres hjelp kunne vi samarbeide med kundens kundeansvarlige, gå til kunden og spørre hva de helst ville se først.

Det viktigste er å gjøre så mye som mulig på ditt eget nivå – som individuell bidragsyter, senior produktsjef, ledende produktsjef eller gruppeleder – slik at du har prioritert alt arbeidet du kan håndtere kreativt i teamet. Ledelsen bør først involveres når det gjelder større områder.

I dette tilfellet var det nyttig at den samme kunden ble påvirket av begge problemsettene. Vi kunne samarbeide med kunden om hva de ønsket først, og hva som kunne komme senere. På grunnlag av dette kunne vi si: «La oss løse disse ti problemene i dette kvartalet, slik at den andre funksjonen ikke blir særlig forsinket. La oss løse disse ti problemene i neste kvartal.»

Dette var det første kvartalet vi gjorde alt dette. I de påfølgende kvartalene kunne vi allerede i planleggingssyklusen sette av dedikert tid der teamene bare jobbet med tilgjengelighet.

Her er det viktig å involvere hele organisasjonen. Vi arrangerte egne tilgjengelighetssprinter. Vi la dem ofte til den globale dagen for bevissthet om tilgjengelighet, når det passet med kvartalet. Alle i teamet, på tvers av utviklingsgruppene, samarbeidet om tilgjengelighetsproblemer i løpet av sprinten. Det skapte også et godt fellesskap.

Vi hadde dessuten noen verksteder der vi lærte teamene om tilgjengelighet. Det fungerte svært godt, men jeg kan si at det kreves mye hardt arbeid i begynnelsen. Når det finnes store avveininger mellom funksjoner, må ledelsen involveres for å hjelpe deg med å forhandle om hva som skal prioriteres, og når.

Hannah Clark: Dette er veldig interessant, og jeg liker virkelig å høre om hvordan hele organisasjonen samlet seg for å prioritere tilgjengelighet og sette av tid til det. Det høres også ut som det ble en svært positiv arbeidsopplevelse.

Nå som vi snakker om samarbeid og det å jobbe på tvers av team, lurer jeg på hvordan dette fungerer i en organisasjon med flere produkter i porteføljen, der flere team forsøker å løse tilgjengelighetsproblemer på tvers av ulike produkter og funksjoner.

Hvordan samarbeider man mellom produktteam for å jobbe samordnet og redusere mengden arbeid og kommunikasjon som kreves for å lansere disse produktene?

Prerna Ramachandra: Det er et godt spørsmål. Jeg mener det finnes to ulike måter, eller to pilarer, for å håndtere dette problemet.

Den første pilaren er strukturell. Hvis organisasjonen har en sentral tilgjengelighetsorganisasjon – og jeg tror de fleste organisasjoner i dag har dette i en eller annen form – må man spørre hvor den er plassert i organisasjonen. Hvis den ligger under én enkelt vertikal, blir det svært vanskelig å bryte gjennom organisatoriske siloer og samarbeide med andre team.

Du må derfor sikre at teamet er riktig plassert. Hvis det ikke er det, må du som produktsjef gjøre arbeidet med å kontakte de andre teamene, forstå veikartene deres og bli kjent med dem, slik at dere kan samarbeide godt.

Den andre delen handler om å sikre – og dette gjelder også på to nivåer – at både personen som leder den sentrale tilgjengelighetsorganisasjonen og produktsjefene i de enkelte funksjonsteamene kommuniserer jevnlig om veikartene sine.

Hvis du vet hva som kommer, blir planleggingen enklere. Dette var en av de største utfordringene og samtidig et av de største mulighetsområdene for teamet vårt da jeg jobbet med tilgjengelighet i Slack. Senere, da jeg begynte å jobbe med skrivebordsproduktet, gikk jeg plutselig fra å være en del av det sentrale tilgjengelighetsteamet til selv å være del av et funksjonsteam.

Det viktigste er å sørge for at du involverer tilgjengelighetsekspertene allerede når veikartet planlegges. Det starter i planleggingsprosessen og fortsetter gjennom designprosessen. Jeg liker å si at tilgjengelighet ikke nødvendigvis begynner hos utviklerne, selv om det krever utviklingskompetanse.

Noen ganger begynner det hos designeren. Hvis du bruker verktøy som Figma, har de gode verktøy for tilgjengelig design og arbeidsflyter som er spesifikke for tilgjengelighet. Designeren vår var derfor involvert helt fra starten av produktutviklingen og designprosessen. Han kunne spørre hvordan vi sikret at designene var tilgjengelige, hva som fungerte, og hva som ikke fungerte.

Dette er nyttig både for framtidig planlegging og for eksisterende problemer. Hvis du allerede har identifisert en rekke tilgjengelighetsproblemer i produktet, kommer rammeverket virkelig til sin rett.

Selv om jeg gjorde mitt beste, kunne jeg ikke holde oversikt over alle endringer, alle endringer i veikartet og alt teamet gjorde da jeg jobbet i den sentrale organisasjonen.

Fordi vi hadde et sentralisert sett med rammeverk som alle kjente til, kunne en produktsjef i et funksjonsteam bruke det som referanse, gi det videre til designeren eller utvikleren og selv undersøke om en tilgjengelighetsfeil var kritisk, middels eller lavt prioritert.

Da kunne de selv avgjøre om den måtte prioriteres umiddelbart eller kunne vente. Det var svært nyttig å ha sentrale standarder, fordi også personer uten denne ekspertisen hadde noe å støtte seg på når feil oppstod.

Det betydde også at én enkelt person ikke måtte forsøke å holde styr på alt og hele tiden spørre om andre gjorde det de skulle. Jeg ønsket ikke å være som en skoleinspektør som forteller folk hva de skal gjøre. Ingen ønsker det. Vi er alle voksne mennesker, og jeg tror at alle som er involvert faktisk bryr seg om dette.

Ingen jeg snakket med sa at de ikke ville gjøre det. Alle sa at de brydde seg om tilgjengelighet og ønsket å sikre at produktet var tilgjengelig. De visste bare ikke alltid hvordan, eller om de ville få myndighet og tid til å prioritere det. Det var dette vi prøvde å løse.

Hvis du er produktsjef for en funksjon og prøver å gjøre produktet ditt tilgjengelig, bør du undersøke om du kan utvikle et rammeverk, eller samarbeide med noen i organisasjonen om å utvikle ett. Da slipper du hele tiden å vente på at noen skal svare på om noe er viktig. Du vet det selv, du får myndighet, og du kan skape noe nytt.

Når du bygger et nytt produkt, må du sørge for å involvere personer med riktig kompetanse og bygge inn tilgjengelighet i designprosessen helt fra begynnelsen. Da unngår du at feil dukker opp senere og tvinger deg til å skynde deg med prioriteringen. Du vet at produktet vil være tilgjengelig fra lanseringen.

Hannah Clark: Dette er veldig interessant. Jeg vil gjerne snakke litt mer om implementering og videreutvikling. Det er én ting å analysere funksjonene du har, prioritere og gjennomføre endringer og forbedringer i den eksisterende versjonen av produktet, men etter hvert introduseres nye funksjoner, og andre blir foreldet eller erstattes av oppdateringer.

Hvordan integrerer du denne analyseprosessen, eller hvordan jobber du proaktivt, for å sikre at framtidige funksjoner som kommer inn i veikartet også er tilgjengelige fra dag én?

Prerna Ramachandra: Det er et godt spørsmål. Jeg skal gi et konkret eksempel. Siden du nevnte brukerintroduksjon i begynnelsen, vil jeg si at det første du må gjøre når du lager veikartet, er å se på alle funksjonene og alt du har på gang, inkludert det nye du bygger, og vite at du må tenke på tilgjengelighet.

Som produktsjef må du ha dette i tankene hver eneste gang. Du må også utvikle en forståelse for når og hvem i kundebasen som kan hjelpe deg med å finne ut om noe er tilgjengelig. Produktsjefer bruker mye brukerundersøkelser for å finne ut hva de skal bygge, men glemmer ofte at det finnes kunder og mennesker som bruker produktet på måter som krever tilgjengelighetsfunksjoner.

Sørg derfor for å involvere disse personene i brukerundersøkelsene helt fra begynnelsen. Når du tenker framover, er brukerintroduksjon et godt eksempel. I den første analysen vår av Slack fant vi tilgjengelighetsmangler i introduksjonsopplevelsen som vi ønsket å løse. Samtidig visste vi at teamet for brukerintroduksjon i Slack var i ferd med å gjøre en stor redesign, fordi produktet hadde utviklet og utvidet seg siden første gang de bygget dette.

De ønsket å sikre at alt ble tatt med. Vi kunne derfor samarbeide med teamet helt fra starten for å sikre at den sentrale introduksjonsflyten de redesignet, var tilgjengelig.

Vi var tett involvert i planleggingen av veikartet fra begynnelsen. Dette var et stort prosjekt, og i slike prosjekter er det særlig viktig å involvere de riktige ekspertene. Designeren vår deltok gjennom hele designprosessen. Under brukerundersøkelser, brukertesting og arbeidet med designene i Figma laget han tilgjengelighetsspesifikasjoner parallelt med teamet, slik at alt var tilgjengelig fra starten.

Det var den samme prosessen vi brukte da vi redesignet skrivebordsappen i Slack. I tillegg fant vi en reell mulighet til å lage en introduksjonsopplevelse som var spesielt rettet mot tilgjengelighet for brukerne som trengte det.

Det beste eksempelet er Apples produkter. Apple er etter min mening svært gode når det gjelder tilgjengelighet. Når du kjøper en ny Mac, kan du velge en introduksjonsflyt som viser hvor de ulike tilgjengelighetsfunksjonene finnes, hvordan de brukes og så videre.

Tilgjengelighetsteamet vårt bygde derfor en slik introduksjonsopplevelse. Når du går inn i den vanlige introduksjonsflyten, spør vi om du er interessert i tilgjengelighet. Hvis du svarer ja, får du en trinnvis arbeidsflyt som viser hvor de ulike verktøyene finnes, hvordan du navigerer med tastaturet, hvilke kommandoer som er tilgjengelige, og så videre.

Vi kunne også bruke dataene. Når noen fortalte oss at de var interessert i tilgjengelighet, tok vi dem gjennom arbeidsflyten. Deretter kunne vi vise dem strategisk plasserte verktøytips i produktet, slik at de kunne fortsette tilgjengelighetsreisen.

Dette var mulig fordi vi først identifiserte problemene og så et stort gap: Det fantes ingen introduksjonsopplevelse for tilgjengelighet. Deretter snakket vi med mange kunder, blant annet kunder som hadde sendt inn feilmeldinger om tilgjengelighet og hjulpet oss med å forstå hvor tilgjengelig produktet var.

Mange sa at det ikke fantes noe som hjalp dem med å forstå hvordan de skulle navigere i Slack. De måtte finne ut av alt selv. Mange er dessverre vant til dette, fordi mange av produktene våre ikke hjelper dem. Likevel er det etter min mening ikke den ideelle arbeidsflyten.

Når du tenker på framtidige produkter og hva du ønsker å bygge, må du bruke brukerundersøkelser aktivt. Jeg vet ikke hvorfor dette ikke snakkes mer om i bransjen vår, men du må snakke med kundene dine. Ingenting kan erstatte det. Jeg tror ikke kunstig intelligens kommer til å fortelle deg hva du skal bygge. Det er menneskene som bruker produktet, som kan fortelle deg det.

Det finnes selskaper og verktøy som hjelper deg med dette. Hvis du er et stort selskap med bedriftskunder, vil kundene dine nesten garantert ha en ressursgruppe for ansatte med funksjonsnedsettelser. Jeg er ganske sikker på at disse gruppene vil være aktive i vurderingen av leverandører.

Det er en ressurs du kan bruke. En annen ressurs er et selskap vi tidligere samarbeidet med, som spesifikt rekrutterte brukere med funksjonsnedsettelser til brukertesting av tilgjengelighet. Det fungerer som en tjeneste for brukertesting, men er laget spesielt for tilgjengelighet.

Samarbeid med slike virksomheter og organisasjoner for å forstå hva du bygger og hvordan du bygger det. Når du starter design- og videreutviklingsprosessen, bør du involvere noen med tilgjengelighetskompetanse. Designeren kan ta et kurs i tilgjengelig design, eller du kan involvere en ekspert fra starten av.

Sørg for at designene har tilgjengelighetsspesifikasjoner. Det er disse utviklerne vil bruke som referanse når de skal finne ut hvordan noe skal bygges. Sørg også for at designere og tilgjengelighetseksperter deltar i testingen. Slik sikrer du at alt du bygger framover, er tilgjengelig, i stedet for å måtte skynde deg og gjøre det om igjen senere.

Hannah Clark: Alle som har hørt på programmet lenge, vet at jeg liker konkrete råd. Tusen takk for disse spesifikke anbefalingene. For å avslutte vil jeg gjerne innom analyse. Vi snakket om data tidligere, og jeg vil knytte dette tilbake til hvordan vi skal måle suksessen til tilgjengelighetsfunksjonene og alt arbeidet vi har lagt ned sammen.

Når man måler aktiveringsgrad eller andre viktige adopsjonsmål for befolkningen generelt, ser man kanskje på en annen prosess for å segmentere hvor effektive tilgjengelighetsfunksjonene er. Dette gjelder enten det handler om brukerintroduksjon eller andre tilgjengelighetsfunksjoner.

Det er et spørsmål i flere deler. For det første: Hvordan segmenterer du det du måler, slik at du måler suksessen til tilgjengelighetsfunksjonene du har bygget, og ikke bare produktet som helhet? Finnes det verktøy du ville brukt? Har du andre tips for å sikre at denne typen data kan brukes i framtidige utgaver?

Prerna Ramachandra: Jeg skal gi et svar som sannsynligvis gjør mange produktsjefer ukomfortable. Det er også noe jeg selv synes er vanskelig: Du kan ikke stole på kvantitative data for å forstå om tilgjengelighetsfunksjonene fungerer, eller om produktet faktisk er tilgjengelig.

Moralsk og etisk kan du ikke uten videre segmentere brukere etter tilgjengelighet, fordi du da trekker antakelser om hvorvidt noen har en funksjonsnedsettelse. Selv om du måler hvor mange som bruker tastaturnavigasjon eller har aktivert skjermleserkommandoer, kan du fortsatt utelate en stor del av befolkningen.

Er for eksempel personer med nevrodivergens i stand til å bruke produktet, eller blir det for overveldende? Det finnes spesifikke funksjoner knyttet til dette. I Slack og mange andre produkter med animasjoner kan du slå av animasjonene, fordi de kan utløse anfall hos enkelte. Dette er også vanskelig å måle.

Du får derfor bare så mye ut av kvantitative målinger. Det er vanskelig å segmentere brukere på samme måte som du vanligvis segmenterer brukerbasen, fordi du trekker antakelser om mennesker som du vanligvis ikke bør trekke.

Det vil dessuten sannsynligvis ikke være særlig effektivt. Det finnes skjulte funksjonsnedsettelser, og metoden tar ikke hensyn til situasjonene jeg snakket om i begynnelsen.

Det som etter min erfaring fungerer best for å måle om et produkt og tilgjengelighetsfunksjonene er tilgjengelige, er å gå tilbake til brukerne og spørre dem. Kvalitativ forskning er etter min mening den beste måten å måle suksess på.

Et konkret eksempel er en tilgjengelighetsfunksjon vi bygde i Slack: et programmeringsgrensesnitt som flere team kunne bruke til enkelt å bygge tastaturnavigasjon inn i produktene sine. Tastaturnavigasjon krever spesialisert kompetanse, så grensesnittet skulle gjøre det enklere for teamene.

Vi målte suksessen ved å se hvor mange team som brukte programmeringsgrensesnittet. Det var ikke obligatorisk; teamene kunne bygge funksjonen selv. Hvis teamene brukte grensesnittet, betydde det at vi som tilgjengelighetsteam hadde laget noe de kunne bruke, og som fungerte godt.

Det var altså mer et internt teammål enn et brukermål. For brukerne målte vi som sagt først og fremst ved å spørre dem. Da vi lanserte introduksjonsflyten, fikk vi noen kvantitative data om hvor mange brukere som valgte tilgjengelighetsintroduksjonen. Men i hovedsak hadde vi satt sammen grupper av brukere som vi snakket med om tilgjengelighet.

Når du lanserer noe, bør du vanligvis gjøre kvalitativ forskning for å forstå effekten. Vi sørget for at gruppene inkluderte brukere som hadde spurt om tilgjengelighet, brukte tilgjengelighetsfunksjoner og så videre. Det handlet i stor grad om samtaler, kvalitative målinger og kvalitativ forskning.

Du ønsker ikke bare å vite om noen bruker produktet, men om de kan bruke det ordentlig for å utføre oppgavene de ønsker å utføre. Hvis produktet gjør det godt blant flertallet av brukerne, gir det en viss indikasjon på at produktet fungerer. Men hvis du vil snakke med bestemte brukere om tilgjengelighet, må du finne disse brukerne og gjøre den kvalitative undersøkelsen og analysen.

Jeg vet at dette ikke er et godt svar når du som produktsjef egentlig ønsker deg tall og data. Samtidig mener jeg at en del av jobben er å akseptere en viss usikkerhet. Du kommer aldri til å bli perfekt.

Ingen produkter vil noensinne oppfylle alle krav til tilgjengelighet perfekt. Mye er situasjonsbetinget, og derfor er det viktig å fortsette samtalene med brukerne. Brukere som bryr seg om tilgjengelighet, er ofte svært tydelige, fordi de ikke er vant til å få det de trenger for å gjøre jobben sin.

De må være tydelige for å kunne fungere og gjøre jobben sin ordentlig. Dette er en stor ressurs. Det jeg lærte mer enn noe annet i karrieren min som produktsjef, var hvor viktig det er å snakke med og lytte til brukerne. De kan gi deg den beste informasjonen om hvordan produktet fungerer.

Folk snakker ikke nok om hvor viktig kvalitativ forskning og menneskelig kontakt er. Jeg mener likevel at dette virkelig forteller deg om produktet fungerer. Når det gjelder tilgjengelighet, er det spesielt viktig å snakke med mennesker.

Hannah Clark: Jeg kunne ikke vært mer enig. Dette er virkelig en episode som fremhever betydningen av brukerundersøkelser. Vi hadde en episode med Steve Portigal om hvordan man intervjuer brukere. Den er en av favorittene våre, fordi den handler om å snakke med mennesker, la dem fortelle om sine ekte erfaringer og ikke forsøke å styre samtalen eller la egne fordommer påvirke den. Det er så viktig i produktutvikling.

Tusen takk. Dette har vært en utrolig hyggelig samtale, og jeg setter stor pris på perspektivet ditt. Du har delt så konkrete historier om et så kjent produkt at vi virkelig kan forstå hvordan disse funksjonene blir til.

Hvor kan folk følge arbeidet ditt på nettet eller komme i kontakt med deg?

Prerna Ramachandra: Jeg er på LinkedIn. Du finner meg under fornavn og etternavn, Prerna Ramachandra. Du kan også kontakte meg via nettstedet mitt, PrernaRamachandra.me.

Hannah Clark: Flott. Tusen takk for at du var med.

Prerna Ramachandra: Tusen takk, Hannah. Dette var flott.

Hannah Clark: Takk for at du lyttet. For flere gode innsikter, veiledninger og verktøyanmeldelser kan du abonnere på nyhetsbrevet vårt på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved å abonnere på The CPO Club, uansett hvor du hører på podkaster.