Hvordan gør jeg Developer UX hos Google

Forklaret gennem en brugerundersøgelse af Flutter

Når folk taler om brugeroplevelse (UX), taler de ofte om deres elskede forbrugerprodukter: en smartphone, en meddelelsesapp eller måske et par hovedtelefoner.

Brugeroplevelse betyder også noget, når du bygger noget til udviklere. Folk har en tendens til at glemme, at udviklere også er brugere, og softwareudvikling er en iboende menneskelig aktivitet, der kun er begrænset af, hvordan computere fungerer, men også hvordan programmerere fungerer. Der er ganske vist færre udviklere end forbrugere generelt, men jo mere brugbare udviklerværktøjer er, jo mere energiudviklere kan bruge på at levere værdi til deres brugere. Derfor er UX for udviklerprodukter lige så vigtig som for forbrugerprodukter. I dette indlæg vil jeg introducere udvikleroplevelsen, forklare en af ​​måderne, vi vurderer den på Google, og dele nogle lektioner, vi har lært af en specifik undersøgelse, vi udførte på Flutter, en ny SDK til opbygning af smukke mobile apps.

Ideen om udvikleroplevelse er ikke helt ny. Forskning om udvikleroplevelse går tilbage til de tidlige dage med computing, da alle brugere på det tidspunkt var udviklere til en vis grad. "The Psychology of Computer Programming", udgivet i 1971, er en milepælbog om emnet. Når vi taler om udvikleroplevelse, især anvendelse af udtrykket på en SDK eller bibliotek, henviser vi normalt til tre aspekter af produktet:

  • API Design, som inkluderer navngivning af klasser, metoder og variabler, abstraktionsniveauet for API, organisering af API og den måde, hvorpå API påberopes.
  • Dokumentation, der inkluderer både API-reference og andre indlæringsressourcer, f.eks. Tutorials, how-tos og udviklervejledninger.
  • Værktøj, som involverer både kommandolinjegrænsefladen (CLI) og GUI-værktøjer, der hjælper med at redigere, debugging og teste koden. For eksempel har forskning vist, at autofuldførelse i IDE har en stor indflydelse på, hvordan API'er opdages og bruges i programmering.

Disse tre søjler med udvikleroplevelse supplerer hinanden, så de skal designes og vurderes som en pakke.

Hvordan ser vi udvikleroplevelsen?

En af de forskningsmetoder, vi bruger til at vurdere udvikleroplevelse, er at observere, hvordan virkelige udviklere udfører en realistisk programmeringsopgave ved hjælp af vores SDK og dev-værktøjer. Denne metode, kaldet brugertest, er vidt brugt i forbruger UX-forskning, og vi tilpassede den til at evaluere udviklerprodukter. I denne specifikke undersøgelse af Flutter inviterede vi 8 professionelle udviklere og bad hver af dem om at implementere mock-upen til venstre.

En nøgleteknik, der er involveret i denne proces, er tænk højt protokollen. Det er en verbal rapporteringsprotokol udviklet af Clayton Lewis hos IBM, og det er nyttigt at forstå deltagerens begrundelse bag deres handlinger. Vi gav vores deltagere følgende instruktioner:

”Når du arbejder med programmeringsøvelsen, skal du" tænke højt ". Det betyder verbalt at beskrive din mentale proces, når den udvikler sig, herunder de tvivl og spørgsmål, du har, de løsningsstrategier, du overvejer, og de grunde, der berettiger dine beslutninger.”

Vi forsikrede yderligere vores deltagere om, at vi vurderede Flutter, ikke deres programmeringsevner:

”Husk, at vi tester udvikleroplevelsen af ​​Flutter - det er ikke en test af dig. Så alt hvad du finder forvirrende er noget, vi er nødt til at ordne. ”

Vi startede hver session med en opvarmningssamtale om deltagerens baggrund, og derefter havde de cirka 70 minutter på at arbejde med opgaven. I de sidste 10 minutter af sessionen beskrev vi deltageren om deres oplevelse. Hver undersøgelsessession, inklusive deltagerens computerskærm, blev livestreamet privat til et separat mødelokale, der blev overvåget af flere ingeniører i produktgruppen. For at beskytte deltagernes privatliv henviser vi til dem med identifikatorer (f.eks. P1, P2, P3 osv.) Bortset fra deres navne i dette indlæg.

Så hvad lærte vi om udvikleroplevelser fra denne undersøgelse?

1. Giv mange eksempler, og præsenter dem effektivt

Efter blot et par brugertestsessioner blev det klart, at udviklere forventede at lære at arbejde med en ny SDK ud fra eksempler. Problemet var dog ikke, at Flutter ikke gav nok eksempler - det havde mange eksempler i sit Github-arkiv. Problemet var, at disse eksempler ikke var organiseret og præsenteret på en måde, der faktisk var nyttige for vores studiedeltagere af to grunde:

For det første manglede kodeprøverne i Flutter's Github-arkiv skærmbilleder. På det tidspunkt leverede Flutter's websted et link til at søge i alle kodeeksempler, der indeholdt en bestemt widget-klasse i sin Github-repo, men det var svært for deltagerne at bestemme, hvilket eksempel der ville give det ønskede resultat. Du var nødt til at køre eksempelkoden på en enhed eller en simulator for at se widgetets udseende, som ingen gider at gøre.

”Dette er rart, der linker til den faktiske kode. Men det er meget vanskeligt at vælge, hvilken du vil bruge, medmindre du ser output. ”(P4)

For det andet forventede deltagere at have prøvekode i API-dokumentationen, ikke et separat sted. Prøve og fejl er en almindelig måde at lære et API på, og korte uddrag i API-dokumenter aktiverer denne læringsmetode.

"Jeg klikker på 'Dokumentation', men det er API'er, ikke eksempler." (P4)

Flere ingeniører i Flutter-teamet observerede undersøgelsessessioner over livestream, og de blev ramt af de udfordringer, som nogle deltagere oplevede. Som et resultat har teamet støt tilføjet mere prøvekode til Flutter's API-dokumenter (f.eks. ListView og Card).

Derudover startede teamet med at opbygge et kurateret, visuelt katalog til større kodeprøver. Der er kun en håndfuld eksempler i øjeblikket, men hver prøve har et skærmbillede og en selvstændig kode, så udviklere hurtigt kan bestemme, om en prøve er nyttig til deres problem.

2. Tilpas udviklernes kognitive evner

Programmering er en kognitivt intens aktivitet. I dette tilfælde fandt vi, at det var vanskeligt for nogle udviklere at skrive et UI-layout rent i kode. I en Flutter-app indebærer bygning af et layout valg og indlejring af widgets i et træ. For at oprette layoutet på cafe-informationskortet skal du for eksempel organisere flere række-widgets og flere kolonne-widgets korrekt. Det så ikke ud som en hård opgave, men tre deltagere blandede række og kolonne, da de forsøgte at oprette det layout.

“Kan du fortælle mig, hvad du forventede, at output skulle være?” (Moderator)
[Taler gennem hvad han ville gøre] ”Åh… jeg burde sandsynligvis have brugt en søjle ikke en række.” (P6)

Vi henvendte os til kognitiv psykologi for at få forklaringer. Det viser sig, at opbygning af et layout i kode kræver evnen til at resonnere om det rumlige forhold mellem objekter, og det er kendt for kognitive psykologer som rumlig visualiseringsevne. Det er den samme evne, der påvirker, hvor godt en person kan forklare kørselsvejledninger eller rotere en magisk terning.

Denne konstatering har ændret nogle holdmedlemmernes syn på behovet for en visuel UI-builder. Holdet var meget begejstret over at se samfundsdrevne udforskninger på denne front, f.eks. Denne webbaserede UI-bygger, der hedder Flutter Studio.

3. Fremme anerkendelse frem for tilbagekaldelse

Det er et velkendt UX-princip, at brugergrænseflader skal undgå at tvinge brugere til at huske information (f.eks. En arkane kommando eller parameter). I stedet skal brugergrænsefladen give brugerne mulighed for at genkende mulige handlingsforløb.

Hvordan er dette princip relevant for softwareudvikling? Et problem, vi observerede, var, at det ikke var intuitivt at forstå standardlayoutadfærden for Flutter-widgets og finde ud af, hvordan man ændrer deres opførsel. For eksempel vidste P3 ikke, hvorfor kortet som standard krympet til størrelsen på den tekst, det indeholdt. P3 havde problemer med at finde ud af, hvordan man får kortet til at udfylde bredden på skærmen.

body: nyt kort (
  barn: ny tekst (
    '1625 Charleston Road, Mountain View, CA 94043'
  )
),
”Det, jeg ønskede, er at få det til at tage hele skærmbredden op.” (P3)

Selvfølgelig kan mange programmerere finde ud af det til sidst, men de er nødt til at huske, hvordan de gør det, næste gang de står over for det samme problem. Der var ingen synlige ledetråde for udviklere til at genkende en løsning i denne situation.

Holdet udforsker et par retninger for at reducere tilbagekaldelsesbyrden ved bygning af layouts:

  • Sammenfatte layoutadfærd hos widgets for at gøre dem lettere at resonnere over.
  • Tilbyder layoutprøver med både kode og billeder for at omdanne nogle tilbagekaldelsesopgaver til genkendelsesopgaver
  • Tilvejebringelse af en Chrome-stilinspektør til at vise "beregnet værdi" af en widget-egenskab

4. Forvent, at udviklere er blinde for noget "lige foran dem"

En funktion, som Flutter-teamet virkelig er stolt af, er Hot Reload. Det giver udvikleren mulighed for at anvende ændringer på en kørende app inden for 1 sekund uden at miste apptilstanden. Det er så simpelt at udføre en varm genindlæsning som at klikke på en knap i IntelliJ IDE eller trykke på 'r' i konsollen.

I de første par sessioner af undersøgelsen blev teamet dog forundret over nogle deltagernes forventning om at udløse Hot Reload på arkivering, til trods for at Hot Reload-knappen blev vist i en animeret gif i instruktionerne om Kom godt i gang. Hvordan kunne de ikke se knappen Hot Reload?

Det viste sig, at deltagere, der gik glip af Hot Reload-knappen og forventede at udløse reload med undtagelse, var brugere af React Native. De fortalte os, at i React Native blev Hot Reload automatisk udført ved arkivering.

En udviklers tidligere eksisterende mentale model kan ændre deres opfattelse og føre til en vis grad af ”blindhed” til UI-elementer. Holdet har tilføjet flere visuelle signaler til at hjælpe med at opdage Hot Reload-knappen. Desuden har nogle ingeniører undersøgt en pålidelig måde at tillade genindlæsning på gemt for brugere, der har brug for det.

5. Antag ikke, at programmerere læser engelske ord som forventet, når de vises i koden

I Flutter er alt en widget. En brugergrænseflade er primært sammensat af rednings widgets. Nogle widgets tager kun et barn, mens andre tager flere børn. Denne sondring er indikeret af eksistensen af ​​enten en "barn" egenskab eller en "børn" egenskab på en widget klasse. Det lyder ganske ligetil, ikke?

Vi troede det også. Alligevel signaliserede ordets enestående form for nogle deltagere ikke, at kun en widget kunne indlejres i den aktuelle widget. De tvivlede på, at ”barn” virkelig betød ”bare et.”

”Jeg tænker, at” barnet ”kan være flere eller ikke. Kan jeg videregive en matrix, eller er det bare muligt? ”(P2)
"Så" barnet "vil være fire ting, det første emne, en separator og to flere elementer." (P2)

Denne misfortolkning af semantikken i ejendomsnavnet førte til en fejlagtig kode som denne:

Og fejlmeddelelsen, der er vist i dette tilfælde, selvom den er nøjagtig, var ikke handling nok til at skubbe deltageren tilbage på den rigtige vej:

Det er let at afvise, hvad der skete her som en begynders fejl. Imidlertid var teamet ikke godt med at se en professionel udvikler spilder flere minutter på at håndtere dette enkle problem. Så en kortvarig fix blev landet et par dage efter, at undersøgelsesresultaterne blev rapporteret. Det føjede en af ​​de mest nyttige multi-child widgets, Kolonne, til den appskabelon, du får ved at køre kommandoen 'flutter create'. Målet er at udsætte forskellen mellem 'barn' og 'børn' for en ny udvikler tidligt, så de ikke spilder tid på at finde ud af det senere. Derudover undersøger nogle teammedlemmer en længerevarende løsning til forbedring af handlingsevnen for fejlmeddelelser i situationer som denne og videre.

Konklusion

Vi kan lære meget af at observere udviklere bruge API'er og anvende læring til forbedring af brugeroplevelsen af ​​et udviklerprodukt. Hvis du skriver en kode eller bygger et værktøj, der bruges af andre udviklere, opfordrer vi dig til at observere, hvordan de bruger den. Som en Flutter-ingeniør udtrykte det, lærer du altid noget nyt ved at observere en brugerundersøgelse. Når software fortsætter med at drive ændringer i verden, så lad os sørge for, at udviklere er så produktive og glade som muligt.