Mensgericht machinaal leren

7 stappen om gefocust te blijven op de gebruiker bij het ontwerpen met ML

Door Josh Lovejoy en Jess Holbrook

Machine learning (ML) is de wetenschap om computers te helpen patronen en relaties in gegevens te ontdekken in plaats van handmatig te worden geprogrammeerd. Het is een krachtig hulpmiddel voor het creëren van gepersonaliseerde en dynamische ervaringen, en het stuurt al alles aan, van Netflix-aanbevelingen tot autonome auto's. Maar naarmate meer en meer ervaringen met ML worden gebouwd, is het duidelijk dat UXers nog veel te leren hebben over hoe ze gebruikers controle over de technologie kunnen geven, en niet andersom.

Zoals het geval was met de mobiele revolutie en het internet daarvoor, zorgt ML ervoor dat we opnieuw nadenken, herstructureren, verplaatsen en nieuwe mogelijkheden overwegen voor vrijwel elke ervaring die we opbouwen. In de Google UX-gemeenschap zijn we begonnen met een inspanning die 'mensgericht machinaal leren' (HCML) wordt genoemd om dat gesprek te helpen focussen en begeleiden. Met deze lens kijken we door producten heen om te zien hoe ML geaard kan blijven in menselijke behoeften, terwijl ze op unieke manieren kunnen worden opgelost, alleen mogelijk via ML. Ons team bij Google werkt samen met UXers in het hele bedrijf om hen op de hoogte te brengen van de belangrijkste ML-concepten, begrijpt hoe ML te integreren in de UX-hulpprogramma en zorgt ervoor dat ML en AI op inclusieve manieren worden gebouwd.

Als je net met ML bent begonnen, voel je je misschien een beetje overweldigd door de complexiteit van de ruimte en de enorme hoeveelheid mogelijkheden voor innovatie. Vertraag, geef jezelf de tijd om te acclimatiseren en raak niet in paniek. U hoeft uzelf niet opnieuw uit te vinden om waardevol te zijn voor uw team.

We hebben zeven punten ontwikkeld om ontwerpers te helpen navigeren op het nieuwe terrein van het ontwerpen van ML-aangedreven producten. Geboren uit ons werk met UX- en AI-teams bij Google (en een gezonde dosis vallen en opstaan), helpen deze punten je om de gebruiker op de eerste plaats te zetten, snel te herhalen en de unieke kansen te begrijpen die ML biedt.

Laten we beginnen.

1. Verwacht niet dat Machine learning erachter komt welke problemen moeten worden opgelost

Machine learning en kunstmatige intelligentie hebben op dit moment veel hype. Veel bedrijven en productteams springen meteen in productstrategieën die beginnen met ML als oplossing en overslaan door zich te concentreren op een zinvol probleem om op te lossen.

Dat is prima voor pure verkenning of om te zien wat een technologie kan doen, en inspireert vaak het denken van nieuwe producten. Als u echter niet bent afgestemd op een menselijke behoefte, gaat u gewoon een zeer krachtig systeem bouwen om een ​​heel klein - of misschien niet-bestaand - probleem aan te pakken.

Dus ons eerste punt is dat je nog steeds al dat harde werk moet doen dat je altijd hebt gedaan om menselijke behoeften te vinden. Dit is alle etnografie, contextuele vragen, interviews, diep rondhangen, enquêtes, klantenservicetickets lezen, logboeken analyseren en mensen benaderen om erachter te komen of u een probleem oplost of een onverklaarbare behoefte aanpakt die mensen hebben. Machine learning komt niet te weten welke problemen op te lossen. Dat moeten we nog definiëren. Als UXers hebben we al de tools om onze teams te begeleiden, ongeacht het dominante technologieparadigma.

2. Vraag jezelf af of ML het probleem op een unieke manier zal aanpakken

Nadat u de behoefte of behoeften heeft vastgesteld waaraan u wilt voldoen, wilt u beoordelen of ML deze behoeften op unieke manieren kan oplossen. Er zijn tal van legitieme problemen waarvoor geen ML-oplossingen nodig zijn.

Een uitdaging op dit moment bij productontwikkeling is het bepalen welke ervaringen ML vereisen, die zinvol worden verbeterd door ML, en die niet profiteren van ML of er zelfs door worden afgebroken. Veel producten kunnen 'slim' of 'persoonlijk' aanvoelen zonder ML. Denk er niet aan dat dat alleen met ML mogelijk is.

Gmail zoekt naar zinnen zoals woorden als

We hebben een aantal oefeningen gemaakt om teams te helpen de waarde van ML voor hun gebruik te begrijpen. Deze oefeningen doen dit door in te gaan op de details van welke mentale modellen en verwachtingen mensen zouden kunnen brengen bij de interactie met een ML-systeem en welke gegevens daarvoor nodig zouden zijn.

Hier zijn drie voorbeeldoefeningen waar teams doorheen lopen en antwoorden over de use cases die ze proberen aan te pakken met ML:

Beschrijf de manier waarop een theoretische menselijke 'expert' de taak vandaag kan uitvoeren.
Als uw menselijke expert deze taak zou uitvoeren, hoe zou u dan reageren op hen zodat ze voor de volgende keer zouden verbeteren? Doe dit voor alle vier fasen van de verwarringmatrix.
Als een mens deze taak zou uitvoeren, welke aannames zou de gebruiker dan willen?

Als u slechts een paar minuten de tijd neemt om elk van deze vragen te beantwoorden, worden de automatische veronderstellingen onthuld die mensen naar een ML-aangedreven product brengen. Ze zijn even goed als aanwijzingen voor een productteambespreking of als prikkels in gebruikersonderzoek. We zullen hier ook wat later op ingaan wanneer we het proces van het definiëren van labels en trainingsmodellen beginnen.

Na deze oefeningen en wat extra schetsen en storyboards van specifieke producten en functies, zetten we vervolgens alle productideeën van het team in een handige 2x2 uiteen:

Zet ideeën in deze 2x2. Laat het team stemmen over welke ideeën de grootste gebruikersimpact zouden hebben en die het meest zouden worden verbeterd door een ML-oplossing.

Dit stelt ons in staat om impactvolle ideeën te scheiden van minder impactvolle ideeën, en om te zien welke ideeën afhankelijk zijn van ML versus degenen die er niet of slechts licht van profiteren. In deze gesprekken zou je al met Engineering moeten samenwerken, maar als je dat niet bent, is dit een goed moment om ze te betrekken bij de ML-realiteit van deze ideeën. Op wat de grootste gebruikersimpact heeft en uniek is ingeschakeld door ML (in de rechterbovenhoek van de bovenstaande matrix), moet u zich eerst richten.

3. Doe alsof met persoonlijke voorbeelden en tovenaars

Een grote uitdaging met ML-systemen is prototyping. Als de hele waarde van uw product is dat het unieke gebruikersgegevens gebruikt om een ​​ervaring op haar af te stemmen, kunt u niet alleen snel een prototype maken en het bijna authentiek laten aanvoelen. Als u wacht op een volledig gebouwd ML-systeem om het ontwerp te testen, is het waarschijnlijk te laat om het op een zinvolle manier te wijzigen na het testen. Er zijn echter twee benaderingen voor gebruikersonderzoek die kunnen helpen: persoonlijke voorbeelden van deelnemers en Wizard of Oz-onderzoeken gebruiken.

Laat gebruikers bij het doen van gebruikersonderzoek met vroege modellen een aantal van hun eigen gegevens inbrengen, bijv. persoonlijke foto's, hun eigen contactlijsten, muziek- of filmaanbevelingen die ze hebben ontvangen - voor de sessies. Vergeet niet dat u ervoor moet zorgen dat u de deelnemers volledig informeert over hoe deze gegevens worden gebruikt tijdens het testen en wanneer deze worden verwijderd. Dit kan zelfs een soort leuk 'huiswerk' zijn voor deelnemers voor de sessie (mensen praten tenslotte graag over hun favoriete films).

Met deze voorbeelden kunt u vervolgens goede en foute reacties van het systeem simuleren. U kunt bijvoorbeeld het systeem simuleren dat de verkeerde filmaanbeveling aan de gebruiker retourneert om te zien hoe ze reageert en welke veronderstellingen ze maakt over waarom het systeem dat resultaat heeft geretourneerd. Dit helpt u om de kosten en baten van deze mogelijkheden met veel meer geldigheid te beoordelen dan met dummyvoorbeelden of conceptuele beschrijvingen.

De tweede benadering die vrij goed werkt voor het testen van nog niet gebouwde ML-producten, is het uitvoeren van Wizard of Oz-onderzoeken. Alle woede in één keer, studies van Wizard of Oz raakten de laatste 20 jaar zo populair als onderzoeksmethode voor gebruikers. Nou, ze zijn terug.

Chatinterfaces zijn een van de gemakkelijkste ervaringen om te testen met een Wizard of Oz-aanpak. Houd gewoon een teamgenoot klaar aan de andere kant van de chat om 'antwoorden' van de 'AI' in te voeren (afbeelding van: https://research.googleblog.com/2017/04/federated-learning-collaborative.html)

Snelle herinnering: in Wizard of Oz-onderzoeken hebben deelnemers interactie met wat zij denken dat een autonoom systeem is, maar dat in feite wordt bestuurd door een mens (meestal een teamgenoot).

Een teamgenoot de acties van een ML-systeem laten nabootsen, zoals chatreacties, suggereert mensen die de deelnemer zou moeten bellen, of filmsuggesties kunnen de interactie met een "intelligent" systeem simuleren. Deze interacties zijn essentieel voor het sturen van het ontwerp, omdat wanneer deelnemers serieus kunnen omgaan met wat zij als een AI beschouwen, zij van nature de neiging hebben een mentaal model van het systeem te vormen en hun gedrag aan te passen aan de hand van die modellen. Het observeren van hun aanpassingen en tweede-orde interacties met het systeem is enorm waardevol voor het informeren van het ontwerp.

4. Weeg de kosten van valse positieven en valse negatieven

Uw ML-systeem zal fouten maken. Het is belangrijk om te begrijpen hoe deze fouten eruit zien en hoe ze de gebruikerservaring van het product kunnen beïnvloeden. In een van de vragen in punt 2 hebben we iets genoemd dat de verwarringmatrix wordt genoemd. Dit is een sleutelconcept in ML en beschrijft hoe het eruit ziet als een ML-systeem het goed en fout doet.

De vier toestanden van een verwarringmatrix en wat ze waarschijnlijk voor uw gebruikers betekenen.

Hoewel alle fouten gelijk zijn aan een ML-systeem, zijn niet alle fouten gelijk aan alle mensen. Als we bijvoorbeeld de classificatie 'is dit een mens of een trol?' Hebben, dan is het per ongeluk classificeren van een mens als een trol slechts een fout in het systeem. Het heeft geen idee van het beledigen van een gebruiker of de culturele context rond de classificaties die het maakt. Het begrijpt niet dat mensen die het systeem gebruiken, veel meer beledigd kunnen zijn als ze per ongeluk een trol worden gelabeld dan trollen die per ongeluk als mensen worden gelabeld. Maar misschien komt dat door onze mensgerichtheid. :)

In ML-termen moet u een bewuste afweging maken tussen de precisie en het terugroepen van het systeem. Dat wil zeggen, u moet beslissen of het belangrijker is om alle juiste antwoorden op te nemen, zelfs als dit betekent dat er meer foute antwoorden binnenkomen (optimaliseren voor terugroepen), of het aantal foute antwoorden minimaliseren ten koste van het weglaten van juiste (optimalisatie voor precisie). Als u bijvoorbeeld op Google Foto's naar 'speeltuin' zoekt, ziet u mogelijk dit soort resultaten:

Deze resultaten omvatten een paar scènes van spelende kinderen, maar niet op een speelplaats. In dit geval heeft terugroepen prioriteit boven precisie. Het is belangrijker om alle foto's van de speeltuin te krijgen en er een paar op te nemen die op elkaar lijken, maar niet helemaal juist zijn dan alleen foto's van de speeltuin op te nemen en mogelijk de foto uit te sluiten waarnaar je op zoek was.

5. Plan voor co-learning en aanpassing

De meest waardevolle ML-systemen evolueren in de loop van de tijd samen met de mentale modellen van gebruikers. Wanneer mensen met deze systemen communiceren, beïnvloeden en passen ze het soort output aan dat ze in de toekomst zullen zien. Die aanpassingen zullen op hun beurt de manier veranderen waarop gebruikers omgaan met het systeem, wat de modellen zal veranderen ... enzovoort, in een feedbacklus. Dit kan resulteren in 'complottheorieën' waarbij mensen onjuiste of onvolledige mentale modellen van een systeem vormen en problemen tegenkomen die proberen de output te manipuleren volgens deze denkbeeldige regels. U wilt gebruikers begeleiden met duidelijke mentale modellen die hen aanmoedigen om feedback te geven die voor hen en het model wederzijds voordelig is.

Een voorbeeld van de deugdzame cyclus is hoe Gboard voortdurend evolueert om het volgende woord van de gebruiker te voorspellen. Hoe meer iemand de aanbevelingen van het systeem gebruikt, hoe beter die aanbevelingen worden. Afbeelding van https://research.googleblog.com/2017/05/the-machine-intelligence-behind-gboard.html

Hoewel ML-systemen zijn getraind op bestaande gegevenssets, passen ze zich aan met nieuwe invoer op manieren die we vaak niet kunnen voorspellen voordat ze zich voordoen. Daarom moeten we onze strategieën voor gebruikersonderzoek en feedback dienovereenkomstig aanpassen. Dit betekent vooruit plannen in de productcyclus voor longitudinaal, high-touch en breed onderzoek samen. U moet voldoende tijd plannen om de prestaties van ML-systemen te evalueren door kwantitatieve metingen van nauwkeurigheid en fouten naarmate gebruikers en gebruikstoepassingen toenemen, en met mensen zitten terwijl ze deze systemen gebruiken om te begrijpen hoe mentale modellen evolueren met elk succes en mislukking.

Bovendien moeten we als UXers nadenken over hoe we in situ feedback van gebruikers kunnen krijgen gedurende de hele productlevenscyclus om de ML-systemen te verbeteren. Door interactiepatronen te ontwerpen die het geven van feedback gemakkelijk maken en de voordelen van die feedback snel laten zien, zullen goede ML-systemen zich gaan onderscheiden van geweldige.

De Google-app vraagt ​​af en toe of een bepaalde kaart nu nuttig is om feedback te krijgen op de suggesties.Mensen kunnen feedback geven op Google Search Autocomplete, inclusief waarom voorspellingen ongepast kunnen zijn.

6. Leer uw algoritme aan de hand van de juiste labels

Als UXers zijn we gewend geraakt aan wireframes, mockups, prototypes en redlines als onze kenmerkende producten. Nou, curveball: als het gaat om ML-augmented UX, is er maar zoveel dat we kunnen specificeren. Dat is waar "labels" binnenkomen.

Labels zijn een essentieel aspect van machine learning. Er zijn mensen wiens taak het is om naar tonnen inhoud te kijken en deze te labelen, en vragen te beantwoorden als "zit er een kat op deze foto?" En zodra voldoende foto's zijn gelabeld als "kat" of "geen kat", heb een gegevensset die u kunt gebruiken om een ​​model te trainen om katten te kunnen herkennen. Of beter gezegd, om met een zeker betrouwbaarheidsniveau te kunnen voorspellen of er een kat op een foto staat die hij nog nooit eerder heeft gezien. Simpel toch?

Kun jij deze quiz doorgeven?

De uitdaging komt wanneer u zich op een terrein begeeft waar het doel van uw model is om iets te voorspellen dat misschien subjectief aanvoelt voor uw gebruikers, zoals of ze een artikel interessant of een gesuggereerd e-mailantwoord zinvol vinden. Maar modellen doen er lang over om te trainen, en het volledig labelen van een dataset kan onbetaalbaar zijn, om nog maar te zwijgen over het feit dat het verkeerd hebben van uw labels een enorme impact kan hebben op de levensvatbaarheid van uw product.

Dus ga als volgt te werk: begin met het maken van redelijke veronderstellingen en bespreek die veronderstellingen met een breed scala aan medewerkers. Deze veronderstellingen moeten over het algemeen de vorm aannemen van "voor ________-gebruikers in ________-situaties, nemen we aan dat ze de voorkeur geven aan ________ en niet ________." Breng deze veronderstellingen zo snel mogelijk in het meest hacky-prototype om feedback te verzamelen en itereren.

Zoek experts die de best mogelijke leraren kunnen zijn voor uw machineleerling - mensen met domeinexpertise die relevant zijn voor de voorspellingen die u probeert te doen. We raden je aan om een ​​handvol van hen in dienst te nemen, of als een fallback iemand in je team in de rol te veranderen. We noemen deze mensen 'inhoudsspecialisten' in ons team.

Op dit punt zult u hebben vastgesteld welke veronderstellingen "waarachtiger" aanvoelen dan anderen. Maar voordat u groot gaat worden en begint te investeren in grootschalige gegevensverzameling en etikettering, wilt u een kritische tweede ronde van validatie uitvoeren met behulp van voorbeelden die zijn samengesteld op basis van echte gebruikersgegevens door inhoudsspecialisten. Uw gebruikers zouden een hifi-prototype moeten testen en moeten waarnemen dat ze communiceren met een legitieme AI (per punt # 3 hierboven).

Met validatie in de hand, laat uw inhoudsspecialisten een breed portfolio met handgemaakte voorbeelden maken van wat u wilt dat uw AI produceert. Deze voorbeelden geven u een stappenplan voor gegevensverzameling, een sterke set labels om trainingsmodellen te starten en een kader voor het ontwerpen van grootschalige etiketteringsprotocollen.

7. Breid uw UX-familie uit, ML is een creatief proces

Denk aan de slechtste "feedback" van het microbeheer die u ooit als UXer heeft ontvangen. Kun je je de persoon voorstellen die over je schouder leunt en bij elke beweging nit kiest? OK, houd dat beeld nu in gedachten ... en zorg er absoluut voor dat je zo niet tegenkomt aan je ingenieurs.

Er zijn zoveel mogelijke manieren om elke ML-uitdaging te benaderen, dus als een UXer kan het te snel voorgeschreven worden leiden tot onbedoeld verankeren - en daarmee de creativiteit van - uw technische tegenhangers. Vertrouw erop dat ze hun intuïtie gebruiken en moedig ze aan om te experimenteren, zelfs als ze aarzelend zijn om met gebruikers te testen voordat er een volledig evaluatiekader is.

Machine learning is een veel creatiever en expressiever engineeringproces dan we in het algemeen gewend zijn. Het trainen van een model kan traag zijn, en de hulpmiddelen voor visualisatie zijn nog niet geweldig, dus technici moeten hun verbeelding vaak gebruiken bij het afstemmen van een algoritme (er is zelfs een methode genaamd "Actief leren" waar ze handmatig "afstemmen" het model na elke iteratie). Het is jouw taak om hen te helpen geweldige keuzes te maken waarbij de gebruiker centraal staat.

Werk samen met Engineering, Product, etc. om de juiste ervaring samen te stellen.

Dus inspireer ze met voorbeelden - dekken, persoonlijke verhalen, visievideo's, prototypen, clips van gebruikersonderzoek, de werken - van hoe een geweldige ervaring eruit zou kunnen zien en aanvoelen, hun vloeiendheid in doelen en bevindingen van gebruikersonderzoek opbouwen en ze voorzichtig introduceren naar onze wondere wereld van UX-crits, workshops en ontwerpsprints om een ​​dieper inzicht in je productprincipes en ervaringsdoelen te helpen manifesteren. Hoe eerder ze vertrouwd raken met iteratie, hoe beter het zal zijn voor de robuustheid van uw ML-pijplijn en voor uw vermogen om het product effectief te beïnvloeden.

Gevolgtrekking

Dit zijn de zeven punten die we met teams in Google benadrukken. We hopen dat ze nuttig voor u zijn als u nadenkt over uw eigen ML-aangedreven productvragen. Naarmate ML meer en meer producten en ervaringen gaat aandrijven, laten we onze verantwoordelijkheid opnemen om mensgericht te blijven, de unieke waarde voor mensen te vinden en elke ervaring geweldig te maken.

auteurs

Josh Lovejoy is een UX Designer in de Research and Machine Intelligence-groep bij Google. Hij werkt op het snijvlak van interactieontwerp, machinaal leren en onbewust vooroordeel, toonaangevend ontwerp en strategie voor de ML Fairness-inspanningen van Google.

Jess Holbrook is UX Manager en UX Researcher in de groep Research and Machine Intelligence bij Google. Hij en zijn team werken aan meerdere producten op basis van AI en machine learning die een mensgerichte benadering van deze technologieën hanteren.

Akiko Okazaki heeft de prachtige illustraties gemaakt.