Hoe ik ontwikkelaar UX bij Google doe

Uitgelegd via een gebruikersstudie van Flutter

Als mensen het hebben over User Experience (UX), praten ze vaak over hun favoriete consumentenproducten: een smartphone, een berichten-app of misschien een koptelefoon.

Gebruikerservaring is ook belangrijk wanneer u iets voor ontwikkelaars bouwt. Mensen vergeten vaak dat ontwikkelaars ook gebruikers zijn en softwareontwikkeling is een intrinsiek menselijke activiteit die niet alleen wordt beperkt door hoe computers werken, maar ook hoe programmeurs werken. Toegegeven, er zijn minder ontwikkelaars dan consumenten in het algemeen, maar hoe bruikbaarder de ontwikkeltools zijn, hoe meer energieontwikkelaars kunnen besteden aan het leveren van waarde aan hun gebruikers. Daarom is de UX van ontwikkelaarsproducten net zo belangrijk als voor consumentenproducten. In dit bericht ga ik de ontwikkelaarservaring introduceren, een van de manieren uitleggen waarop we deze beoordelen bij Google en enkele lessen delen die we hebben geleerd uit een specifiek onderzoek dat we hebben uitgevoerd op Flutter, een nieuwe SDK voor het bouwen van prachtige mobiele apps.

Het idee van ontwikkelaarservaring is niet bepaald nieuw. Onderzoek naar de ervaring van ontwikkelaars gaat terug tot de begindagen van het computergebruik, aangezien alle gebruikers in die tijd tot op zekere hoogte ontwikkelaars waren. "The Psychology of Computer Programming", gepubliceerd in 1971, is een historisch boek over dit onderwerp. Als we het hebben over de ervaring van ontwikkelaars, met name wanneer we de term toepassen op een SDK of bibliotheek, verwijzen we meestal naar drie aspecten van het product:

  • API-ontwerp, inclusief het benoemen van klassen, methoden en variabelen, het abstractieniveau van de API, de organisatie van de API en de manier waarop de API wordt aangeroepen.
  • Documentatie, die zowel de API-referentie als andere leermiddelen bevat, zoals tutorials, how-tos en handleidingen voor ontwikkelaars.
  • Tooling, die zowel de opdrachtregelinterface (CLI) als de GUI-tools omvat die helpen bij het bewerken, debuggen en testen van de code. Onderzoek heeft bijvoorbeeld aangetoond dat autocomplete in de IDE een grote impact heeft op hoe API's worden ontdekt en gebruikt bij het programmeren.

Deze drie pijlers van ervaring met ontwikkelaars vullen elkaar aan, dus moeten ze als een pakket worden ontworpen en beoordeeld.

Hoe observeren we ontwikkelaarservaring?

Een van de onderzoeksmethoden die we gebruiken om de ervaring van ontwikkelaars te beoordelen, is observeren hoe echte ontwikkelaars een realistische programmeertaak uitvoeren met behulp van onze SDK en dev-tools. Deze methode, die gebruikerstests wordt genoemd, wordt veel gebruikt in UX-consumentenonderzoek en we hebben deze aangepast om ontwikkelaarsproducten te evalueren. In deze specifieke studie over Flutter hebben we 8 professionele ontwikkelaars uitgenodigd en elk van hen gevraagd om de mock-up aan de linkerkant te implementeren.

Een belangrijke techniek die bij dit proces betrokken is, is het hardop denkprotocol. Het is een verbaal rapportageprotocol ontwikkeld door Clayton Lewis bij IBM en het is nuttig om de redenering van de deelnemer achter hun acties te begrijpen. We hebben onze deelnemers de volgende instructies gegeven:

"Als je aan de programmeeroefening werkt, denk dan alsjeblieft hardop."

We hebben onze deelnemers verder gerustgesteld dat we Flutter aan het evalueren waren, niet hun programmeervaardigheden:

"Vergeet niet dat we de ontwikkelaarservaring van Flutter testen - het is geen test van jou. Dus alles wat je verwarrend vindt, is iets dat we moeten oplossen. "

We begonnen elke sessie met een warming-up-interview over de achtergrond van de deelnemer en daarna hadden ze ongeveer 70 minuten aan de taak gewerkt. In de laatste 10 minuten van de sessie hebben we de deelnemer geïnformeerd over hun ervaringen. Elke studiesessie, inclusief het computerscherm van de deelnemer, werd privé live gestreamd naar een aparte vergaderruimte die door verschillende technici van het productteam werd bekeken. Om de privacy van deelnemers te beschermen, verwijzen we naar hen door middel van ID's (bijvoorbeeld P1, P2, P3, enz.) Anders dan hun namen in dit bericht.

Dus, wat hebben we geleerd over ervaringen van ontwikkelaars uit deze studie?

1. Geef veel voorbeelden en presenteer ze effectief

Na slechts een paar testsessies voor gebruikers werd het duidelijk dat ontwikkelaars verwachtten te leren werken met een nieuwe SDK uit voorbeelden. Het probleem was echter niet dat Flutter niet genoeg voorbeelden gaf - het had tonnen voorbeelden in zijn Github-repository. Het probleem was dat die voorbeelden niet waren georganiseerd en gepresenteerd op een manier die onze deelnemers aan de studie om twee redenen daadwerkelijk ten goede kwam:

Ten eerste misten de codevoorbeelden in Flutter's Github-repository schermafbeeldingen. Destijds bood de website van Flutter een link om in alle codevoorbeelden te zoeken die een bepaalde widgetklasse in de Github-repo bevatten, maar het was moeilijk voor deelnemers om te bepalen welk voorbeeld het gewenste resultaat zou opleveren. Je moest de voorbeeldcode op een apparaat of een simulator uitvoeren om het uiterlijk van de widget te zien, wat niemand de moeite nam te doen.

“Dit is leuk, linken naar de werkelijke code. Maar het is heel moeilijk om te kiezen welke je wilt gebruiken, tenzij je de uitvoer ziet. ”(P4)

Ten tweede verwachtten deelnemers dat ze voorbeeldcode in de API-documentatie zouden hebben, niet op een aparte plaats. Trial and error is een veel voorkomende manier om een ​​API te leren, en korte fragmenten in API-documenten maken die leermethode mogelijk.

"Ik klik op" Documentatie ", maar het zijn API's, geen voorbeelden." (P4)

Verschillende ingenieurs van het Flutter-team observeerden studiesessies via livestream en werden getroffen door de uitdagingen die sommige deelnemers ondervonden. Als gevolg hiervan heeft het team gestaag meer voorbeeldcode toegevoegd aan Flutter's API-documenten (bijv. ListView en Card).

Daarnaast is het team begonnen met het samenstellen van een samengestelde, visuele catalogus voor grotere codevoorbeelden. Er zijn momenteel slechts een handvol voorbeelden, maar elk voorbeeld heeft een screenshot en zelfstandige code, zodat ontwikkelaars snel kunnen bepalen of een voorbeeld nuttig is voor hun probleem.

2. Pas de cognitieve vaardigheden van ontwikkelaars aan

Programmeren is een cognitief intense activiteit. In dit geval vonden we dat het schrijven van een UI-lay-out puur in code moeilijk was voor sommige ontwikkelaars. In een Flutter-app omvat het bouwen van een lay-out het selecteren en nesten van widgets in een boom. Als u bijvoorbeeld de lay-out op de informatiekaart van het café wilt maken, moet u verschillende rijwidgets en verschillende kolomwidgets correct organiseren. Het zag er niet uit als een zware taak, maar drie deelnemers wisselden Rij en Kolom door elkaar toen ze probeerden die lay-out te maken.

“Kun je me vertellen wat je verwachtte dat de uitvoer zou zijn?” (Moderator)
[Praten door wat hij wilde doen] "Oh ... ik had waarschijnlijk een kolom moeten gebruiken, geen rij." (P6)

We wenden ons tot Cognitieve Psychologie voor uitleg. Het blijkt dat het bouwen van een lay-out in code de mogelijkheid vereist om te redeneren over de ruimtelijke relatie tussen objecten, en het staat bij cognitieve psychologen bekend als ruimtelijke visualisatievermogen. Het is dezelfde vaardigheid die beïnvloedt hoe goed een persoon een routebeschrijving kan verklaren of een magische kubus kan draaien.

Deze bevinding heeft de kijk van sommige teamleden op de behoefte aan een visuele UI-builder veranderd. Het team was erg enthousiast om community-driven verkenningen op dit front te zien, zoals deze webgebaseerde UI-bouwer genaamd Flutter Studio.

3. Bevorder erkenning boven terugroeping

Het is een bekend UX-principe dat gebruikersinterfaces moeten vermijden dat gebruikers worden gedwongen informatie op te roepen (bijvoorbeeld een geheimzinnige opdracht of parameter). In plaats daarvan zou de gebruikersinterface gebruikers in staat moeten stellen mogelijke handelwijzen te herkennen.

Hoe is dit principe relevant voor softwareontwikkeling? Een probleem dat we hebben opgemerkt, was dat het niet intuïtief was om het standaard lay-outgedrag van Flutter-widgets te begrijpen en erachter te komen hoe ze hun gedrag konden veranderen. P3 wist bijvoorbeeld niet waarom de kaart standaard kleiner werd dan de tekst die erin zat. P3 had moeite om erachter te komen hoe de kaart de breedte van het scherm kon vullen.

body: nieuwe kaart (
  child: nieuwe tekst (
    ‘1625 Charleston Road, Mountain View, CA 94043’
  )
)
“Wat ik wilde, was dat het de volledige breedte van het scherm zou innemen.” (P3)

Natuurlijk kunnen veel programmeurs daar uiteindelijk achter komen, maar ze moeten zich herinneren hoe ze het moeten doen de volgende keer dat ze met hetzelfde probleem worden geconfronteerd. Er waren geen zichtbare aanwijzingen voor ontwikkelaars om een ​​oplossing in die situatie te herkennen.

Het team onderzoekt een paar richtingen om de terugroepingslast bij het bouwen van lay-outs te verminderen:

  • Samenvatting van het lay-outgedrag van widgets zodat ze gemakkelijker te redeneren zijn.
  • Het aanbieden van lay-outvoorbeelden met zowel code als afbeeldingen om sommige terugroepopdrachten om te zetten in herkenningstaken
  • Biedt een Chrome-stijl inspecteur om de "berekende waarde" van een widgeteigenschap weer te geven

4. Verwacht dat ontwikkelaars blind zijn voor iets "recht voor hen"

Een kenmerk waar het Flutter-team echt trots op is, is Hot Reload. Hiermee kan de ontwikkelaar binnen 1 seconde wijzigingen aanbrengen in een actieve app, zonder de app-status te verliezen. Een Hot Reload uitvoeren is net zo eenvoudig als klikken op een knop in de IntelliJ IDE of op ‘r’ drukken in de console.

In de eerste paar sessies van het onderzoek was het team echter verbaasd over de verwachting van sommige deelnemers om Hot Reload te activeren bij het opslaan van bestanden, ondanks het feit dat de Hot Reload-knop in een geanimeerde gif werd getoond in de instructies Aan de slag. Hoe konden ze de Hot Reload-knop niet zien?

Het bleek dat deelnemers die de Hot Reload-knop misten en verwachtten opnieuw laden te activeren bij het opslaan, gebruikers waren van React Native. Ze vertelden ons dat in React Native, Hot Reload automatisch werd uitgevoerd bij het opslaan van bestanden.

Het reeds bestaande mentale model van een ontwikkelaar kan zijn perceptie veranderen en leiden tot een zekere mate van "blindheid" voor UI-elementen. Het team heeft meer visuele aanwijzingen toegevoegd om de knop Hot Reload te helpen ontdekken. Bovendien hebben sommige ingenieurs een betrouwbare manier onderzocht om herladen mogelijk te maken voor gebruikers die dit nodig hebben.

5. Ga er niet vanuit dat programmeurs Engelse woorden lezen zoals verwacht wanneer ze in code verschijnen

In Flutter is alles een widget. Een gebruikersinterface bestaat voornamelijk uit nest-widgets. Sommige widgets nemen slechts één kind, terwijl anderen meerdere kinderen nemen. Dit onderscheid wordt aangegeven door het bestaan ​​van een eigenschap "child" of een eigenschap "child" in een widgetklasse. Het klinkt vrij eenvoudig, toch?

Wij dachten dat ook. Voor sommige deelnemers gaf de enkele vorm van het woord echter niet aan dat slechts één widget in de huidige widget kon worden genest. Ze betwijfelden of 'kind' echt 'slechts één' betekende.

"Ik denk dat het" kind "meerdere kinderen kan zijn of niet. Kan ik een array doorgeven of is er maar één mogelijk? ”(P2)
"Dus het‘ kind ’zal 4 dingen zijn, het eerste item, een scheidingsteken en nog twee items." (P2)

Deze verkeerde interpretatie van de semantiek van de eigenschapsnaam leidde tot verkeerde code zoals deze:

En het foutbericht dat in dit geval wordt weergegeven, hoewel nauwkeurig, was niet bruikbaar genoeg om de deelnemer terug op het juiste pad te duwen:

Het is gemakkelijk om te negeren wat hier is gebeurd als een beginnersfout. Het team vond het echter niet prettig om een ​​professionele ontwikkelaar enkele minuten te zien verspillen met dit eenvoudige probleem. Dus een kortetermijnoplossing werd geland een paar dagen nadat de onderzoeksresultaten waren gerapporteerd. Het heeft een van de handigste multi-child widgets, Kolom, toegevoegd aan de app-sjabloon die je krijgt door de opdracht ‘flutter create’ uit te voeren. Het doel is om het verschil tussen ‘kind’ en ‘kinderen’ vroeg genoeg aan een nieuwe ontwikkelaar bloot te leggen, zodat ze geen tijd verspillen om daar achter te komen. Bovendien onderzoeken sommige teamleden een oplossing op langere termijn om de bruikbaarheid van foutmeldingen in situaties als deze en verder te verbeteren.

Gevolgtrekking

We kunnen veel leren van het observeren van ontwikkelaars die API's gebruiken en lessen toepassen om de gebruikerservaring van een ontwikkelaarsproduct te verbeteren. Als u code schrijft of een tool bouwt die door andere ontwikkelaars wordt gebruikt, raden we u aan te observeren hoe zij deze gebruiken. Zoals een Flutter-ingenieur het uitdrukte, leer je altijd iets nieuws van het observeren van een gebruikersonderzoek. Omdat software veranderingen in de wereld blijft stimuleren, moeten we ervoor zorgen dat ontwikkelaars zo productief en gelukkig mogelijk zijn.