Amazon Checkout Redesign-øvelse - Del I: Navigation

Bemærk venligst: dette er en øvelse. Dets formål er ikke at skabe forretningsløsninger, men at øve sig på at skabe dem i et simuleret miljø. Gætningens gætte bruges til at danne forretningsmæssige mål og målinger.

Du vil finde links til prototyper og andre dele af øvelsen (når de først er offentliggjort) i slutningen af ​​denne artikel.

Målet

Amazon arbejder godt med at behandle millioner af ordrer om dagen, men der er altid noget plads til forbedring: højere kundetilfredshed, vellykket opsalg, konverteringer til betalte abonnementer osv.

I denne øvelse vil vi forsøge at opdele kasseprocessen i mindre oplevelser og se, om vi kan forbedre dem en efter en, startende med navigation.

Den givne

Checkout hos Amazon er en flertrinsproces. Dette er, hvad en uregistreret bruger gennemgår for at afgive en ordre:

Uregistreret bruger checkout flow på Amazon.com

På trods af at vi ikke kender nogen af ​​de faktiske resultatindikatorer for denne arbejdsgang, kan vi se det mest indlysende problem her - UI ser ud til at mangle konsistens:

  • De fleste skærme har unik layout og styling, så du bliver nødt til at studere hver skærm, før du kan begynde at interagere med den med tillid.
  • Skærmbilleder har anden kontekst: visning af indkøbsvogn (1) er en del af det generelle brugergrænseflade, men resten af ​​skærmene behandles med en særlig overskrift, der repræsenterer trin, der skal udføres.
  • Navigation gennem kassen er en envejsvej: Du kan ikke gå tilbage til tidligere trin det meste af tiden. Header angiver dine fremskridt, men det gør ikke jobbet godt: Du sidder fast i Forsendelse og betaling for tre forskellige skærme (3-5), så springes gaveindstillinger bare i de fleste tilfælde.

Checkout-processen er kompleks (af en grund) med mange flere UX-problemer, og jeg anbefaler, at du gennemgår det selv og ser, at andre gør det. At opleve løsningen er tusind billeder værd.

For tiden er vores opgave at forbedre navigationen, og det er tid til noget blyantarbejde.

Skitsering

Doodling er et godt værktøj til UI-designudforskning. På samme måde som brainstorming handler du med kvalitet og detaljer for frihed og hastighed ved at generere løsninger. Og hvis du spørger mig, er frihed sammen med hastighed det, der betyder mest for den første iteration.

Produkter af doodling: grimt, kaotisk og indsigtsfuldt.

Et par timer senere koger utal af ideer ned til en af ​​de to tilgange i navigationen:

Den første er kassecentrisk. Det betyder, at vi dybest set starter med, hvad der i øjeblikket er den sidste skærm i kassen: Resume. For at redigere oplysningerne skal en bruger åbne de respektive visninger (som forsendelse og betaling).

Den anden er trinbaseret. Det ligner meget det nuværende design, Amazon har, men med nogle undtagelser: indkøbskurv er en del af den samlede checkout-arbejdsgang, og vi vil også give brugerne mulighed for frit at navigere rundt i processens trin.

Nu hvor vi har skitser til to udgangspunkt, kan vi gå til det næste niveau af designudforskning. Nej, ikke mockups, selvfølgelig.

Prototyping

I stedet for at tegne mockups i Sketch eller Figma bare for at tilføje lidt mere detaljer til vores håndtegnede doodles, bruger vi vue.js til at begynde at oprette handlingsmæssige designs med det samme.

Prototyperne har Prototype Manager indbygget til hurtigt at skifte mellem versioner, vi implementerer, og iterationer, vi gennemgår:

Prototype Manager

Checkout-centreret design

Ideen her er at gøre den endelige Checkout-side til et udgangspunkt og gøre alle andre (redigerbare) visninger til dens børn:

At vise indkøbskurv som en del af den komplekse skærm er ikke en god ide for dem, der bare vil se, hvad der er derinde, eller måske fjerne nogle genstande. Så det giver mening at indstille redigerbar indkøbsvogn-skærm som et indgangspunkt for processen, selvom det ikke er hovedvisningen.

Nogle kodningstimer senere har vi en prototype, der simulerer trinene for første gangs brugere at gennemgå med denne navigationsarkitektur:

Første test og observationer afslører nogle gode ting ved denne tilgang:

  • Hovedstrømmen for en førstegangsbruger er den samme som for en registreret: Indkøbskurv - Kasse (- eventuelt Redigere forsendelses- / betalingsinfo). Dette mønster er enkelt sammenlignet med trinbaseret navigation, der har en tendens til lydløst at springe over nogle trin under særlige omstændigheder.
  • På ethvert givet tidspunkt er det let at fortælle, hvor nøjagtigt du er i processen, hvordan du kom dertil, og hvor knapperne tager dig. Denne komfort opnås ved at fjerne alle mystiske Continue- og Proceed-knapper, som i sig selv er et resultat af at bevæge sig væk fra den lineære trin-for-trin-proces. Her skal brugerne bevidst vælge at gå til enhver skærm ved at trykke på den tilsvarende knap.

Dårlige ting ved denne tilgang afslører sig også hurtigt:

  • Du skal selv vælge at indtaste de manglende oplysninger. I modsætning til i det trinbaserede design, der viser dig alle nødvendige formularer en efter en, før det giver dig mulighed for at fortsætte, her skal du trykke på Rediger for alle manglende stykker.
  • Den travleste skærm vises lige fra starten. Der er ikke noget at komme væk fra oversigtsoversigten, der skal vise alle oplysninger for at få dig til at føle dig tryg ved at klikke på Foretag ordre. Men at have det som processens hjem kan overvælde brugeren.

Her kan du selv teste prototypen: Prototype A.1. Gider ikke indtaste nogle data i Forsendelse og betaling - bare at trykke på “Gem” vil gøre det i øjeblikket.

Trinbaseret design

Denne arkitektur ligner meget at navigere med faner, men i stedet for faner har vi trin, og de fleste af dem afslører formularer, du skal udfylde for at fortsætte. Dette mønster skal se velkendt ud for alle, der var heldige nok til at installere software pakket med installationsguiden.

Under de første iterationer af prototypeprocessen bliver det tydeligt, at indholdsfortegnelsen også kan fungere som navigations- og informationssammendrag. Så hvorfor ikke prøve det:

Gode ​​ting vi finder her:

  • Processen er tydeligvis progressiv: en skærm ad gangen, efterfulgt af en anden. Du ser kun én handlingsknap ad gangen, så det er usandsynligt, at du nogensinde vil spekulere på, hvad du skal gøre næste.
  • Vi var i stand til at gøre indholdsfortegnelsen til en endnu mere nyttig del af brugergrænsefladen, der nu også tjener til navigation og ordreoversigt. At vise brugerne resultaterne af deres indsats forbedrer normalt den overordnede forståelse af processen.

Dårlige ting ved denne tilgang:

  • Strømmen varierer for forskellige anvendelsessager. Førstegangsbrugere gennemgår alle trin, mens de registrerede brugere føres til det sidste trin. Og mange mennesker vil sandsynligvis opleve begge tilfælde.
  • Registrerede brugere starter med en ret optaget skærm, ligesom i vores første tilgang. Selvom det i dette tilfælde er næsten uundgåeligt, da der ikke er nogen oplysninger at udfylde, hvilket betyder, at der ikke er nogen trin at vise.

Her kan du selv prøve prototypen: Prototype A.2

Konklusion

Der er ingen klar vinder mellem de to tilgange, da begge har deres unikke styrker og svagheder. Mange rettelser kommer i senere iterationer. Der er bestemt flere brugertest at gøre, men det kommer også senere. Navigation er kun en smule af den større oplevelse, som burde være det egentlige genstand for testning.

I mellemtiden kan du finde begge prototyper her:

https://checkout-redesign-89a9e.firebaseapp.com/#/

Gå videre og prøv prototyper (glem ikke at skifte mellem dem ved hjælp af Prototype Manager-menuen nederst til højre), og slå mig op med dine forslag og ideer på Twitter.

Glem ikke at abonnere, og jeg ser dig i del II: Indkøbskurv Gendesign.