Sådan stopper UX Research som blokering

Montering af forskning i agile teams

Når det er bedst, overflader UX-forskning indsigt og muliggør fremskridt; på det værste kommer det bare i vejen.

Der er mange indvendinger mod at udføre UX-forskning, men det mest almindelige jeg hører er 'Vi har ikke nok tid.'

Jeg kan helt sikkert sympatisere med denne tilbøjelighed til at "bare få det gjort".

Med flytningen væk fra alt for administrerede vandfaldsprojekter til tværfunktionelle agile teams, kan det være svært at finde, hvor i processen forskning bedst passer.

Er din UX-forsker en del af det tværfunktionelle agile team, eller er de opdelt som deres egen separate forretningsfunktion?

Hvordan er det muligt for et team at undersøge, designe, bygge og teste den samme funktion samtidig?

Hvordan kan vi beslutte, hvad vi skal bygge, mens vi er midt i bygningen?

Indlejret, men blokerende

Et populært kompromis er at integrere UX-forskning i et agilt team, men lad forskeren arbejde et par sprints foran. En fornuftig klingende løsning, men den har ofte den uønskede konsekvens af at skabe spændinger mellem resten af ​​teamet og UX-forskeren.

Et team kan kun arbejde så hurtigt som dets langsomste proces - så det kan finde sig selv kontinuerligt blokeret af en enkelt UX-forsker, der prøver deres bedste for at følge en designproces for bedste praksis.

Et andet problem med denne fremgangsmåde er, at du i det væsentlige lige har oprettet en terrarium-størrelse vandfaldsproces i dit agile team.

Til sidst fungerer dette ikke, fordi god forskning tager tid. Du har brug for tid til at komme ud i marken; du har brug for tid til at forstå brugerne; og du har brug for tid til at følge så mange indsigter til blindgyde, som det tager, før du finder ud af, at en kerneindblik, der låser op produktgeni.

Denne type forskning kan ikke låses væk i en enkelt sprint eller to.

Ikke-blokerende, men abstraheret

En anden mulighed er, at UX-forskere skal være i deres egen separate afdeling, splitte fra de agile hold, de støtter, og ofte arbejde uger og endda måneder foran udviklerne.

Den klare fiasko her er, at forskning er bedst, når den er frisk og relevant. Brugerundersøgelser er kun gavnlig, hvis det fører til store produktoplevelser for brugerne. Den yderligere forskningsindsigt er fra deres praktiske anvendelse, jo mindre påvirkning vil de have.

Den største svaghed ved denne model er, at adskilt fra udviklerne og testernes hårde pragmatisme kan designere blive lidt for kreative.

Der bliver en kløft mellem de 'ideelle oplevelser', og hvad der kan bygges pragmatisk. Designere bliver frustrerede over udviklere, der altid siger nej, og udviklere træthed ved konstant ikke at indse de svimlende højder af en designer's vilde fantasi.

Sådan integreres UX som sin egen parallelle proces

Som du måske har samlet, hvad vi har brug for er en bedste-fra-begge-verdener løsning.

Vi er nødt til at beslutte, hvilke UX-aktiviteter, der skal forblive integreret i den agile teamstruktur, og hvilke aktiviteter der bedst spinde ud på deres egen tidslinje.

Den parallelle UX-proces

En god måde at visualisere dette er ved at opdele forskningsaktiviteter i to forskellige lejre: grundlæggende forskning kontra retningsbestemt forskning.

Grundlæggende forskning er brugerinterviews og etnografisk forskning, der skaber et solidt fundament for beslutningstagning.

Retningsbestemt forskning er de spidse anvendelighedseksperimenter, du kører, der besvarer specifikke brugerspørgsmål for at forme produktets daglige retning.

Retningsbestemt forskning

Retningsbestemt forskning er peget og har en kort levetid. Det udføres for at besvare specifikke spørgsmål om brugervenlighed og produkt ønskværdighed.

Retningsbestemt forskning lever inden for og ledes af det agile team. For at dette kan fungere godt, skal eksperimenter holdes små og uafhængige. Eksperimenter skal besvare et specifikt spørgsmål eller validere en specifik hypotese.

Direktionsforskning kommunikeres ganske enkelt i teamet og til den bredere forretning. Outputet skal være et specifikt ja / nej svar eller en klar til implementering anbefaling - ikke en 14-siders rapport.

For eksempel:

Spørgsmål

Bør knapmærkaten være 'Send' eller 'Registrer og fortsæt'?

Svar

Vi kørte en A / B-test på 500 besøgende, og 'Registrer og fortsæt' presterede 20% bedre.

Spørgsmål

Er der problemer med brugervenligheden med det aktuelle skærmdesign?

Svar

Vi gennemførte en brugbarhedstest med 6 deltagere og fandt 4 potentielle problemer. Vi anbefaler, at du (1) gør registreringsknappen mere fremtrædende, (2) ændrer formatet på adressefeltet for at acceptere P.O. bokse, (3) flytte ...

Spørgsmål

Vi mener, at vores førstegangsbrugere ved at tilføje en ny funktion vil finde produktet mere nyttigt og opgradere til den betalte version.

Svar

Vi kørte en brugbarhedstest på en tidlig prototype og fandt, at førstegangsbrugere blev overvældet af funktioner og ikke opgraderede.

Grundlæggende forskning

Grundlæggende forskning er brugerinterviews og etnografisk forskning, du udfører for at forstå dine brugers ønsker, behov, mål og motiveringer og for at få et godt afrundet billede af dine brugere.

Bemærk, at værdien af ​​denne grundlæggende forskning i diagrammet nedenfor ikke forbliver statisk. Du kan ikke bare tale med dine brugere én gang og kalde det om dagen. Markedet ændrer sig, teknologitendenser ændres, dine brugere ændres og forhåbentlig ændrer dit produkt. Din forskning bliver mindre relevant og mere uaktuel jo ældre den bliver.

Dette betyder, at grundlæggende forskning skal være igangværende. Indblik bygger over tid, og du skal aldrig afslutte at tale med og lære af dine brugere.

Grundlæggende forskning har brug for tid til at blive gennemført godt. Hold har brug for tid til at komme ud i marken og observere brugeradfærd. Holdet har brug for tid til at stille utallige spørgsmål fra utallige brugere, indtil du afslører den guldklump af indsigt, som så mange virksomheder før du har savnet.

eksempler

  • Opdagelse eller etnografisk forskning
  • Brugerinterviews
  • Personas
  • Rejse kort
  • Empatikort
  • JTBD

At bringe grundlæggende og retningsbestemte sammen

Disse to strømme af UX-forskning kan køre uafhængigt af hinanden, så både hurtig og langsom forskning kan eksistere side om side.

Så hvordan får jeg det til at arbejde med mine teams?

Hvis du er en regelmæssig læser af Medium og 1000'erne af artikler her, der dækker UX og produktproces, ville du allerede vide, at der ikke er et svar i én størrelse, der passer til alle. Du skal finde, hvad der fungerer for dig.

Så i stedet er her 6 tip, der hjælper dig med at implementere din parallelle UX-proces:

1. Dit agile team er altid den centrale og vejledende styrke

For at hold skal få succes i et smidigt miljø, er de nødt til at være virkelig selvstyrende og autonome. De har brug for forskning for at hjælpe med at informere deres beslutninger, men de skal ikke uden hensyntagen gøre, hvad UX-forskningen siger.

Dette betyder, at det agile team skal føle sig bemyndiget til både at iværksætte forskning og udføre den.

2. Vær klog med batchstørrelser og tidsboksning

Testning af en bruger tidligt i projektet er bedre end at teste 50 nær slutningen.
- Steve Krug

Det kan være fristende at ønske at udføre al din forskning i starten. Det kan være fristende at ønske at have svaret på ethvert spørgsmål, inden du går ind på en kode.

Dette er ikke realistisk. Du kan aldrig vide 'alt' der er at vide om et specifikt emne. Du har måske bemærket, at jo mere du lærer om noget, desto mere lærer du, du har brug for at vide.

Du skal være i stand til at opdele din forskning i små, håndterbare, tidsboksede bidder og bruge det, du lærer, til at informere, hvor du skal undersøge næste.

3. Brug teamets magt til at eksperimentere

Du er et tværfunktionelt team. Handle som det.

Den bedste måde at forstå brugeradfærd er at opbygge noget, frigive det og se, hvordan brugerne bruger det. Igen, start småt: Spørg dig selv, hvad er den mindste ting, du kan opbygge for at besvare dit vigtige brugerspørgsmål.

Vil kunder købe mit produkt?

Udvikl en destinationsside, og se, hvor mange brugere der klikker på 'Køb nu'.

Vil kunder bruge denne funktion?

Opret en knap til den, og se, om de klikker på den.

Skal knappen siger 'Registrer' eller 'Tilmeld'?

Kør en A / B-test og find ud af det.

Udviklere og testere kan være en UX-forskers bedste ven.

Når du er færdig med dine eksperimenter, skal du sørge for at tage dig tid til at lære af det, du har opdaget, og derefter implementere det.

4. Find tid til at re-faktor

(Gode) udviklere tager tid at konstant refactor og rydde op i deres kode. Vi bør tage os tid til at gøre det samme med vores oplevelser og interface design.

At bruge tid på at fjerne teknisk gæld gør koden mere pålidelig og bæredygtig; at fjerne vores UX-gæld gør det samme med vores oplevelser.

Udviklere og produkt ejere: hvis du bruger en lille tid på hver sprint til at rydde op i interfaceproblemer i stedet for at oplade med flere og flere nye funktioner, vil du opdage, at dine UI- og UX-designere vil slappe af og begynde at arbejde med dig i stedet for imod dig.

5. UX er en ægte tværfunktionel færdighed og ansvar

Det er for vigtigt at være begrænset til kun et teammedlem.

Du kan ikke bare ansætte en 'scrum master' og kalde dig selv en smidig forretning. På samme måde kan du ikke bare ansætte en enkelt UX-designer og kalde dig selv menneskecentreret.

Alle på teamet skal overveje brugeren. UX-designeren skal være facilitator for denne indsats. Ikke ejeren.

6. Hvis du er i tvivl, skal du omfatte Lean UX-principperne

I resumé kan UX-forskning ikke forhastes, men den kan heller ikke være ikke omfattet.

Nogle forskningsaktiviteter vil tage længere tid end andre, men det er vigtigst at skelne mellem forskning, der giver specifik værdi i øjeblikket kontra forskning, der lønner sig strategisk i det lange løb.

Grundlæggende forskningsmetoder hjælper dig med at beslutte, hvor du vil hen, mens retningsbestemte metoder giver dig skridt for tur retninger for, hvordan du kommer dertil.

Hvis du er interesseret i en eller anden sammenhæng om mig som UX-designer, så tjek min LinkedIn-konto. Du er også velkommen til at komme i kontakt gennem de almindelige kanaler (Twitter / Web) med spørgsmål eller forslag.