Hvorfor tilgængelighed skal have højeste prioritet i 2025

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle slåfejl, da botten ikke er korrekt 100 % af tiden.

Hannah Clark: Jeg tror, det er på tide, at vi indrømmer, at det ofte gør os utilpasse at tale om tilgængelighed. I en produktkontekst prioriterer vi typisk funktioner med den største effekt og den største procentdel af brugerne. Så når vi taler om at bygge tilgængelige produkter, føles det som et komplekst emne. Hvor på køreplanen skal vi placere funktioner, der har stor betydning for en relativt lille procentdel af brugerne? Hvordan ved vi, hvordan tilgængelighed bør se ud for vores produkt, når tilgængelig betyder forskellige ting for forskellige mennesker? Og hvordan gør vi alt dette uden at træffe antagelser eller utilsigtet støde de brugere, vi forsøger at støtte?

Min gæst i dag er Prerna Ramachandra, ledende produktchef hos Yahoo. Før hun kom til Yahoo, var Prerna seniorproduktchef hos Slack, hvor hun spillede en central rolle i at gennemgå og udvikle tilgængelige funktioner til produktets mangfoldige brugerbase. Det, du skal til at høre, er dels et casestudie og dels en praktisk guide til forretningsargumenterne for tilgængelighed samt de mest effektive og etiske måder at gøre dit produkt mere imødekommende for alle. Lad os gå i gang.

Velkommen tilbage til The CPO Club Podcast. I dag er vi her sammen med Prerna Ramachandra.

Prerna, mange tak, fordi du har afsat tid i din travle kalender til at være med i dag.

Prerna Ramachandra: Mange tak, fordi jeg måtte komme. Det er dejligt at være her.

Hannah Clark: Kan du fortælle os lidt om din baggrund, og hvordan du nåede dertil, hvor du er i dag?

Prerna Ramachandra: Jeg er i øjeblikket ledende produktchef hos Yahoo. Jeg har været her i omkring halvandet år nu. Før Yahoo arbejdede jeg hos Slack, og jeg var hos Slack lige før virksomheden blev opkøbt af Salesforce og fortsatte gennem Salesforce-opkøbet. Hos Slack ledede jeg primært teamet for tilgængelighed og designsystemer, før jeg skiftede til at arbejde med deres centrale skrivebordsoplevelse.

Mit arbejde skiftede fra det ene team til det andet, og de to områder overlappede faktisk hinanden, hvilket jeg gerne vil dykke ned i senere i dag. Før Slack arbejdede jeg hos Washington Post, hvor jeg ledede redesignet af deres forside og den nye platform for oplevelsen af artikelsiden. Så jeg har erfaring fra medier og fra store teknologivirksomheder.

Jeg plejer at sige, at min interesse for produktområdet specifikt ligger i krydsfeltet mellem produkt, teknologi og historiefortælling – og i de måder, mennesker bruger historier til at kommunikere med hinanden på, samt hvordan teknologi kan være et effektivt værktøj til det.

Hannah Clark: Det passer jo perfekt, eftersom du er her i dag for at fortælle din historie.

Det er tydeligvis noget, vi begge brænder for: historiefortælling. I dag skal vi fokusere på noget, der måske er lidt mere nichepræget, men bestemt et emne, som jeg synes, vi ikke taler nok om. Det er tilgængelighed – og specifikt krydsfeltet mellem tilgængelighed og brugerintroduktion.

For at lægge ud: Hvorfor vil du ud fra din erfaring med at arbejde inden for dette område sige, at tilgængelighed ofte bliver behandlet som en eftertanke? Og hvad er forretningsargumentet for at indbygge det fra begyndelsen?

Prerna Ramachandra: Helt sikkert. Jeg vil gerne begynde med en sætning, som jeg virkelig, virkelig tror på: Vi lever i en tid, hvor jeg ikke længere mener, at teknologi er en luksus.

Jeg voksede op i 1990’erne, så jeg afslører min alder lidt her, hvor teknologi stadig var noget nyt og spændende. Internettet var stadig noget nyt og spændende. Ikke alle havde adgang til det, og det var heller ikke nødvendigt for alle, men vi lever i en tid, hvor alle vores essentielle tjenester på den ene eller anden måde er digitaliserede. Det betyder, at alle mennesker i verden bør kunne bruge dem nemt.

Mennesker med handicap bliver generelt behandlet som en eftertanke i vores samfund. Jeg synes, at mange af vores tjenester ikke er tilstrækkeligt tilgængelige, men teknologien er i en unik position til faktisk at kunne indbygge tilgængelighed i det, den gør, på en forholdsvis enkel måde. Teknologien er også i en unik position til at gøre livet meget lettere for alle – herunder mennesker med handicap.

Derfor mener jeg, at dette er en af de vigtigste grunde til, at vi bør prioritere det ud fra et moralsk og etisk synspunkt. Hvorfor det bliver behandlet som en eftertanke, skyldes helt ærligt, at jeg ikke tror, de fleste organisationer fuldt ud forstår forretningsargumentet for det. Det er det første. For det andet tror jeg, det skyldes, at folk føler, at tilgængelighed kræver en meget dyb teknisk ekspertise.

Derfor føler de ikke altid, at de har den ekspertise, eller de tænker ikke altid på det. Det er ikke indbygget i vores processer. Som følge heraf ignorerer vi det, indtil nogen bliver bekymret for, at virksomheden bliver sagsøgt, eller at den mister en kunde, som har krav til tilgængelighed.

Pludselig kæmper jeres teams for at finde ud af, hvad der er galt, og hvordan det skal bygges ind. For at besvare anden del af dit spørgsmål – hvad er forretningsargumentet for tilgængelighed? – berørte jeg faktisk allerede dette i mit første punkt. Virkeligheden er, at hvis teknologien skal lykkes, vil man gerne have flere brugere, ikke? Og for de fleste af os gælder det, at vi tjener mere, jo mere vores produkt bliver brugt.

Flere mennesker bruger det, hvis de kan få adgang til det. På et grundlæggende niveau er tilgængelighed derfor virkelig vigtigt, fordi flere mennesker kan bruge jeres produkter, og når flere mennesker bruger jeres produkter, tjener I ganske enkelt flere penge. Bagsiden er, at I ikke ønsker at blive sagsøgt, og hvis I bliver sagsøgt, er der en risiko for, at I skal betale mange penge.

Der er altså et forretningsargument for tilgængelighed fra begge perspektiver. Jeg vil også gerne tilføje – og det vil jeg gå mere i detaljer med – noget, som jeg personligt brænder meget for inden for tilgængelighedsområdet. Vi begrænser altid idéen om tilgængelighed til at sikre, at et produkt kan bruges med skærmlæsere, og at man kan navigere med tastaturet. Men jeg synes, vi er nødt til at gå videre end den definition af tilgængelighed og virkelig tænke over, hvordan vi sikrer, at alle kan bruge produktet i enhver situation.

Vi tænker ofte ikke på tilgængelighed som noget, der kan være situationsbestemt og betinget. Et eksempel, jeg altid ynder at bruge, er stemmekommandoer eller brug af stemmen til at anvende produktet. Vi tænker altid, at det er lettere, hvis man har nedsat syn. Min far er for eksempel meget ældre, og han kan måske ikke se den lille tekst på sin skærm, så han kan godt lide at bruge stemmen til at styre mange ting på sin telefon.

Men hvis man kører bil, har man heller ikke hænderne fri, og man bruger ikke øjnene på samme måde, så man kan stadig bruge stemmekommandoer. Når man tænker på tilgængelighed, kan man derfor se det som noget, der omfatter en situation snarere end en person eller et individuelt problem. Det udvider faktisk ens definition og får en til at indse, at man lader et enormt anvendelsestilfælde og en enorm brugergruppe ligge uudnyttet.

Det er sandsynligvis ikke godt for forretningen. Der er altså et praktisk forretningsargument for, hvorfor det er vigtigt at prioritere dette helt fra begyndelsen.

Hannah Clark: Det giver virkelig genklang. Jeg synes, det gælder for tilgængelighed i digitale produkter såvel som i fysiske produkter og fysiske rum. Jeg kan virkelig godt lide indramningen af at være tilgængelig i en situation frem for til et specifikt anvendelsestilfælde. Jeg oplevede det selv, da jeg skubbede en barnevogn, og lagde mærke til, hvor mange områder der var designet til én enkelt fodgænger – altså til at gå på række.

Man indser, at der er så mange forskellige sammenhænge, hvor nogen kan have brug for en tilgængelighedsfunktion eller en tilpasning, eller hvor noget er designet med tilgængelighed for øje. Det kan nemlig anvendes på tværs af mange aldre, livsfaser og stadier. Så ja, jeg kan virkelig godt lide den måde at tænke på, og jeg vil gerne dykke lidt dybere ned i det om lidt.

Du nævnte, at du gerne vil tale lidt mere om din erfaring hos Slack, og jeg vil meget gerne høre om nogle af de projekter, du arbejdede på dengang – især arbejdsgange for tilgængelig brugerintroduktion.

Fortæl mig lidt om, hvordan du greb en analyse af den aktuelle situation an for at vurdere produktets nuværende tilgængelighed, og hvordan gik du videre derfra?

Prerna Ramachandra: Helt sikkert. Da jeg begyndte hos Slack, var et af de første projekter, jeg arbejdede på, faktisk at finde ud af, hvor tilgængeligt produktet var, og hvad vi kunne gøre – præcis som du siger.

Hvilke rammer havde vi til at gennemføre en analyse af produktets tilstand? Da jeg kom til Slack, havde vi ikke noget. Slack var på det tidspunkt i gang med for alvor at gå efter store erhvervskunder, efter at have klaret sig rigtig godt på markedet for små og mellemstore virksomheder. Da virksomheden begyndte at gå efter de store erhvervskunder, blev det tydeligt, at der var et meget strengt regelsæt for leverandørernes tilgængelighed.

Det første, jeg gjorde, var derfor at udvikle et internt sæt standarder, som vi kaldte Slacks tilgængelighedsstandarder. De anvendte allerede eksisterende standarder som WCAG, men tog også højde for Slacks unikke produkter og for, hvad tilgængelighed ville betyde for netop disse produkter. Vi sammensatte en ramme, der gjorde det muligt at gennemgå produktet og analysere, om det opfyldte bestemte kriterier.

Som resultat af analysen tildelte vi forskellige funktioner i produktet en karakter – A, B eller C – for at analysere, hvor tilgængelige de var. Det var i høj grad en kvantitativ og kvalitativ analyse. Vi havde en liste over kriterier. Nogle var baseret på meget enkle ting som opgavestyring: Er alt tilgængeligt via tastaturet?

Er alt tilgængeligt for skærmlæsere? Andre ting var lidt mere uhåndgribelige. Slack er for eksempel et kommunikationsprodukt, og en af de ting, det gør rigtig godt, er meddelelser. Man skal have besked, men det var under pandemien, så mange mennesker arbejdede hjemmefra.

Mange arbejdede på afstand. Vi hørte derfor fra kunder, at der var en overbelastning af meddelelser, og at det specifikt påvirkede personer, der identificerede sig som neurodivergente, fordi de følte sig meget overvældede og ikke kunne udføre deres opgaver ordentligt. Det var lidt mere uhåndgribeligt.

Det er ikke noget, man nødvendigvis ser i mange af de tilgængelighedsretningslinjer, der findes. Derfor indarbejdede vi alt dette i rammen. Vi brugte rammen til at tildele karakterer til hvert funktionsområde, og karaktererne var udelukkende baseret på, om personen kunne udføre opgaven, og hvor hurtigt det kunne ske.

Det hjalp med at skabe en fornemmelse af, hvilke problemer der hastede, hvad der var vigtigst, og hvad der ikke var. Det var det første, vi gjorde. Vi brugte det til at analysere produktets tilstand og gik derefter til ledelsen og sagde: Okay, dette er hele produktet. Sådan fordeler det sig. Og det er de problemer, vi mener, skal løses med det samme, fordi produktet grundlæggende er ødelagt for en gruppe kunder som følge af, at dette ikke er blevet gjort.

Det smarte ved denne ramme var også, at den ikke kun kunne anvendes på eksisterende produkter. Hvis man udviklede nye produkter, kunne man bruge rammen til at forstå, hvad man skulle kontrollere, før produktet kunne lanceres.

Den kunne også bruges fremadrettet og til fremtidige produkter. Det var det første, vi gjorde. Derefter udførte vi en masse arbejde – jeg udførte en masse arbejde – for specifikt at samarbejde med de enkelte teams, så de kunne vide, hvad de skulle prioritere på baggrund af denne ramme.

Alle har en køreplan. Ingen ønsker at sprænge deres køreplan for at imødekomme noget nyt, der dukker op. Alle har en række ting, de har forpligtet sig til. Jeg arbejdede derfor med de enkelte teams, så de vidste præcis, hvilke kritiske punkter der gjaldt for dem. Når vi derefter samlet gik til ledelsen og sagde: Dette skal prioriteres. Dette skal løses, kunne vi komme med en meget klar plan og også fortælle, hvad afvejningerne var.

Hvad ville indsatsen være for at løse hvert af disse punkter, hvad ville blive skubbet ud af køreplanen, hvis vi skulle indarbejde dette, og hvad ville effekten være? Jeg mener altid, at når det handler om tilgængelighed – og det gælder for mange ting inden for produktområdet – skal man forstå balancen mellem at arbejde med det enkelte team, der er ansvarligt for funktionsområdet, og samtidig navigere i, hvordan man samarbejder med ledelsen for at få opbakning til at prioritere arbejdet.

Jeg var meget heldig, fordi ledelsen hos Slack var stærkt engageret i at prioritere dette arbejde og gøre det ordentligt. Det, de virkelig havde brug for fra os, var tydelige oplysninger: Hvad er indsatsen? Hvad er tidsplanen? Hvad er afvejningerne? Og hvad er effekten? Det var det, vi kunne præsentere for dem.

Det var altså meget arbejde med personaleledelse og også meget teknisk arbejde sammen med ingeniørerne for at levere den analyse, de havde brug for.

Hannah Clark: Det her er så afgørende. Jeg synes, at opbakningen er helt central for at sikre, at disse funktioner faktisk bliver leveret. Som du siger, skal man gøre det rigtigt.

Jeg vil gerne gå lidt mere i detaljer, eftersom du nævnte afvejningen. Hvordan ser en afvejning ud? Hvis du skulle give et eksempel på, hvordan det kunne blive præsenteret, hvordan ville du formulere det for at sætte det hele i kontekst og forklare projektets omfang, og hvor det befinder sig på listen over kritiske punkter?

Prerna Ramachandra: Det team, som efter min mening blev mest påvirket af det arbejde, vi udførte, var teamet, der arbejdede med den centrale del af projektets meddelelsesfunktion. Det skyldtes, at de ejede det største område. De ejede alt fra oplevelsen af at skrive og sende en meddelelse til at modtage en meddelelse i hele meddelelsesområdet.

De havde også medlemmer på teamet, der ejede kanaler. Hvis man bruger Slack, ved man, at dette er kernen i Slack-oplevelsen. Det gav derfor mening, at de havde det største antal punkter, de skulle håndtere. De ejede ikke bare det største område, men også det mest kritiske område.

Slack eksisterer, fordi folk sender og modtager meddelelser. Det var derfor det mest kritiske område, og det havde flest alvorlige tilgængelighedsproblemer, som skulle håndteres. For at give et helt konkret eksempel vil jeg ikke bruge de faktiske tal, men nogle hypotetiske tal.

Lad os bruge 100, fordi det gør procentberegninger lettere. Jeg gik til dem med en liste på 100 problemer og sagde: Dette er alt det, der skal håndteres for at sikre, at jeres produkt som minimum kan bruges af alle, der anvender en skærmlæser, navigerer med tastaturet eller identificerer sig som en person med handicap.

Det første, jeg gjorde, var at sætte mig sammen med produktchefen og sige: Okay, dette er en liste over problemer, som vi har identificeret på baggrund af den ramme, vi har. Det var faktisk et meget vigtigt skridt, fordi produktchefen kunne samarbejde med mig og sige: Jeg forstår, hvorfor du siger, at disse 100 punkter er kritiske, men jeg mener faktisk kun, at 80 procent af dem er kritiske.

Det skyldes de brugerdata og den brugerinformation, vi har om, hvordan folk anvender dette. Hvis du mener, at denne bestemte arbejdsgang er meget vigtig, udfører brugerne den faktisk på en anden måde. Der findes allerede omveje og løsninger. Den første analyse var derfor meget vigtig, fordi vi kunne reducere de 100 punkter til 80.

Jeg synes, det er afgørende for alle, der har en central organisation for tilgængelighed, at føre denne samtale med produktchefen for selve produktet. De kender nemlig deres brugere bedst. Derfor kunne vi reducere listen en hel del. Det næste, vi gjorde, var at se på problemerne og undersøge, hvilke af dem der lå i produkt- eller funktionsområder, som snart skulle redesignes eller udfases.

Det hjalp os med at sige: Hvis dette bestemte område skal redesignes, skal vi blot sikre, at det er tilgængeligt i redesignet, og så behøver vi ikke løse problemet lige nu. Hvis dette område skal udfases, behøver vi heller ikke løse problemet lige nu. Det fjernede yderligere omkring 10 problemer.

Derefter havde vi omkring 70 problemer, som skulle håndteres sammen med teamet. Vi satte os sammen med deres ingeniører. Her er det virkelig vigtigt at have mindst én intern ekspert i tilgængelighed. Vi var meget heldige at have en utrolig dygtig ingeniør med den ekspertise. Han kunne komme ind og arbejde sammen med deres ingeniørteam for at hjælpe dem med at forstå problemerne og foretage en vurdering af indsatsen for hvert af de 70 problemer.

Derefter satte vi os sammen med produktchefen og spurgte: Hvor mange af disse 70 problemer kan I prioritere i den nuværende eller kommende sprint inden for dette kvartal uden at bekymre jer om, at noget bliver forsinket? Hvor meget kan I få plads til? De fleste teams har normalt en vis buffer, især hvis de arbejder på et allerede lanceret produkt og skal håndtere indkommende fejl og problemer.

Det blev derfor indarbejdet i denne arbejdsgang, og de sagde: Vi kan sandsynligvis løse omkring 20 af dem uden alvorlig påvirkning af køreplanen. Vi behøvede derfor ikke engang at tage det op med ledelsen. Så var vi måske nede på halvdelen. Vi kunne virkelig reducere antallet, og med de resterende – lad os sige 50 problemer – skulle vi spørge: Hvilke større produktområder i dette kvartal kunne blive skubbet ud eller forsinket, hvis alle disse problemer blev prioriteret?

Det var det øjeblik, hvor vi havde brug for, at ledelsen trådte til og hjalp os med at navigere i og forhandle, hvad der skulle gøres. Der var et funktionsområde, en funktion, som teamet skulle lancere i det kvartal. Den var meget vigtig for en stor kunde, men den samme store kunde var også den, der bad os om at løse disse tilgængelighedsproblemer inden for en bestemt tidsramme.

Vi kunne derfor gå til ledelsen og sige: Dette er afvejningen. Dette er det, vi arbejder med. Derefter kunne vi bruge deres hjælp og samarbejde med kundens account managers, gå til kunden og sige: Okay, dette er vores situation. Hvad vil I helst se?

Det vigtigste her er efter min mening at udføre så meget arbejde som muligt på sit eget niveau – som individuel bidragyder, seniorproduktchef, ledende produktchef eller gruppeproduktchef – for at sikre, at man har gjort alt, hvad man kan, for kreativt at prioritere det arbejde, der kan udføres internt i teamet. Man bør først inddrage ledelsen, når der er tale om større områder.

I dette tilfælde var det nyttigt, at den samme kunde blev påvirket af begge sæt problemer. Derfor kunne vi samarbejde med kunden om at forhandle, hvad de ønskede først, og hvad der kunne komme senere. På den baggrund kunne vi sige: Lad os løse disse 10 problemer i dette kvartal, så den anden funktion ikke bliver forsinket alt for meget. Lad os løse disse 10 problemer i næste kvartal.

Det var første kvartal, hvor vi gjorde alt dette. I de efterfølgende kvartaler kunne vi i selve planlægningscyklussen for kvartalet samarbejde med teams om at afsætte dedikeret tid, hvor de udelukkende arbejdede med tilgængelighed.

Det er her, det virkelig er vigtigt at involvere hele organisationen, fordi vi kunne afholde sprintuger for tilgængelighed. Vi plejede at placere dem samtidig med den globale dag for bevidsthed om tilgængelighed, når kvartalet passede med det. Alle i teamet – alle de forskellige ingeniørgrupper – arbejdede sammen om tilgængelighedsproblemer i den sprint. Det skabte også et rart fællesskab.

Vi havde også workshops, hvor vi fortalte teams om tilgængelighed. Det fungerede virkelig godt, men jeg kan sige, at der er meget hårdt arbejde i begyndelsen. Især når der er store afvejninger mellem funktioner, er det nødvendigt at inddrage ledelsen for at få hjælp til at forhandle og navigere i, hvad der skal prioriteres, og hvornår.

Hannah Clark: Det er virkelig spændende, og jeg elsker at høre om, hvordan hele organisationen samles for specifikt at prioritere tilgængelighed og afsætte tid til det. Og at det samtidig viste sig at være en så positiv arbejdsoplevelse. Det lyder fantastisk.

Nu hvor vi taler om samarbejde og om at arbejde som ét team på tværs af forskellige teams, er jeg nysgerrig efter at høre, hvordan det fungerer, når man arbejder i en organisation, der måske har flere produkter i porteføljen, og hvor flere teams forsøger at håndtere tilgængelighedsproblemer på tværs af disse produkter og funktioner.

Hvordan samarbejder man mellem produktteams for at arbejde synkront og minimere den indsats og kommunikation, der kræves for at lancere disse produkter?

Prerna Ramachandra: Det er et godt spørgsmål. Jeg synes, der er to forskellige måder – eller to søjler – til at håndtere dette problem.

Den første søjle er strukturel. Hvis organisationen har en central organisation for tilgængelighed – og det har de fleste organisationer i dag i en eller anden form – hvor er den så placeret i organisationen? Hvis den er placeret i en enkelt vertikal, bliver det meget svært at bryde gennem organisatoriske siloer for at arbejde sammen med andre teams.

Man skal derfor virkelig sikre, at teamet er placeret det rigtige sted. Hvis det ikke er tilfældet, skal man som produktchef selv gøre arbejdet for at række ud til alle de andre teams, forstå deres køreplaner og lære dem at kende, så man kan arbejde godt sammen. Det er det første.

Den anden del er at sikre – og her er der også to sider – både for den person, der administrerer og leder den centrale organisation for tilgængelighed, og for produktcheferne i de enkelte funktionsområder, at man hele tiden kommunikerer om sine køreplaner.

Hvis man ved, hvad der kommer, var det faktisk en af de største udfordringer for vores team og samtidig et af de største muligheder, da jeg arbejdede med tilgængelighed hos Slack. Senere, da jeg begyndte at arbejde med skrivebordsproduktet, gik jeg pludselig fra at være en del af det centrale tilgængelighedsteam til selv at være en del af et af disse funktionsorienterede teams.

Det vigtigste er at sikre, at man allerede fra begyndelsen af køreplanlægningen inddrager de tilgængelighedseksperter, der skal inddrages. Det begynder i planlægningsprocessen og fortsætter gennem designprocessen. Jeg plejer at sige, at tilgængelighed faktisk ikke begynder hos ingeniørerne, selvom det kræver ingeniørmæssig ekspertise.

Nogle gange begynder det hos designeren. En af de ting, vi begyndte at gøre – og hvis man bruger værktøjer som Figma, har de et fantastisk værktøjssæt til at udforme tilgængelige designs eller en specifik arbejdsgang for tilgængelighed i designet – var at involvere vores designer helt fra begyndelsen af produktudviklings- og designprocessen.

Designeren kunne sige: Hvordan sikrer vi, at de designs, I skaber, er tilgængelige? Er der ting, der fungerer? Er der ting, der ikke fungerer? Det er her, det er nyttigt at tænke fremad, både i forhold til eksisterende problemer og nye funktioner. Hvis man allerede har identificeret en række tilgængelighedsproblemer i produktet, er det her, rammen bliver meget nyttig.

Selvom jeg gjorde mit bedste, kunne jeg, da jeg var en del af den centrale organisation, ikke holde styr på hver eneste ændring, hver eneste ændring i køreplanen og alt, hvad teamet foretog sig. Men fordi vi havde dette centraliserede sæt rammer, som alle kendte, kunne en produktchef i et funktionsorienteret team bare slå op i det, give det videre til designeren, give det videre til ingeniøren eller selv se på det og sige: Okay, denne tilgængelighedsfejl er kommet ind. Ifølge rammen er den kritisk, middel eller lav prioritet. Så kan jeg bruge det til at afgøre, om den skal prioriteres med det samme eller senere.

Det var meget nyttigt at have disse centrale standarder, fordi det sikrede, at en person uden den pågældende ekspertise stadig havde noget at støtte sig til, når fejlene opstod, og kunne hjælpe med at prioritere. Det sikrede også, at der ikke var én enkelt person, som skulle forsøge at holde styr på det hele.

Jeg ønskede virkelig at sikre, at jeg ikke blev som en skoleinspektør, der fortæller folk, hvad de skal gøre. Det tror jeg heller ikke, nogen ønsker. Vi er alle voksne mennesker. Jeg vil også gerne tro, at alle involverede faktisk går op i dette.

Ingen, jeg talte med, sagde: Jeg vil ikke gøre dette. Alle sagde: Det her betyder virkelig noget for mig. Jeg vil sikre, at vores produkt er tilgængeligt. Jeg ved enten ikke hvordan, eller også ved jeg ikke, om vi får bemyndigelse til at prioritere det, eller om vi får tid til det. Det var det, vi forsøgte at løse.

Hvis du er produktchef for en funktion og forsøger at gøre dit produkt tilgængeligt, vil jeg derfor anbefale, at du undersøger, om du kan udvikle en ramme eller samarbejde med nogen i organisationen om at udvikle en ramme, som du og andre kan bruge. Så behøver du ikke hele tiden vente på, at nogen svarer på, om noget er vigtigt eller ej.

Du vil selv vide det. Du vil være bemyndiget. Og når du skaber noget nyt og bygger et nyt produkt, skal du sikre, at du kan række ud til personer med den rette ekspertise og indbygge tilgængelighed i designprocessen helt fra begyndelsen. På den måde undgår du problemet med, at disse fejl dukker op senere, og at du pludselig kæmper for at prioritere dem. Du ved, at produktet vil være tilgængeligt fra lanceringen.

Hannah Clark: Det er virkelig interessant, og jeg vil gerne tale lidt mere om implementering og iteration, fordi det er én ting at analysere de funktioner, man har, og prioritere og implementere ændringer og forbedringer i den eksisterende version af produktet eller i det, virksomhedskunderne efterspørger. Men med tiden introduceres nye funktioner, og funktioner bliver forældede eller erstattes af opdateringer.

Hvordan integrerer man denne analyseproces, eller hvad er den proaktive tilgang, der sikrer, at fremtidige funktioner, som introduceres i køreplanen, også er tilgængelige fra dag ét?

Prerna Ramachandra: Ja, det er også et godt spørgsmål. Jeg vil give et meget konkret eksempel. Da du nævnte brugerintroduktion specifikt i begyndelsen, vil jeg sige, at det første, man skal gøre, når man laver sin køreplan, er at se på hver funktion og alt, hvad man har gang i, herunder alt nyt, man bygger, og vide, at man er nødt til at tænke på tilgængelighed.

Det er noget, man som produktchef skal have i tankerne hver eneste gang. Det andet er at vide hvornår – og det er lidt produktchefintuition, der udvikler sig over tid, samt lidt baseret på faktiske data – hvilke personer i kundebasen der kan hjælpe med at sikre, at noget er tilgængeligt eller ikke er tilgængeligt.

Som produktchefer er vi meget afhængige af brugerundersøgelser for at vide, hvad vi skal bygge. Men vi glemmer ofte, at der faktisk er kunder og mennesker derude, som bruger vores produkt på en måde, der kræver tilgængelighedsfunktioner – brugere med handicap, som anvender disse funktioner. Sørg derfor for, at du har måder at inddrage dem i din brugerundersøgelsesproces helt fra begyndelsen.

Når du tænker fremad, er brugerintroduktion et godt eksempel. Et af de funktionsområder, vi fandt, da vi lavede vores indledende analyse hos Slack, var, at introduktionsoplevelsen havde huller i tilgængeligheden, som vi gerne ville løse. Men vi vidste også, at introduktionsteamet hos Slack var i gang med en større redesignproces, fordi produktet havde udviklet sig og ændret sig, siden de lavede det første gang.

De ønskede at sikre, at alt blev indarbejdet. Vi kunne derfor samarbejde med teamet helt fra begyndelsen for at sikre, at den centrale introduktionsproces, de redesignede, var tilgængelig. Vi gjorde det ved at være tæt involveret i deres køreplanlægning helt fra begyndelsen.

Det var et meget stort projekt. Når man har disse store projekter, er det især vigtigt at få de rette eksperter involveret. Vores designer var faktisk involveret under hele designprocessen. Da de udførte brugerundersøgelser, brugertests og skabte deres designs i Figma, udarbejdede han tilgængelighedsspecifikationen for disse designs parallelt med dem for at sikre, at tingene var tilgængelige helt fra begyndelsen.

Det var den samme proces, vi brugte hos Slack, da vi redesignede skrivebordsappen. For det andet fandt vi en reel mulighed for at skabe en introduktionsoplevelse, der specifikt var centreret omkring tilgængelighed for de brugere, der havde brug for den.

Det bedste eksempel er efter min mening Apple. Apples produkter er virkelig solide, når det handler om tilgængelighed. Når man køber en ny Mac, kan man faktisk vælge at gennemgå en introduktionsproces, der specifikt viser, hvor de forskellige tilgængelighedsfunktioner findes, og hvordan man bruger dem.

Vores team – tilgængelighedsteamet – byggede derfor denne centrale introduktionsoplevelse. Når man åbner appen og går ind i den almindelige introduktionsproces, spørger vi: Går du op i tilgængelighed? Hvis man svarer ja, bliver man ført gennem en trinvis arbejdsgang, der viser, hvor de forskellige værktøjer findes, hvordan man bruger tastaturnavigation, hvad de forskellige kommandoer er osv.

Vi kunne også bruge data. Når nogen fortæller os, at de er interesserede i tilgængelighed, fører vi dem gennem arbejdsgangen. Derefter kunne vi strategisk vise dem forskellige værktøjstip i produktet, som gjorde det muligt for dem at fortsætte deres tilgængelighedsrejse.

Alt dette var muligt, fordi vi først identificerede problemerne. Da vi beskrev alle problemerne i den eksisterende arbejdsgang, så vi et stort hul, fordi der ikke fandtes nogen introduktionsoplevelse for tilgængelighed.

For det andet talte vi med mange kunder. Vi talte med kunder, der sendte fejlrapporter om tilgængelighed til os, og som hjalp os med at forstå, hvor tilgængeligt produktet var. Mange sagde: Der var ikke noget, der hjalp mig med at finde ud af, hvordan jeg skulle navigere i Slack. Jeg måtte selv finde ud af det.

De fleste er desværre vant til at gøre det, fordi mange af vores produkter ikke hjælper dem med det. Men efter min mening er det stadig ikke den ideelle arbejdsgang. Når du tænker fremad og overvejer, hvilke produkter du vil bygge, og hvordan dit produkt fungerer, skal du derfor i høj grad stole på brugerundersøgelser.

Jeg ved ikke, hvorfor der ikke bliver talt mere om det i vores branche, men man er nødt til at tale med sine kunder. Intet kan erstatte det. Jeg tror ikke, kunstig intelligens vil fortælle dig, hvad du skal bygge. Det er de mennesker, der bruger produktet, som fortæller dig, hvad du skal bygge.

I dag findes der virksomheder og værktøjer, som kan hjælpe dig med det. Hvis du for eksempel er en stor virksomhed, og dine kunder er erhvervskunder, kan jeg garantere, at de har en medarbejderressourcegruppe af en slags med medarbejdere med handicap. Jeg er helt sikker på, at de vil være meget aktive i at sikre, at deres leverandører bliver vurderet.

Det er en ressource, du kan bruge. En anden ressource er en virksomhed, vi plejede at samarbejde med, som hedder Fable. Den rekrutterede specifikt brugere med handicap til at udføre brugertests af tilgængelighed. Det er som usertesting.com, men specifikt til tilgængelighed. Samarbejd med disse aktører og organisationer for at forstå, hvad du bygger, og hvordan du bygger det.

Når du begynder design- og iterationsprocessen, skal du desuden inkludere nogen med den rette ekspertise. Få enten din designer til at tage et kursus i design for tilgængelighed, eller sørg for, at en person med ekspertise inden for tilgængelighed deltager i processen helt fra designfasen. Sørg for, at dine designs har tilgængelighedsspecifikationer.

Det er nemlig det, dine ingeniører vil støtte sig til, når de skal beslutte og finde ud af, hvordan noget skal bygges. Sørg for, at designerne og tilgængelighedseksperterne deltager i testningen. Sådan sikrer du, at alt, hvad du bygger fremadrettet, bliver tilgængeligt.

I stedet for igen at skulle kæmpe og derefter lave det hele om senere.

Hannah Clark: Alle, der har lyttet til programmet længe, ved, at jeg elsker konkrete og handlingsanvisende råd. Detaljerede råd. Så tak, fordi du kommer med disse meget specifikke anbefalinger. For at runde af, da vi snart afslutter, vil jeg gerne sikre mig, at vi kommer ind på analyse.

Vi nævnte data for ikke så længe siden, og jeg vil gerne vende tilbage til, hvordan vi måler succesen af vores tilgængelighedsfunktioner og det, vi har implementeret og brugt så meget tid på at skabe sammen. Når man måler aktiveringsraten eller andre vigtige adoptionsmålinger for den almindelige befolkning, forestiller jeg mig naturligvis, at man ser på en meget anderledes eller måske delvist anderledes proces for at segmentere, hvor effektive tilgængelighedsfunktionerne er – hvad enten det gælder introduktion eller andre tilgængelighedsfunktioner i produktet.

Det er et spørgsmål i flere dele. For det første: Hvordan segmenterer man det, man måler, for at sikre, at man måler succesen af de tilgængelighedsfunktioner, man har bygget, i stedet for blot produktet som helhed? Er der værktøjer, man ville bruge til det? Og har du andre tips eller tricks til at sikre, at man kan integrere den type data i fremtidige iterationer?

Prerna Ramachandra: Helt sikkert. Jeg vil give et svar, der sandsynligvis vil gøre mange produktchefer utilpasse. Det er også noget, jeg selv er utilpas ved: Man kan ikke stole på kvantitative data for at forstå, om ens tilgængelighedsfunktioner fungerer, og om produktet er tilgængeligt.

Noget af grunden er, at man moralsk og etisk ikke rigtigt kan segmentere brugere på baggrund af tilgængelighed, fordi man dermed forsøger at antage, om en person har et handicap eller ej. Selv hvis man bruger data som at måle, hvor mange brugere der anvender tastaturnavigation, eller hvor mange der har aktiveret kommandoer til skærmlæsere, kan man stadig potentielt udelukke en stor del af befolkningen.

Jeg nævnte for eksempel neurodivergens. Kan mennesker med neurodivergens bruge produktet, eller er det for overvældende? Der findes bestemte funktioner omkring det. I Slack og i mange andre produkter, der har en form for animation, kan man slå animationen fra, fordi den hos nogle mennesker kan udløse krampeanfald. Det er også vanskeligt at måle.

Man kan kun få en begrænset mængde information fra kvantitative målinger, fordi det er meget svært at segmentere brugere på den måde, man normalt ville segmentere sin brugerbase. Man foretager mange antagelser om mennesker, som man generelt ikke bør foretage.

Det vil sandsynligvis heller ikke være særligt effektivt. Der er mange ting som skjulte handicap, og tilgangen tager ikke højde for den situationsbestemte dimension, jeg talte om i begyndelsen af episoden. Det, jeg har oplevet fungerer bedst til at måle, om et produkt er tilgængeligt, er at gå tilbage til brugerne og spørge dem.

Kvalitativ research er efter min mening den bedste måde at måle succesen for tilgængelighed på. Det bygger også på meget af det, jeg har set fungere i mit tidligere og nuværende arbejde med tilgængelighed.

Jeg vil give endnu et meget konkret eksempel. En anden tilgængelighedsfunktion, vi byggede hos Slack, var grundlæggende en API, som mange forskellige teams kunne bruge til nemt at indbygge tastaturnavigation i deres produkt. Det kræver nemlig specialiseret ekspertise, og mange teams havde ikke den.

API’en skulle gøre det lettere for teams. I dette tilfælde målte vi succes ved at se på, hvor mange teams der brugte API’en. Det var ikke et krav, at teams skulle bruge den; de kunne forsøge at bygge funktionen selv. Vi sagde derfor: Hvis jeres team bruger denne API, betyder det, at vi som tilgængelighedsteam har haft succes med at bygge noget, I kunne anvende, fordi vi ved, at det fungerer godt.

Det var mindre et brugermål og mere et internt teammål. Som jeg sagde, målte vi succes for brugerne ved ganske enkelt at spørge dem. Da vi lancerede introduktionsarbejdsgangen, fik vi nogle kvantitative data om, hvor mange brugere der valgte introduktionsoplevelsen for tilgængelighed. Men for det meste havde vi arbejdet hårdt på at samle grupper af brugere, som vi kunne tale med om tilgængelighed.

Når man lancerer noget, regner jeg også med, at man udfører kvalitativ research for at forstå effekten. Vi sørgede for, at grupperne omfattede brugere, der havde spurgt til tilgængelighed, brugte tilgængelighedsfunktioner osv. Det bestod i høj grad af samtaler, kvalitativ måling og kvalitativ research.

Man vil ikke kun vide, om en person bruger produktet, men også om personen er i stand til at bruge det ordentligt – altså til at gennemføre de opgaver, vedkommende ønsker at gennemføre. Hvis produktet klarer sig godt blandt størstedelen af brugerne, giver det kvantitativt allerede en retningsgivende indikation af, om produktet er tilgængeligt. Men hvis man vil tale med bestemte brugere om tilgængelighed, er man nødt til at finde disse brugere og specifikt udføre kvalitativ research og analyse for at sikre, at det fungerer, som man ønsker.

Jeg ved, at det ikke er et fantastisk svar, fordi man som produktchef virkelig leder efter tal og data. Men jeg mener også, at en del af jobbet som produktchef er at kunne acceptere den grad af usikkerhed. Og jeg vil sige dette: Man bliver aldrig perfekt.

Intet produkt vil nogensinde kunne sætte flueben ved hver eneste boks, når det handler om tilgængelighed, fordi meget af dette igen er situationsbestemt. Derfor er det så vigtigt fortsat at have disse samtaler med brugerne. Brugere, der går op i tilgængelighed, vil især være meget tydelige, fordi de ikke er vant til at få de ting, de har brug for, for blot at kunne udføre deres arbejde.

De er nødt til at sige fra for overhovedet at kunne klare sig og udføre deres arbejde ordentligt. Jeg synes derfor, man har en enorm ressource dér. Noget, jeg har måttet lære mere end nogensinde før i min karriere som produktchef, er, at det var gennem mit arbejde med tilgængelighed, jeg virkelig forstod betydningen af at tale med og lytte til sine brugere.

De kan give dig den bedste information om, hvad du har brug for at vide om, hvordan dit produkt fungerer. Der bliver ikke talt nok om, hvor vigtig den kvalitative research og den menneskelige forbindelse er. Men jeg synes virkelig, det er det, der fortæller dig, om dit produkt fungerer. Når det handler om tilgængelighed, er det afgørende at tale med mennesker.

Hannah Clark: Jeg kunne ikke være mere enig. Det her er virkelig et program, der går ind for brugerresearch. Vi lavede for et stykke tid siden en episode med Steve Portigal om, hvordan man interviewer brugere. Det er en af vores absolutte favoritter, fordi den handler om at tale med mennesker, lade dem fortælle om deres autentiske oplevelse og ikke forsøge at styre samtalen eller lade ens egne fordomme påvirke den. Det er så vigtigt i en produktudviklingsproces.

Mange tak. Det har været en virkelig sjov samtale. Jeg sætter stor pris på dit perspektiv på dette emne og på de konkrete historier om et så velkendt produkt. På den måde kan vi alle virkelig forstå og bakke op om, hvordan disse funktioner bliver til.

Hvor kan folk følge dit arbejde online eller komme i kontakt med dig?

Prerna Ramachandra: Jeg er på LinkedIn. Det er bare mit fornavn og efternavn, Prerna Ramachandra. Man kan også kontakte mig via min hjemmeside. Den hedder PrernaRamachandra.me.

Hannah Clark: Fremragende. Mange tak, fordi du var med.

Prerna Ramachandra: Mange tak, Hannah. Det var dejligt.

Hannah Clark: Tak, fordi du lyttede med. Du kan få flere gode indsigter, vejledninger og værktøjsanmeldelser ved at abonnere på vores nyhedsbrev på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved at abonnere på The CPO Club, uanset hvor du får dine podcasts.