Et simpelt UI-hack til forbedring af Onboarding UX [OCD]

UI-modeller og skitser antager, at brugerdata allerede er til stede. For eksempel antager mockup'en nedenfor, at brugeren har kontakter at chatte med, underretninger og endda chattråde.

Enkel messenger ui bygget ved hjælp af denne gratis skitse-ressource

Men dette er aldrig tilfældet, når en bruger tilmelder sig. I begyndelsen er der ingen data, så en tom kontaktskolonne og et tomt chatvindue.

Skinnende UI-design gør det nemt at forbruge information og fokuserer ikke på, hvordan man opretter disse oplysninger.

Jeg lærte dette på den hårde måde, da jeg gennemvædet så meget af Dribbble jeg kunne til at designe et instrumentbræt til en b2b-applikation. Det så godt ud på Sketch, men vores kunder kunne ikke finde vej gennem.

Dårlig UX øger omkostninger til om bord og support, der direkte påvirker indtægterne. Det føles også dårligt at se en bruger, der kæmper for at forbruge dit pixel perfekte design. Minder dig om, at du mislykkedes.

Eksisterende løsninger

En løsning var at have en forudgående on-boarding ved hjælp af dias som interface. Dette ser ud til at være standarden for mobile apps.

Slacks slide-baserede UX-boardingbord

Problemet med dias-tilgang er manglen på kontekst. Du kan kun formidle så meget på diaserne (hvor meget brugeren beholder er et andet spørgsmål).

Det er dejligt at give et overblik over produktet, men ikke meget nyttigt til at forklare, hvordan produktet fungerer. Det var irrelevant for min brugssag, da produktets kompleksitet ikke kunne koges ned til et par lysbilleder.

Der var også en værktøjstip-baseret løsning, der leder brugeren gennem specifikke trin. Denne indstilling er mere populær med webapps. Der er mange gode javascript-biblioteker, der hjælper dig med at opbygge disse strømme.

Værktøjstip baseret på boarding-demo til introjs.com/

Hvad angår en værktøjstipbaseret løsning, fandt jeg dem irriterende og næsten altid klikkede på "spring tutorial". Selvom store virksomheder som Canva bruger værktøjstip baseret på boarding. Et produkt kaldet AppCues giver dig mulighed for at designe disse værktøjstip uden kode, pæne.

Der findes også en beacon-stiltilgang, hvor ofte misforståede funktioner er mærket med glødende beacons, som giver relevant information, når (hvis) det er nødvendigt.

Dette er den mest beskedne måde. I modsætning til værktøjstip, der skyver en 17-trins tutorial ned i halsen og forsvinder, når du faktisk har brug for det, giver denne hotspot-baserede tilgang oplysninger, når du er klar.

Det er værd at nævne, at Slack bruger alle de 3 former. Ikke underligt, at deres brugere holder fast. Hvilket også på en eller anden måde antyder, at fastholdelse er direkte proportional med lethed ved ind-boarding.

OCD alias Onboarding centralt design

Jeg kan godt lide at navngive ting. Navne hjælper med at materialisere ideer i sindet. Så lad os kalde dette Onboarding centralt design.

Jeg ønskede en løsning, der:

  • Var relevant for konteksten
  • Var ikke irriterende (ingen kan lide at tage 17 skridt for at lære, hvordan en funktion fungerer)
  • Er diskret (ligesom fyret)
  • Er let at forbruge (værktøjstip er ikke nemme at forbruge)

Resultat

Jeg begyndte ganske enkelt at designe stater. Chatdesignet, du så, mens du begyndte at læse denne artikel, kan designes med tre tilstande.

Tilstand 1: Ingen kontakter er til stede

Tilstand 2: Kontakter til stede, men ingen chats

Tilstand 3: Både chats og kontakter er til stede

Målet for hver stat er at videreføre brugeren til den næste tilstand. Når brugeren er gået videre til tilstand 3, er hun med succes om bord. I betragtning af chatmodellen er målet for hver stat som følger:

Mål for stat 1: Første bruger til at tilføje en kontakt

Mockup'en nedenfor har kun et opkald til handling, den blå plus-knap, der giver brugeren mulighed for at tilføje en ny kontakt. Grafikken og teksten er begge vigtige for, at brugeren skal tage denne handling.

Tilstand 1 - Primer brugeren til at tilføje kontakter (illustration af undraw.co)

Når en kontakt er tilføjet, kan vi starte det andet mål.

Mål for tilstand 2: Første bruger til at starte en chat

Modellen nedenfor viser har en grafisk primer til at starte en chat. Det skitserer eksplicit de tilgængelige funktioner. Igen er der kun en ting, du kan gøre nu, dvs. sende en besked. Du kan også ringe til dette UI, men begge disse handlinger tjener det samme formål. De tager din bruger til trin 3.

Tilstand 2 - Kontakt tilføjet, først for at starte en chat

Mål for tilstand 3: Ingen, brugeren er om bord - alle signaler skal forsvinde

Og til sidst, når din bruger har gentaget processen et par gange, begynder hendes UI at se ud som vi oprindeligt havde til hensigt.

Tilstand 3 - Brugeren er medbragt om bord

Fordelene ved denne tilgang

  • Sammenlignet med dias-tilgang i trin 1, præsenterer Onboarding Centric Design (OCD) indholdet i bidder. Oplysningerne er tilgængelige på tidspunktet for beslutningsprocessen.
  • Denne tilgang kan bruges på både mobile og stationære enheder. Denne brugergrænseflade er enkel, men i tilfælde af en kompleks brugergrænseflade kan du bruge OCD med hotspots til at hæve CTA'er.
  • Denne tilgang forbedrer din UX i første omgang ved at tvinge dig til at tænke i form af brugerens rejse.
  • Hvis du tilfældigvis skriver dine frontender ved hjælp af React, passer denne tilgang pænt med dens komponentarkitektur.

Så som en tommelfingerregel:

Design mockups til stater.
Hver stat har et mål - fremskridt til næste stat.
Den sidste tilstand er, når din bruger er indbygget.

Tak for at have læst :)

Hej, hvis du kunne lide denne artikel og vil holde dig opdateret, følg mig på: Medium, Github eller Twitter

Jeg driver et slapt samfund (som har 18 medlemmer fra den 6. oktober 2018), hvor du kan hjælpe andre eller modtage hjælp til frontend, backend og udvikling generelt. Du kan deltage her.