Forbedring af anvendeligheden ved at vælge flere fra en lang liste

Valg af flere elementer fra en liste var aldrig en behagelig opgave. Der er nogle innovative løsninger, der fungerer i orden på store skærme, men som regel er de et mareridt at bruge på mobile enheder. Her er historien om, hvordan jeg fandt en løsning til at forbedre tagvalget til vores udbydere.

De eksisterende UI-løsninger

Når du søger efter UI-løsninger til multivalg, finder du normalt lignende løsninger: give dem en dropdown, som de både kan rulle gennem eller søge i, og vise emnerne som piller i inputfeltet. Sådan her.

Rulning og søgning gennem en lang liste

Eller du får listerne med afkrydsningsfelter skjult i en rulleliste. Eller to lister, og du flytter dit valg fra venstre til højre. Som disse.

Hybrid dobbeltliste med filteropløsning fra doejo

Vores system havde allerede en komponent fra Select2, der svarede til det første eksempel. Vores udviklere begyndte at bruge det i flere områder, såvel som oprettelsesprocessen, der består af flere trin, lige på det første trin, vi beder vores udbydere om at vælge 4-6 relevante tags til deres lister fra en meget lang liste.

Problemet med søgbart multi-select

Listen, som vi viser til vores udbydere, er meget lang. Den indeholder omkring 300 genstande, og de fleste af dem er de ikke bekendt med. Fra skærmoptagelser så jeg, at (1) brugere rullede kun et par gange og derefter gav op med at rulle gennem hele listen, og derefter (2) begyndte de at søge efter, hvad de havde i tankerne.

Multi-select pilleboks er en god løsning, når brugeren er fortrolig med indholdet på listen, og de ved, hvad de leder efter. De kan let finde ved at søge eller bare rulle til den relevante del af listen.

I tilfælde af, at indholdet af listen ikke er kendt, er der flere problemer. Det er ekstremt trættende at rulle gennem en liste så længe og læse hvert emne. Ingen gør det. Især når det ikke engang er sorteret alfabetisk.

Derefter vender deres søgning ikke tilbage med nogen resultater 50% af tiden. Enten fordi de bruger en anden sætning eller ordrækkefølge end strengene på listen, eller indholdet bare ikke er der. Efter et par forsøg og fejl giver de op og går videre uden at faktisk vælge de mest relevante tags.

Fra vores team om indholdskvalitet hørte jeg, at den samlede kvalitet af de valgte tags var virkelig lav, meget generisk og ikke nok, det krævede en masse ekstra undersøgelser og tidsinvesteringer for at hjælpe udbydere og forbedre indholdets kvalitet og placering af deres fortegnelse .

Første idé til forbedring

Jeg overvejede seriøst ”Hybrid Dual List with Filter” -løsning, da indstillingerne er synlige (lettere at læse), og markeringen er tydelig på listen til højre. Men hvordan er det mobilvenligt? Vi udvikler os med en første mobil tilgang til vores udbydere, og denne løsning passede ikke.

Hvad ellers? Lad os udsætte alle indstillingerne for udbyderne i en form som en tag sky, som Foursquare gør med "smag".

Vælg din smag med Foursquare

Med denne forbedring håbede vi, at det ville være lettere at finde de relevante tags og vælge dem. Vi var klar over, at taglisten er for lang og ustruktureret, men det var et godt nok lille skridt at gøre og begynde at lære af.

Førtilstanden - se størrelsen på rullebjælkenEftertilstand - alle udsatte genstande

Dette var udelukkende en UI-ændring, ingen data eller sortering i backend blev rørt. Som du kan se på eksemplet, ordnes “kategorierne” ikke alfabetisk, hvilket berørte mig lidt. Vil det være godt nok?

Før jeg satte det foran vores kunder, gav jeg begge versioner til kolleger med 6 varer at vælge (som jeg tog fra et ægte eksempel fra en skærmoptagelse) og målte den tid det tog dem at vælge de ting, jeg gav dem.

Med vilje gav jeg dem listen, da udbyderen forsøgte at søge efter dem, ikke som de er på listen.

I den gamle version 3 opgav kollega af de 5 opgaven, 2 af dem afsluttede den på over et minut. I den nye version lykkedes det alle at udføre opgaven inden for et minut med en kombination af Ctrl + F-søgning og -scanning. Det var et godt nok resultat for mig.

Indlæring fra denne test

Jeg udsatte halvdelen af ​​vores udbydere for tag skybaseret funktion i cirka en måned (på grund af lav trafik), men desværre var der ingen reelle forbedringer i (1) at vælge mere relevante tags hverken i (2) hastigheden for at finde disse tags.

Jeg var nødt til at indse, at kun det kun at udsætte mulighederne ikke var nok, især når de ikke engang er sorteret. Det kræver meget mere fokus og hjernebåndbredde, da øjet skal springe frem og tilbage, op og ned mellem tags i stedet for bare at følge et mønster.

Iteration: næste trin er lidt større

Da min tro på at afsløre optionerne ikke ændrede mig, var jeg nødt til at beskæftige mig med at bringe orden og mønster ind i historien. Dette krævede også nogle ændringer i infrastrukturen. Skulle det være det værd?

For at gøre det lidt mindre brugte jeg et eksisterende, men ubrugt informationsarkitekturdesign, som skabte grupper af tags baseret på lighed og relevans. Dette reddede os et par dage med at tænke, og jeg kunne straks springe ind i iterationen med min udvikler.

Vi oprettede en fornuftig størrelse af grupper med meget dristige titler (så brugere kan scanne dem først hurtigt og derefter kigge ind i den aktuelle liste, hvis de finder det relevant) og meget pænt organiserede lister i kolonner i samme størrelse, som responsivt ændrede bredden i procent men holdt fra op-til-ned læseretning.

Først byggede jeg søjlerne med display: flex; der bestilte varerne fra venstre til højre i stedet for fra op til ned. Den magiske løsning var kolonnetælling: 2; At løse dette var en sejr alene! (Klik for JSFiddle for at illustrere.)

De to lister var dog endnu længere end med tags, så vi besluttede at opdele disse felter i dets egen side i stedet for at skubbe det ind i en form med 4-5 nye elementer. Dette gav os chancen for at overvåge den nye funktion og dens brug mere omhyggeligt.

Analyse af resultatet

Efter at have udsat halvdelen af ​​vores udbydere for den grupperede og eksponerede liste over tags vs multi-select pilleboksen, så jeg skærmoptagelser for at se, hvor godt accepteret denne løsning var.

Min opfattelse var positiv fra de sessioner, jeg så, folk rullede gennem hele listen, men kun 1,93% af dem sad fast på denne side. Jeg ville gerne have nogle hårde data om antallet af valgte tags (jeg ønskede at se klar forbedring) og hvor lang tid det tog at gennemføre trinnene (jeg ville se tidsfald). Desværre er det eksperimentværktøj, vi bruger, udviklet til at måle ændringer i kundekonverteringstragt og slet ikke optimeret til at måle ændringer i anvendeligheden af ​​form i vores admin-område.

Så jeg var nødt til at samle og analysere data manuelt.

Først identificerede jeg de lister, der blev oprettet i kontrolgruppen og behandlingen.

For kontrolgruppen (V0) stillede jeg spørgsmålstegn ved de sekunder, der blev taget for hver liste for at fortsætte fra trin 1 til trin 2 (trin 1 indeholdt multivælgerpillekasser), og mængden af ​​markerede tags

Behandlingsgruppen (V1) havde tag-plukningen på et nyt trin, i trin 2, så for dem måtte jeg spørge, hvor mange sekunder det tog dem at komme fra trin 1 til trin 3, samt hvor mange mærker der blev valgt.

Jeg lagde dem i et Google Sheet for at starte analysen og lavede hurtigt Gennemsnit på de numre, jeg fik. Og resultatet var overraskende:

En prøve af datasættet jeg arbejdede med

10000 sekunder ekstra i gennemsnit ??? Næsten 3 timer længere i behandlingsgruppen? Det kan ikke stemme. Jeg er ikke en forretningsanalytiker, men der kom noget tilbage fra mine universitetsstudier om statistik og fjernelse af outliers fra datasæt, så du ikke ser virkningen af ​​- i dette tilfælde - udbydere, der forlod processen i en hel dag og derefter vendte tilbage .

Så hvad er den bedste måde at fjerne outliers, som Google Sheets let kan håndtere? Efter en vis undersøgelse besluttede jeg at bruge TRIMMEAN-funktionen, der beregner gennemsnittet af et datasæt, eksklusive en del af data fra datasættets høje og lave ender. I beregningen udelukkede jeg de øverste og nederste 20% for at få et mere reelt billede af brugen.

Og resultatet var overraskende!

Færdiggørelsen af ​​de 2 trin kombineret i behandlingsgruppen var 33% hurtigere end det ene trin i kontrolgruppen, og der blev yderligere 4 tags valgt i den nye version af listen. Hvilken stor forbedring!

Konklusionen

Design er kontekstuelt. Det kan være en simpel opgave at vælge dit hjemland fra en liste med 195 genstande, selvom du skal rulle et stykke tid.

Når det kommer til ukendte genstande, er det bedre at visuelt udsætte elementerne i stedet for at skjule dem. Det er endnu bedre at gøre det på en logisk organiseret måde: oprette grupper med meningsfulde titler, og lad brugerne zoome ind på de grupper, de er interesseret i.

Med mindre kognitiv belastning tager opgaven mindre tid at gennemføre og efterlader brugeren mere energi til at gennemgå hele processen.