Hvordan UX Research forbedrer produktkvaliteten og reducerer udviklingstiden

Sponsoreret

Fordele ved UX-forskning (baseret på et eksisterende projekt)

I praksis hilser kunderne ikke UX-forskning velkommen: det tager meget tid, og udvikling udføres ikke i denne periode. Der er dog situationer, hvor man ikke kan undvære UX. Det er præcis, hvad der skete med et projekt, som Andersen-teamet arbejdede på.

En kunde bad os om at redesigne et callcentersystem og optimere denne løsning til brugernes behov. Virksomheden ønskede at få en prototype med det samme, men vi insisterede på at gennemføre en fuldgyldig undersøgelse, der viser fordelene ved denne tilgang. Vi vil fortælle dig, hvad der kom ud af det, og hvordan vi forbedrede projektet takket være det velkoordinerede samarbejde mellem en forretningsanalytiker, en projektleder og en UX/UI-designer.

Hvordan det hele startede: et komplekst system med en enorm manual, ligesom i 90'erne

Så kunden henvendte sig til os med ideen om en komplet opdatering af deres callcentersystem. Programmet var meget kraftfuldt, men solgte ikke godt, fordi det så forældet ud og tog lang tid at mestre. Kunden ønskede at gøre det mere attraktivt på markedet og optimere dets funktionalitet.

Andersen-teamet gennemgik den daværende version af systemet og så flere store problemer:

Et ekstremt komplekst system.

Udviklingen af ​​systemet startede for mere end ti år siden. I alle disse år er det fortsat, og der er dukket adskillige opdateringer op, da systemet tog hensyn til helt andre kunders behov og gav alt for brede tilpasningsmuligheder.

Uklar funktionalitet.

Det andet problem havde rødder i det første. Overfloden af ​​funktionalitet førte til, at navigationen og systemets overordnede udseende var forældede og fuldstændig ulogiske og uforståelige, hvilket gjorde det svært at arbejde med programmet.

En kæmpe ubrugelig manual.

I teorien var det muligt at håndtere systemet ved hjælp af manualen, men det tog omkring tre hundrede sider. Derudover blev det skrevet som en beskrivelse af funktionaliteten, ikke brugerscenarier, så det var ikke nemt at forstå, hvad man skulle gøre i en bestemt situation. Som vi fandt ud af senere, brugte ingen manualen.

Et system uden kundeorientering.

På trods af alle ovenstående problemer skal systemet være brugercentreret. Når alt kommer til alt, indebærer arbejdet i et callcenter et øjeblikkeligt svar, hurtig interaktion med kunder og udførelse af forskellige operationer.

For at opsummere fik vi et komplekst uforståeligt system med overdreven dokumentation, og det manglede kundeorientering. UX-forskning var et must i det tilfælde.

Kilde: andersenlab.com

Hvordan UX-forskning vi forberedte og udførte

For at vise kunden, hvilke problemer systemet havde, er Business Analytikeren og den UX/UI designer studeret manualen og den daværende version af systemet og analyseret lignende systemer og konkurrenter. Det første bekendtskab med programmet afslørede problemer med navigation og instruktioner til dets brug. Teamet indså, at det ville være nødvendigt at kommunikere med forskellige interessenter (virksomhedsejere, salgsafdeling) og lavede en detaljeret plan for det videre arbejde med specifikke deadlines og resultater. Hver anden uge ringede vi til kundens ledere, og PM leverede rapporter og målinger og diskuterede potentielle risici og forbedringer. Som et resultat, vidste kunden præcis, hvad de ville modtage, og hvorfor de havde brug for det.

Det tog omkring to måneder at studere domænet, instruktioner til systemet, artikler om callcentre og software til dem. Det var nødvendigt at korrelere det, der blev fortalt i manualen, med det, der faktisk var i systemet. Som et resultat af omhyggeligt arbejde var forretningsanalytikeren i stand til at oprette et mindmap, som præsenterede systemets struktur og den vigtigste funktionalitet, som hver af hovedenhederne udførte.

Under UX-forskningen stødte vi på visse forhindringer. Lad os tale om dem i detaljer.

Brugertest er ikke tilladt. Hvordan blev dette problem løst?

Teamet havde brug for svar på følgende spørgsmål: "Hvem er vores brugere?" og "Hvordan bruger de systemet?" Brugerroller var dårligt beskrevet i manualen, og derfor skulle vi afklare, om vi forstod dem korrekt.

Desværre var Andersen-specialister ikke i stand til at udføre brugertest, fordi callcentret arbejdede med banker, forsikringsselskaber og andre organisationer. I henhold til sikkerhedsreglerne kan tredjepartsdata ikke overføres til nogen. Derudover kunne vi på grund af lukkede grænser ikke besøge kunderne personligt.

Men disse forhindringer stoppede os ikke, da vores team havde en plan. Det var nødvendigt at forstå, hvad callcenterbrugere forventede, hvilke tilbud der var på markedet, og hvordan virksomheder tiltrak nye kunder. Under det første opkald med interessenter blev Business Analyst, PM og designer bedt om at organisere online kommunikation med slutbrugerne af produktet. Kunden sagde ja til det, og Andersen-medarbejdere kunne lave en generel undersøgelse og arrangere samtaler.

Brugerinterviews: Engelsk er ikke respondenternes modersmål

Det var den mest interessante del af jobbet. Forretningsanalytikeren og UX/UI-designeren lavede et Google-dokument-spørgeskema for at udforske nogle af punkterne. Som en del af undersøgelsen blev to tilgange kombineret. Takket være en kvantitativ tilgang var det muligt at indsamle statistiske data om brugen af ​​systemet efter brugerroller. En kvalitativ metode hjalp os med at dykke ned i detaljerne og få nøgleindsigter frem.

Først var det nødvendigt at tjekke brugerrollerne. Designeren sendte med kundens samtykke et spørgeskema til 21 callcenterkundevirksomheder: banker, forsikringsorganisationer, virksomheder osv. Vi fandt ud af, hvordan 139 medarbejdere fra forskellige strukturer arbejdede med programmet, og hvad deres ansvar var. UX-specialisten lærte, hvilke moduler af systemklienterne brugte oftest. Et af punkterne i undersøgelsen afklarede, om respondenterne ønskede at tale med Andersen-eksperter. I så fald efterlod de deres e-mail i formularen, og vi planlagde et interview med dem.

Interviewene var begrænset til 30 minutter pr. respondent. Der blev udarbejdet en liste med spørgsmål for hver brugerrolle. Deltagernes svar blev registreret, hvilket var nyttigt til transskription. Interviewet blev foretaget på engelsk, hvilket var lidt svært, fordi dette sprog ikke var hjemmehørende for vores respondenter. Ikke desto mindre lykkedes det for Andersen-teamet at indsamle gode indsigter, som derefter blev præsenteret for kunden i form af en rapport.

Kilde: andersenlab.com

UX-forskningsværktøjer og databehandling

Mange artikler fortæller, hvordan man laver UX-forskning. Men de mangler information om, hvad de skal gøre med den store mængde data, der er ophobet siden interviewstadiet. Så holdet brugte et affinitetsdiagram til at fortolke resultaterne.

Til dette projekt blev affinitetsdiagrammet brugt som en metode til at hjælpe med at strukturere information. For at gøre dette identificerede vi hovedemnerne i interviewet. Eksempelvis udpegede vi kategorien ”systemets mangler”, hvor vi registrerede respondenternes tanker om mangler. Desuden overvejede vi kommentarer uanset roller, erfaring osv.

Meninger fra almindelige brugere ("der er for meget funktionalitet i systemet, som gør det ubehageligt") og administratorens bemærkning om, at de ikke kan tilpasse systemet til behovene i deres bankvirksomhed – alle disse spørgsmål blev opført i kategorien systemfejl i affinitetsdiagrammet. Således hjalp samtaler med respondenter os til at opdage hovedproblemerne. På baggrund af disse resultater skabte vi personas og forstod, hvilke brugerproblemer vi skulle løse i første omgang.

Det andet vigtige trin i at studere systemet, som forretningsanalytikeren arbejdede på, var oprettelsen af ​​BPMN-diagrammer over hovedprocesserne, klassediagrammer, der illustrerede forholdet mellem enheder, og statusdiagrammer, der viser udviklingen af ​​individuelle elementer i systemet. Således beskrev vi alle forretningsprocesser i et enkelt standardiseret sprog. Ved at se på diagrammet kunne ledere, udviklere, konsulenter og andre specialister involveret i processen forstå essensen af ​​systemet uden at læse omfangsrige instruktioner.

Hvordan forskning var med til at forme det videre arbejde

I løbet af researchen modtog forretningsanalytikeren og UX/UI-designeren nok information, baseret på hvilke de kom med følgende konklusioner:

• Hovedkunder er banker og forsikringsselskaber

Undersøgelsen hjalp os til at fastslå, at systemet hovedsageligt blev brugt af ansatte i banker (13.7%) og forsikringsselskaber (12.9%), og andre institutioner brugte det i mindre omfang. Derfor besluttede Andersen-teamet, da de lavede designet, primært at fokusere på disse kunders behov.

• In-house medarbejdere er hovedbrugerne

Da agenter (51.1%) spiller hovedrollen i systemet, indså teamet, at de skulle tage hensyn til dem, når de udviklede produktet. Andre deltagere (administratorer – 10.8 %, backoffice-brugere – 10.8 %, brugere – 15.1 % og så videre) havde også brug for opmærksomhed. Du skal dog fokusere på avancerede brugere, der er bekendt med den bedste UX-praksis (f.eks. Google, Apple osv.).

• Systemet bruges primært af unge

På baggrund af undersøgelsen blev det klart, at programmets brugerpublikum er medarbejdere i alderen 18-30 år (67.4%). Derfor behøvede teamet ikke at tilpasse designet til ældre mennesker (større skrifttyper, forbedret kontrast og så videre) og kunne vælge moderne webadfærd (søgning, knapplacering og lignende). Efter alt efter seneste designtrends gør mere opmærksom på produktet på markedet og gør det også mere intuitivt for unge brugere.

• De fleste brugere har arbejdet med systemet i mere end et år

Ifølge resultaterne af undersøgelsen viste det sig, at klienter groft kunne opdeles i "junior" (en til tre måneder), "midt" (tre til tolv måneder) og "senior" brugere (mere end et år). Disse data hjalp med at forstå, at de fleste brugere (32.4%) var oldtimere med mere end to års erfaring. En lidt mindre procentdel af medarbejderne (25.2 %) havde arbejdet med systemet i et eller to år og 30.2 % havde været fortrolige med det i 3-10 måneder. Det var således bedre at forlade systemets hovedlogik, så det ville være lettere for forbrugerne at acceptere eventuelle opdateringer til programmet.

• De mest brugte kommunikationskanaler er e-mail, opkald og beskeder

Analysen af ​​spørgeskemaerne viste følgende: For at fungere effektivt havde brugerne primært brug for e-mail, telefonopkald og beskeder, en adressebog, søgning, rapporter og et kontrolpanel. Det var de mest brugte moduler, som skulle have været automatisk vist i menuen og udviklet i første omgang for komfortabelt arbejde.

Hvilke problemer rapporterede brugerne?

Undersøgelsen viste, hvad brugerne ikke kunne lide i systemet:

1. Det viste sig, at de ikke var helt tilfredse med designet: de fandt det ubelejligt. Medarbejderne kunne ikke lide ofte at skifte mellem moduler.
2. Agenter havde brug for at se alle oplysninger om den klient, som de kommunikerede med. Samtidig var der visse vanskeligheder med at registrere information under opkald med klienter.
3. De fleste callcentermedarbejdere havde svært ved at forstå, hvad hver funktion i systemet betød, og hvad der skulle gøres for at fortsætte.
4. Overfloden af ​​information forvirrede brugerne.
5. Nogle respondenter ønskede at implementere yderligere funktioner såsom kommunikationskanaler (Viber, WhatsApp og andre sociale netværk).
6. Brugeropsætningsprocessen skulle forenkles.

Det blev klart, at det var nødvendigt at skabe et nyt designsystem. Der ville funktioner blive grupperet, og knapper, ikoner og andre komplekse elementer ville blive vist med hints, når du svæver over.

Hvorfor havde vi brug for personas?

Teamets næste skridt var at skabe personas baseret på rigtige brugerdata. Som et resultat fik vi to personas, som hjalp os med at diskutere flowet med kunderne.

Derefter blev der lavet et kunderejsekort. Det hjalp os med at definere krav, lave positive og negative scenarier og skitsere konceptet. Senere, da der opstod designtvister, vendte teamet tilbage til dette kort for at koordinere ændringer med brugernes ønsker og behov.

Det vigtigste var, at alle dokumenter hang sammen, og at de blev drøftet og aftalt med kunden. Dermed forstod klienten, hvad teamet lavede og hvorfor.

Hvad skete der til sidst?

I løbet af arbejdet satte PM processerne på projektet op på en sådan måde, at kunden havde maksimal gennemsigtighed i alle systemer, adgang til alt materiale, regelmæssige akkumulerede fremskridtsrapporter og SWOT-analyser.

Forretningsanalytikeren og UX/UI-designeren gjorde et fremragende stykke arbejde, forberedte resultaterne af undersøgelsen og rapporterede om det udførte arbejde. Forretningsanalytikeren brugte personas, CJM og User Story Map til at skrive brugerhistorier og definere acceptkriterier. Med fokus på spørgeskemaet beskrev de kravene til systemets design. Baseret på denne dokumentation kontrollerede de også fuldstændigheden og pålideligheden af ​​kravene og fastlagde status og prioritet for individuelle dele af projektet.

Derefter skabte teamet UX/UI-design. Alt gik ret hurtigt, fordi al dokumentation for undersøgelsen var struktureret og tilgængelig. Til brugergrænsefladen blev der brugt analytiske data. For eksempel, da de fleste brugere arbejder på en skærm med en opløsning på 1200 pixels, blev designet tegnet til disse skærmdimensioner. Også, da kundernes skærme for det meste var ret gamle, lagde teamet mere opmærksomhed på farvekontrasten.

Som et resultat fik vi et stort og funktionelt system. En af interessenterne kommenterede vores arbejde på følgende måde: ”Vi er tilfredse med samarbejdet med Andersen. Designet, de præsenterede for os, er klart, friskt og moderne, og UX-designet er perfekt. Specialisterne viste sig at være professionelle på højt niveau.”

På nuværende tidspunkt kan vi ikke give statistik over, hvordan UX-forskning hjalp os med at forbedre systemet, fordi programmet er under udvikling. Det vil være muligt at teste det på brugere efter afslutningen af ​​programmeringsfasen.

Men Business Analyst og UX/UI-designeren kan konkludere, at detaljerede krav og et klart design dukkede op efter fire måneders omfattende research. På den anden side lod holdet mange veje åbne for systemet til at udvikle sig logisk og konsekvent ud over MVP.

Resultaterne af UX-forskningen gjorde det muligt for os at udarbejde de vigtigste mønstre for brugeradfærd i systemet og skabe nøgleskærme og måder at arbejde med applikationen på. Baseret på dem var teamet i stand til hurtigt at skabe nye moduler for at lade produktet udvikle sig logisk uden at komme i konflikt med eksisterende navigation. Som et resultat kan udviklere få adgang til detaljerede beskrivelser af ethvert scenarie, og brugerne har et system, der adresserer deres behov og præferencer.

Fra brugerens synspunkt er udvikling, test og design ret lovende. Ingen er interesseret i smukke, men ubrugelige billeder. Det er vigtigt, at hver funktion i applikationen virker og hjælper med at skabe overskud. Og for at få endnu mere succes, bør du overveje brugernes mening baseret på resultaterne af foreløbige UX test. Når alt kommer til alt, reducerer investering i UX-design på stadiet med at skabe et projektkoncept softwareudviklingens livscyklus med 33-50%. Dette er blot nogle få af fordelene ved vellykket UX-forskning.