Hvordan UX Research forbedrer produktkvaliteten og reduserer utviklingstiden

Ikon for lesetid 13 min. lese


Lesere hjelper til med å støtte MSpoweruser. Vi kan få provisjon hvis du kjøper gjennom lenkene våre. Verktøytipsikon

Les vår avsløringsside for å finne ut hvordan du kan hjelpe MSPoweruser opprettholde redaksjonen Les mer

Sponset

Fordeler med UX-forskning (basert på et eksisterende prosjekt)

I praksis ønsker ikke kunder UX-forskning velkommen: det tar mye tid, og utviklingen utføres ikke i denne perioden. Det er imidlertid situasjoner hvor man ikke kan klare seg uten UX. Det var akkurat det som skjedde med et prosjekt som Andersen-teamet jobbet med.

En kunde ba oss redesigne et kundesentersystem og optimalisere denne løsningen for brukernes behov. Selskapet ønsket å få en prototype med en gang, men vi insisterte på å gjennomføre en fullverdig studie som viser fordelene med denne tilnærmingen. Vi vil fortelle deg hva som kom ut av det og hvordan vi forbedret prosjektet takket være det godt koordinerte samarbeidet med en forretningsanalytiker, en prosjektleder og en UX/UI-designer.

Hvordan det hele startet: et komplekst system med en enorm manual, akkurat som på 90-tallet

Så kunden henvendte seg til oss med ideen om en fullstendig oppdatering av deres kundesentersystem. Programmet var veldig kraftig, men solgte dårlig fordi det så utdatert ut og tok lang tid å mestre. Kunden ønsket å gjøre den mer attraktiv på markedet og optimalisere funksjonaliteten.

Andersen-teamet gjennomgikk den daværende versjonen av systemet og så flere store problemer:

Et ekstremt komplekst system.

Utviklingen av systemet startet for mer enn ti år siden. I alle disse årene har det fortsatt, og det har dukket opp en rekke oppdateringer ettersom systemet vurderte behovene til helt andre kunder og ga altfor brede tilpasningsmuligheter.

Uklar funksjonalitet.

Det andre problemet hadde røtter i det første. Overfloden av funksjonalitet førte til at navigasjonen og det generelle utseendet til systemet var utdatert og helt ulogisk og uforståelig, noe som gjorde det vanskelig å jobbe med programmet.

En enorm ubrukelig manual.

I teorien var det mulig å håndtere systemet ved hjelp av manualen, men det tok rundt tre hundre sider. I tillegg ble det skrevet som en beskrivelse av funksjonaliteten, ikke brukerscenarier, så det var ikke lett å forstå hva man skulle gjøre i en bestemt situasjon. Som vi fant ut senere, var det ingen som brukte manualen.

Et system uten kundeorientering.

Til tross for alle de ovennevnte problemene, må systemet være brukersentrert. Tross alt innebærer det å jobbe i et kundesenter en umiddelbar respons, rask interaksjon med klienter og utføre ulike operasjoner.

For å oppsummere fikk vi et komplekst uforståelig system med overdreven dokumentasjon, og det manglet kundeorientering. UX-forskning var et must i så fall.

Kilde: andersenlab.com

Hvordan UX-forskning vi forberedte og utførte

For å vise kunden hvilke problemer systemet hadde, Business Analyst and the UX/UI designer studerte manualen og den daværende versjonen av systemet og analyserte lignende systemer og konkurrenter. Det første bekjentskapet med programmet avslørte problemer med navigering og bruksanvisninger. Teamet innså at det ville være nødvendig å kommunisere med ulike interessenter (bedriftseiere, salgsavdeling) og laget en detaljert plan for videre arbeid med spesifikke tidsfrister og resultater. Annenhver uke ringte vi opp kundens ledere og PM ga rapporter og beregninger og diskuterte potensielle risikoer og forbedringer. Som et resultat visste kunden nøyaktig hva de ville motta og hvorfor de trengte det.

Det tok omtrent to måneder å studere domenet, instruksjoner for systemet, artikler om kundesentre og programvare for dem. Det var nødvendig å korrelere det som ble fortalt i manualen med det som faktisk var i systemet. Som et resultat av nøye arbeid kunne Business Analyst lage et tankekart, som presenterte strukturen til systemet og hovedfunksjonaliteten som hver av hovedenhetene utførte.

Under UX-undersøkelsen møtte vi visse hindringer. La oss snakke om dem i detalj.

Brukertesting er ikke tillatt. Hvordan ble dette problemet løst?

Teamet trengte svar på følgende spørsmål: "Hvem er brukerne våre?" og "Hvordan bruker de systemet?" Brukerroller var dårlig beskrevet i manualen, og derfor måtte vi avklare om vi forsto dem riktig.

Dessverre klarte ikke Andersen-spesialister å gjennomføre brukertesting fordi kundesenteret samarbeidet med banker, forsikringsselskaper og andre organisasjoner. I henhold til sikkerhetsreglene kan tredjepartsdata ikke overføres til noen. I tillegg, på grunn av stengte grenser, kunne vi ikke besøke klientene personlig.

Men disse hindringene stoppet oss ikke ettersom teamet vårt hadde en plan. Det var nødvendig å forstå hva kundesenterbrukere forventet, hvilke tilbud som fantes på markedet og hvordan bedrifter tiltrakk seg nye kunder. Under den første samtalen med interessenter ble forretningsanalytikeren, statsministeren og designeren bedt om å organisere nettbasert kommunikasjon med sluttbrukerne av produktet. Kunden sa ja til det, og Andersen-ansatte kunne gjennomføre en generell spørreundersøkelse og arrangere intervjuer.

Brukerintervjuer: Engelsk er ikke førstespråket til respondentene

Det var den mest interessante delen av jobben. Forretningsanalytikeren og UX/UI-designeren laget et spørreskjema for Google doc for å utforske noen av punktene. Som en del av undersøkelsen ble to tilnærminger kombinert. Takket være en kvantitativ tilnærming var det mulig å samle inn statistiske data om bruken av systemet etter brukerroller. En kvalitativ metode hjalp oss med å fordype oss i detaljene og få frem nøkkelinnsikt.

Først var det nødvendig å sjekke brukerrollene. Designeren sendte, med samtykke fra kunden, et spørreskjema til 21 kundesenterselskaper: banker, forsikringsorganisasjoner, bedrifter osv. Vi fant ut hvordan 139 ansatte fra ulike strukturer jobbet med programmet og hva deres ansvar var. UX-spesialisten lærte hvilke moduler av systemklientene som brukte oftest. Et av punktene i undersøkelsen avklarte om respondentene ønsket å snakke med Andersen-eksperter. I så fall la de igjen e-posten sin i skjemaet, og vi avtalte et intervju med dem.

Intervjuene var begrenset til 30 minutter per respondent. Det ble utarbeidet en liste med spørsmål for hver brukerrolle. Deltakernes svar ble registrert, noe som var nyttig for transkripsjon. Intervjuet ble gjennomført på engelsk, noe som var litt vanskelig fordi dette språket ikke var morsmål for våre respondenter. Likevel klarte Andersen-teamet å samle inn god innsikt, som så ble presentert for kunden i form av en rapport.


Kilde: andersenlab.com

UX-forskningsverktøy og databehandling

Mange artikler forteller hvordan du gjør UX-undersøkelser. Men de mangler informasjon om hva de skal gjøre med den store datamengden som har samlet seg siden intervjustadiet. Så laget brukte et affinitetsdiagram for å tolke resultatene.

For dette prosjektet ble affinitetsdiagrammet brukt som en metodikk for å hjelpe til med å strukturere informasjon. For å gjøre dette identifiserte vi hovedtemaene som ble dekket i intervjuet. For eksempel trakk vi ut kategorien «systemets mangler», der vi registrerte respondentenes tanker om mangler. Dessuten vurderte vi kommentarer uavhengig av roller, erfaring osv.

Meninger fra vanlige brukere (“det er for mye funksjonalitet i systemet som gjør det ubehagelig”) og administratorens bemerkning om at de ikke kan tilpasse systemet til behovene til deres bankselskap – alle disse problemene ble lagt inn i kategorien systemfeil i affinitetsdiagrammet. Dermed hjalp samtaler med respondenter oss til å oppdage hovedproblemene. Basert på disse resultatene skapte vi personas og forsto hvilke brukerproblemer vi måtte løse i utgangspunktet.

Den andre viktige fasen av å studere systemet, som forretningsanalytikeren jobbet med, var å lage BPMN-diagrammer over hovedprosessene, klassediagrammer som illustrerte forholdet mellom enheter og statusdiagrammer som viser utviklingen av individuelle elementer i systemet. Dermed beskrev vi alle forretningsprosessene i et enkelt standardisert språk. Ved å se på diagrammet kunne ledere, utviklere, konsulenter og andre spesialister som er involvert i prosessen forstå essensen av systemet uten å lese omfangsrike instruksjoner.

Hvordan forskning var med på å forme videre arbeid

I løpet av undersøkelsen fikk forretningsanalytikeren og UX/UI-designeren nok informasjon, basert på denne konklusjonen:

  • Hovedkunder er banker og forsikringsselskaper

Studien hjalp oss til å fastslå at systemet hovedsakelig ble brukt av ansatte i banker (13.7 %) og forsikringsselskaper (12.9 %), og andre institusjoner brukte det i mindre grad. Derfor bestemte Andersen-teamet seg for først og fremst å fokusere på behovene til disse kundene.

  • Interne ansatte er hovedbrukerne

Siden agenter (51.1%) spiller hovedrollen i systemet, innså teamet at de burde ta hensyn til dem når de utvikler produktet. Andre deltakere (administratorer – 10.8 %, backoffice-brukere – 10.8 %, brukere – 15.1 %, og så videre) trengte også oppmerksomhet. Du må imidlertid fokusere på avanserte brukere som er kjent med de beste UX-praksisene (f.eks. Google, Apple, etc.).

  • Systemet brukes hovedsakelig av ungdom

Basert på undersøkelsen ble det klart at brukerpublikummet til programmet er ansatte i alderen 18-30 år (67.4 %). Derfor trengte ikke teamet å tilpasse designet for eldre mennesker (større skrifttyper, forbedret kontrast, og så videre) og kunne velge moderne nettadferd (søk, plassering av knapper og lignende). Tross alt, å følge siste designtrender trekker mer oppmerksomhet til produktet i markedet og gjør det også mer intuitivt for unge brukere.

  • De fleste brukere har jobbet med systemet i mer enn ett år

I følge resultatene av undersøkelsen viste det seg at klienter grovt sett kunne deles inn i «junior» (én til tre måneder), «midt» (tre til tolv måneder) og «senior» brukere (mer enn ett år). Disse dataene bidro til å forstå at de fleste brukere (32.4 %) var gamle med mer enn to års erfaring. En litt mindre andel av de ansatte (25.2 %) hadde jobbet med systemet i ett eller to år og 30.2 % hadde vært kjent med det i 3-10 måneder. Dermed var det bedre å forlate hovedlogikken til systemet slik at det ville være lettere for forbrukere å akseptere eventuelle oppdateringer til programmet.

  • De mest brukte kommunikasjonskanalene er e-post, samtaler og meldinger

Analysen av spørreskjemaene viste følgende: For å fungere effektivt trengte brukerne primært e-post, telefonsamtaler og meldinger, adressebok, søk, rapporter og kontrollpanel. Dette var de mest brukte modulene, som burde vært automatisk vist i menyen og utviklet i utgangspunktet for komfortabelt arbeid.

Hvilke problemer rapporterte brukerne?

Studien viste hva brukerne ikke likte i systemet:

  1. Det viste seg at de ikke var helt fornøyd med designet: de fant det upraktisk. Ansatte likte ikke å bytte mellom moduler ofte.
  2. Agenter trengte å se all informasjon om klienten de kommuniserte med. Samtidig var det visse vanskeligheter med å registrere informasjon under samtaler med klienter.
  3. De fleste kundesenterarbeidere syntes det var vanskelig å forstå hva hver funksjon i systemet betydde og hva som måtte gjøres for å fortsette.
  4. Overfloden av informasjon forvirret brukerne.
  5. Noen respondenter ønsket å implementere tilleggsfunksjoner som kommunikasjonskanaler (Viber, WhatsApp og andre sosiale nettverk).
  6. Brukeroppsettprosessen måtte forenkles.

Det ble klart at det var nødvendig å lage et nytt designsystem. Der vil funksjoner bli gruppert, og knapper, ikoner og andre komplekse elementer vil bli vist med hint når du holder musepekeren over.

Hvorfor trengte vi personas?

Teamets neste steg var å lage personas basert på ekte brukerdata. Som et resultat fikk vi to personas som hjalp oss å diskutere flyten med kundene.

Deretter ble det laget et kundereisekart. Det hjalp oss med å definere krav, lage positive og negative scenarier og skissere konseptet. Senere, da designtvister oppsto, vendte teamet tilbake til dette kartet for å koordinere endringer med brukerforespørsler og behov.

Det viktigste var at alle dokumenter hang sammen og at de ble diskutert og avtalt med kunden. Dermed forsto klienten hva teamet gjorde og hvorfor.

Hva skjedde på slutten?

I løpet av arbeidet satte PM opp prosessene på prosjektet på en slik måte at kunden hadde maksimal åpenhet i alle systemer, tilgang til alt materiale, regelmessige akkumulerte fremdriftsrapporter og SWOT-analyse.

Forretningsanalytikeren og UX/UI-designeren gjorde en utmerket jobb, forberedte resultatene av studien og rapporterte om arbeidet som ble utført. Forretningsanalytikeren brukte personas, CJM og User Story Map for å skrive brukerhistorier og definere akseptkriterier. Med fokus på spørreskjemaet beskrev de kravene til utformingen av systemet. Basert på denne dokumentasjonen sjekket de også fullstendigheten og påliteligheten til kravene og etablerte status og prioritet for individuelle deler av prosjektet.

Etter det laget teamet UX/UI-design. Alt gikk ganske raskt fordi all dokumentasjon av studien var strukturert og tilgjengelig. For brukergrensesnittet ble analytiske data brukt. For eksempel, siden de fleste brukere jobber på en skjerm med en oppløsning på 1200 piksler, ble designet tegnet for disse skjermdimensjonene. Siden kundenes skjermer stort sett var ganske gamle, ga teamet mer oppmerksomhet til fargekontrasten.

Som et resultat fikk vi et stort og funksjonelt system. En av interessentene kommenterte arbeidet vårt på følgende måte: «Vi er fornøyde med samarbeidet med Andersen. Designet de presenterte for oss er klart, friskt og moderne, og UX-designet er perfekt. Spesialistene viste seg å være profesjonelle på høyt nivå.»

For øyeblikket kan vi ikke gi statistikk på hvordan UX-forskning hjalp oss med å forbedre systemet, fordi programmet er under utvikling. Det vil være mulig å teste det på brukere etter at programmeringsfasen er fullført.

Men forretningsanalytikeren og UX/UI-designeren kan konkludere med at detaljerte krav og et tydelig design dukket opp etter fire måneder med omfattende research. På den annen side la teamet mange veier åpne for at systemet kunne utvikle seg logisk og konsekvent utover MVP.

Resultatene av UX-forskningen gjorde det mulig for oss å finne ut hovedmønstrene for brukeratferd i systemet og lage nøkkelskjermer og måter å jobbe med applikasjonen på. Basert på dem kunne teamet raskt lage nye moduler for å la produktet utvikle seg logisk uten å komme i konflikt med eksisterende navigasjon. Som et resultat kan utviklere få tilgang til detaljerte beskrivelser av ethvert scenario, og brukere har et system som dekker deres behov og preferanser.

Fra brukerens synspunkt er utvikling, testing og design ganske lovende. Ingen er interessert i vakre, men ubrukelige bilder. Det er viktig at hver funksjon i applikasjonen fungerer og bidrar til å tjene penger. Og for å bli enda mer vellykket, bør du vurdere brukernes mening, basert på resultatene fra foreløpige UX-testing. Tross alt, å investere i UX-design på stadiet av å lage et prosjektkonsept reduserer livssyklusen til programvareutvikling med 33-50%. Dette er bare noen av fordelene med vellykket UX-forskning.