Menneskecentreret maskinlæring

7 trin for at holde fokus på brugeren, når han designer med ML

Af Josh Lovejoy og Jess Holbrook

Maskinlæring (ML) er videnskaben til at hjælpe computere med at opdage mønstre og forhold i data i stedet for at blive programmeret manuelt. Det er et kraftfuldt værktøj til at skabe personlige og dynamiske oplevelser, og det kører allerede alt fra Netflix-henstillinger til autonome biler. Men efterhånden som der bygges flere og flere oplevelser med ML, er det klart, at UXers stadig har meget at lære om, hvordan man får brugerne til at føle kontrol over teknologien og ikke omvendt.

Som det var tilfældet med den mobile revolution, og internettet før det, vil ML få os til at genoverveje, omstrukturere, fortrænge og overveje nye muligheder for stort set enhver oplevelse, vi bygger. I Google UX-samfundet har vi startet en indsats, der kaldes "humancentreret maskinlæring" (HCML) for at hjælpe med at fokusere og vejlede den samtale. Ved hjælp af denne linse ser vi på tværs af produkter for at se, hvordan ML kan forblive jordet i menneskelige behov, mens vi løser dem på unikke måder, der kun er mulige gennem ML. Vores team hos Google samarbejder med UXere på tværs af virksomheden for at bringe dem op på hurtige grundlæggende ML-koncepter, forstå, hvordan man integrerer ML i UX-hjælpebåndet og sikre, at ML og AI er bygget på inkluderende måder.

Hvis du lige er begyndt at arbejde med ML, føler du dig måske lidt overvældet af rumets kompleksitet og den store mulighed for innovation. Langsomt ned, giv dig selv tid til at blive akklimatiseret, og lad ikke panik. Du behøver ikke genopfinde dig selv for at være værdifuld for dit team.

Vi har udviklet syv punkter til at hjælpe designere med at navigere i det nye terræn med design af ML-drevne produkter. Født ud af vores arbejde med UX- og AI-teams hos Google (og en sund dosis af prøve og fejl), vil disse punkter hjælpe dig med at sætte brugeren først, iterere hurtigt og forstå de unikke muligheder, ML skaber.

Lad os komme igang.

1. Forvent ikke, at maskinlæring skal finde ud af, hvilke problemer der skal løses

Maskinindlæring og kunstig intelligens har en masse hype omkring dem lige nu. Mange virksomheder og produkthold springer lige ind i produktstrategier, der starter med ML som en løsning og springer over med at fokusere på et meningsfuldt problem at løse.

Det er fint til ren efterforskning eller for at se, hvad en teknologi kan gøre, og inspirerer ofte til nytænkning. Hvis du ikke er på linje med et menneskeligt behov, vil du bare opbygge et meget magtfuldt system til at tackle et meget lille - eller måske ikke-eksisterende - problem.

Så vores første punkt er, at du stadig har brug for alt det hårde arbejde, du altid har gjort for at finde menneskelige behov. Dette er alt om etnografi, kontekstuelle forespørgsler, interviews, dybt hængende ud, undersøgelser, læsning af kundesupportbilletter, logsanalyse og at komme tæt på folk til at finde ud af, om du løser et problem eller adresserer et ikke-angivet behov, som folk har. Maskinlæring finder ikke ud af, hvilke problemer der skal løses. Vi er stadig nødt til at definere det. Som UXere har vi allerede værktøjer til at guide vores teams, uanset det dominerende teknologiparadigme.

2. Spørg dig selv, om ML vil løse problemet på en unik måde

Når du har identificeret det eller de behov, du vil løse, vil du vurdere, om ML kan løse disse behov på unikke måder. Der er masser af legitime problemer, der ikke kræver ML-løsninger.

En udfordring på dette tidspunkt i produktudviklingen er at bestemme, hvilke oplevelser der kræver ML, som meningsfuldt forbedres af ML, og som ikke drager fordel af ML eller endda forringes af det. Masser af produkter kan føles "smart" eller "personlig" uden ML. Bliv ikke trukket til at tro, at det kun er muligt med ML.

Gmail ser efter sætninger, der indeholder ord som

Vi har oprettet et sæt øvelser, der hjælper holdene med at forstå værdien af ​​ML i deres brugssager. Disse øvelser gør det ved at grave i detaljerne om, hvilke mentale modeller og forventninger folk kan medbringe, når de interagerer med et ML-system, samt hvilke data der skulle være behov for dette system.

Her er tre eksempler på øvelser, vi har hold, der går igennem og svarer om de anvendelsessager, de forsøger at adressere med ML:

Beskriv, hvordan en teoretisk menneskelig ”ekspert” kan udføre opgaven i dag.
Hvis din menneskelige ekspert skulle udføre denne opgave, hvordan ville du så svare dem, så de blev bedre til næste gang? Gør dette i alle fire faser af forvirringsmatrixen.
Hvis et menneske skulle udføre denne opgave, hvilke antagelser ville brugeren have, at de skal gøre?

Brug af et par minutter på at besvare hvert af disse spørgsmål afslører de automatiske antagelser, folk vil bringe til et ML-drevet produkt. De er lige så gode som anmodninger om en diskussion om et produkthold eller som stimuli i brugerundersøgelser. Vi berører dem også lidt senere, når vi kommer i gang med at definere etiketter og træningsmodeller.

Efter disse øvelser og nogle yderligere skitsering og storyboarding af specifikke produkter og funktioner, udarbejder vi derefter alle holdets produktideer i en praktisk 2x2:

Plot ideer i denne 2x2. Få teamet til at stemme om, hvilke ideer der vil have den største brugerpåvirkning, og hvilke der vil være mest forbedret med en ML-løsning.

Dette gør det muligt for os at adskille effektive ideer fra mindre virkningsfulde ideer samt se hvilke ideer der afhænger af ML kontra dem, der ikke eller måske kun drager fordel af det. Du skal allerede samarbejde med Engineering i disse samtaler, men hvis du ikke er det, er dette et godt tidspunkt at trække dem ind for at tænke på ML-realiteterne i disse ideer. Uanset hvad der har størst brugerpåvirkning og er unikt aktiveret af ML (i øverste højre hjørne af ovenstående matrix) er det, du først vil fokusere på.

3. Falske det med personlige eksempler og guider

En stor udfordring med ML-systemer er prototyper. Hvis hele produktets værdi er, at det bruger unikke brugerdata til at skræddersy en oplevelse til hende, kan du ikke bare prototype det op virkelig hurtigt og få det til at føle sig et sted i nærheden af ​​ægte. Hvis du venter med at have et fuldt bygget ML-system på plads til at teste designet, vil det sandsynligvis være for sent at ændre det på nogen meningsfuld måde efter testen. Der er dog to brugerundersøgelsesmetoder, der kan hjælpe: ved hjælp af personlige eksempler fra deltagere og Wizard of Oz-studier.

Når deltagerne undersøger brugere med tidlige mockups, skal deltagerne hente nogle af deres egne data - f.eks. personlige fotos, deres egne kontaktlister, musik- eller filmanbefalinger, de har modtaget - til sessionerne. Husk, at du skal sørge for, at du fuldt ud informerer deltagerne om, hvordan disse data bruges under test, og hvornår de bliver slettet. Dette kan endda være en slags sjovt "hjemmearbejde" for deltagerne inden sessionen (folk kan jo gerne tale om deres yndlingsfilm).

Med disse eksempler kan du derefter simulere rigtige og forkerte svar fra systemet. For eksempel kan du simulere systemet, der returnerer den forkerte filmanbefaling til brugeren for at se, hvordan hun reagerer, og hvilke antagelser hun gør om, hvorfor systemet returnerede dette resultat. Dette hjælper dig med at vurdere omkostningerne og fordelene ved disse muligheder med meget mere gyldighed end at bruge dummyeksempler eller konceptuelle beskrivelser.

Den anden tilgang, der fungerer ganske godt til test af ikke-bygget-ML-produkter, gennemfører Wizard of Oz-undersøgelser. Alle raseri på én gang faldt Wizard of Oz-studier fra fremtrædende rolle som en brugerundersøgelsesmetode i løbet af de sidste 20 år eller deromkring. Nå, de er tilbage.

Chatgrænseflader er en af ​​de nemmeste oplevelser at teste med en Wizard of Oz-tilgang. Bare hold en teamkammerat klar på den anden side af chatten for at indtaste “svar” fra “AI.” (Billede fra: https://research.googleblog.com/2017/04/federated-learning-collaborative.html)

Hurtig påmindelse: Wizard of Oz-studier har deltagerne interageret med, hvad de mener er et autonomt system, men som faktisk kontrolleres af et menneske (som regel en teamkammerat).

At have en holdkammerat efterligne et ML-systems handlinger som chatresponser, foreslå personer, som deltageren skal ringe til, eller filmforslag kan simulere interaktion med et "intelligent" system. Disse interaktioner er vigtige for at lede designet, fordi når deltagerne alvorligt kan engagere sig i det, de opfatter som en AI, vil de naturligvis have en mental model af systemet og tilpasse deres opførsel i henhold til disse modeller. At observere deres tilpasninger og andenordens interaktion med systemet er enormt værdifuldt til at informere om dets design.

4. Afvej omkostningerne ved falske positive og falske negativer

Dit ML-system vil begå fejl. Det er vigtigt at forstå, hvordan disse fejl ser ud, og hvordan de kan påvirke brugerens oplevelse af produktet. I et af spørgsmålene i punkt 2 nævnte vi noget, der kaldes forvirringsmatrix. Dette er et nøglekoncept i ML og beskriver, hvordan det ser ud, når et ML-system får det rigtigt og får det forkert.

De fire tilstande med en forvirringsmatrix, og hvad de sandsynligvis betyder for dine brugere.

Mens alle fejl er lig med et ML-system, er ikke alle fejl lige for alle mennesker. For eksempel, hvis vi havde en "er dette et menneske eller et trold?" -Klassifikator, er det ved en fejltagelse at klassificere et menneske som et trold bare en fejl i systemet. Det har ingen opfattelse af at fornærme en bruger eller den kulturelle kontekst omkring klassificeringerne, den foretager. Det forstår ikke, at folk, der bruger systemet, måske er meget mere fornærmet, når de ved et uheld bliver mærket et trold sammenlignet med, at trold, der ved et uheld bliver mærket som mennesker. Men måske er det vores folk-centriske bias, der kommer ud. :)

I ML-termer er du nødt til at foretage bevidste afvejninger mellem systemets præcision og tilbagekaldelse. Det vil sige, at du er nødt til at beslutte, om det er mere vigtigt at medtage alle de rigtige svar, selvom det betyder at lade flere forkerte ind (optimere til genkald), eller minimere antallet af forkerte svar til prisen for at udelade nogle af de rigtige (optimering til præcision). Hvis du f.eks. Søger på Google Fotos efter "legeplads", kan du muligvis se resultater som dette:

Disse resultater inkluderer et par scener af børn, der leger, men ikke på en legeplads. I dette tilfælde prioriterer tilbagekaldelse frem for præcision. Det er vigtigere at få alle legepladsfotos og inkludere et par, der ligner, men ikke er helt rigtige, end det er kun at inkludere legepladsfotos og potentielt udelukke det foto, du ledte efter.

5. Plan for samlæring og tilpasning

De mest værdifulde ML-systemer udvikler sig over tid i takt med brugernes mentale modeller. Når folk interagerer med disse systemer, påvirker de og justerer den slags output, de ser i fremtiden. Disse justeringer vil igen ændre, hvordan brugerne interagerer med systemet, hvilket vil ændre modellerne ... og så videre, i en feedback-loop. Dette kan resultere i "konspirationsteorier", hvor mennesker danner forkerte eller ufuldstændige mentale modeller af et system og løber ind i problemer med at prøve at manipulere outputene i henhold til disse imaginære regler. Du ønsker at guide brugere med klare mentale modeller, der opfordrer dem til at give feedback, der er gensidigt fordelagtigt for dem og modellen.

Et eksempel på den dydige cyklus er, hvordan Gboard løbende udvikler sig for at forudsige brugerens næste ord. Jo mere nogen bruger systemets anbefalinger, desto bedre bliver anbefalingerne. Billede fra https://research.googleblog.com/2017/05/the-machine-intelligence-behind-gboard.html

Mens ML-systemer trænes i eksisterende datasæt, tilpasser de sig med nye input på måder, som vi ofte ikke kan forudsige, før de sker. Så vi er nødt til at tilpasse vores brugerundersøgelser og feedbackstrategier i overensstemmelse hermed. Dette betyder, at man planlægger fremad i produktcyklussen for langsgående, højt berørt såvel som vidtrækkende forskning sammen. Du bliver nødt til at planlægge tid nok til at evaluere effektiviteten af ​​ML-systemer gennem kvantitative målinger af nøjagtighed og fejl, efterhånden som brugerne og brug af sager øges, samt sidde med mennesker, mens de bruger disse systemer til at forstå, hvordan mentale modeller udvikler sig med enhver succes og fiasko.

Derudover skal vi som UXere overveje, hvordan vi kan få in situ feedback fra brugere over hele produktlivscyklussen for at forbedre ML-systemerne. At designe interaktionsmønstre, der gør det let at give feedback såvel som hurtigt at vise fordelene ved denne feedback, vil begynde at differentiere gode ML-systemer fra store.

Google-appen spørger hver gang et stykke tid, om et bestemt kort er nyttigt lige nu for at få feedback om dets forslag.Folk kan give feedback om Google-søgning autofuldfør, herunder hvorfor forudsigelser kan være upassende.

6. Lær din algoritme ved hjælp af de rigtige etiketter

Som UXere er vi vant til wireframes, mockups, prototyper og redlines som vores kendetegnede leverancer. Nå, curveball: når det kommer til ML-augmented UX, er der kun så meget, vi kan specificere. Det er her "labels" kommer ind.

Etiketter er et væsentligt aspekt af maskinlæring. Der er mennesker, hvis job er at se på masser af indhold og mærke det, besvare spørgsmål som "er der en kat på dette foto?" Og når nok fotos er blevet mærket som "kat" eller "ikke kat", har du et datasæt, du kan bruge til at træne en model for at være i stand til at genkende katte. Eller mere præcist for at være i stand til med en vis tillidsniveau at forudsige, om der er en kat på et foto, som den aldrig er set før. Enkelt, ikke?

Kan du bestå denne quiz?

Udfordringen kommer, når du vove dig ind i territorium, hvor målet med din model er at forudsige noget, der måske føles subjektivt for dine brugere, som om de vil finde en artikel interessant eller et foreslået e-mail-svar meningsfuldt. Men modeller tager lang tid at træne, og at få et datasæt, der er fuldt mærket, kan være uoverkommeligt dyrt, for ikke at nævne, at det at få dine etiketter forkert kan have en enorm indflydelse på dit produkts levedygtighed.

Så sådan skal du gå frem: Start med at tage rimelige antagelser og diskutere disse antagelser med en bred vifte af samarbejdspartnere. Disse antagelser skal generelt have formen af ​​"for ________-brugere i ________-situationer. Vi antager, at de foretrækker ________ og ikke ________." Så få disse antagelser så hurtigt som muligt til den hackiest prototype for at begynde at indsamle feedback og iterere.

Find eksperter, der kan være de bedst mulige lærere for din maskinelevende - mennesker med domæneekspertise, der er relevant for alle forudsigelser, du prøver at gøre. Vi anbefaler, at du faktisk ansætter en håndfuld af dem, eller som en backback, omdanner nogen på dit team til rollen. Vi kalder disse mennesker "Indholdsspecialister" på vores team.

På dette tidspunkt har du identificeret hvilke antagelser, der føles "sandere" end andre. Men inden du går i gang og begynder at investere i storskala dataindsamling og -mærkning, vil du udføre en kritisk anden valideringsrunde ved hjælp af eksempler, der er kurateret fra reelle brugerdata af Content Specialists. Dine brugere bør teste en prototyp af høj kvalitet og opdage, at de interagerer med en legitim AI (pr. Punkt 3 ovenfor).

Med validering i hånden, skal dine indholdsspecialister oprette en bred portefølje af håndlavede eksempler på, hvad du vil have din AI til at producere. Disse eksempler giver dig en køreplan for dataindsamling, et stærkt sæt etiketter til at starte træningsmodeller og en ramme for design af store protokoller til mærkning.

7. Udvid din UX-familie, ML er en kreativ proces

Tænk på den værste ”feedback”, som du nogensinde har modtaget som UXer, til mikroadministration. Kan du forestille dig den person, der læner sig over skulderen og nit-plukke din hver bevægelse? OK, hold nu dette billede i dit sind ... og sørg for at være sikker på, at du ikke kommer på den måde til dine ingeniører.

Der er så mange mulige måder at henvende sig til enhver ML-udfordring på, så som en UXer, hvis du får for foreskrivende for hurtigt, kan det resultere i utilsigtet forankring - og derved formindske dine kreative kollegers kreativitet. Stol på dem til at bruge deres intuition og opmuntre dem til at eksperimentere, selvom de måske er tøvende med at teste med brugerne, inden der er indført en fuld evalueringsramme.

Maskinlæring er en meget mere kreativ og udtryksfuld teknisk proces, end vi generelt er vant til. Det kan være langsomt at træne en model, og værktøjerne til visualisering er endnu ikke gode, så ingeniører ender med at skulle bruge deres fantasi ofte, når de indstiller en algoritme (der er endda en metode kaldet “Aktiv læring”, hvor de manuelt “indstiller”) modellen efter hver iteration). Dit job er at hjælpe dem med at tage store brugerorienterede valg hele vejen.

Arbejd sammen med Engineering, Produkt osv. For at dele den rigtige oplevelse sammen.

Så inspirer dem med eksempler - dæk, personlige historier, visionvideoer, prototyper, klip fra brugerundersøgelser, værkerne - til, hvad en fantastisk oplevelse kunne se ud og føle sig, opbygge deres flydende i brugerundersøgelsesmål og fund og introducere dem forsigtigt til vores vidunderlige verden af ​​UX-kriterier, workshops og designsprinter for at hjælpe med at manifestere en dybere forståelse af dine produktprincipper og oplevelsesmål. Jo tidligere de bliver komfortable med iteration, desto bedre vil det være for robustheden i din ML-rørledning og for din evne til at påvirke produktet effektivt.

Konklusion

Dette er de syv punkter, vi lægger vægt på med teams i Google. Vi håber, de er nyttige for dig, som du tænker gennem dine egne ML-drevne produktspørgsmål. Efterhånden som ML begynder at drive flere og flere produkter og oplevelser, lad os gå op til vores ansvar for at forblive menneskecentreret, finde den unikke værdi for mennesker og gøre enhver oplevelse fantastisk.

Forfattere

Josh Lovejoy er en UX-designer i gruppen Research and Machine Intelligence hos Google. Han arbejder i krydset mellem interaktionsdesign, maskinlæring og ubevidst bias opmærksomhed, førende design og strategi for Googles ML Fairness-indsats.

Jess Holbrook er en UX Manager og UX forsker i gruppen Research and Machine Intelligence hos Google. Han og hans team arbejder på flere produkter drevet af AI og maskinlæring, der tager en menneskecentreret tilgang til disse teknologier.

Akiko Okazaki lavede de smukke illustrationer.