Fotokredit: Miserlou Behind The Aperture via Visualhunt.com / CC BY-SA

Ni ubehagelige UX-sandheder

Der er meget at lære på internettet om UX-teori, men tipene nedenfor er 100% resultatet af hårdt fortjent oplevelse… a. Smertefulde øjeblikke. Jeg har skruet meget sammen i de sidste tyve år, og dette er nogle af de måder, jeg har fundet ud for at stoppe med at skrue op. Nyd at lære af mine fejl!

Fire sandheder om design:

Det er faktisk ikke så svært, og du er ikke halvt så smart, som du tror.

1. Farve er meningsløs

Brugerne forstår ikke din farvekodning. Grønt betyder måske "godt" for dig, men for en anden på en anden skærm kan det muligvis betyde "ulæselige" eller "gåseed" eller "Saigon - Shit - jeg er stadig kun i Saigon ..."

Hver person ser hver farve på en helt personlig måde, hvis overhovedet. De kan godt lide nogle farver og hader nogle andre, og det er stort set uforudsigeligt. Du kan ikke vinde.

Farve er ikke verbal eller rationel. Det er kontekstuelt og følelsesladet. Det er magtfuldt, ikke meningsfuldt.

De eneste ting, du kan kommunikere med farve, er:

Enhver farve: denne ting har en farve.

En anden farve: denne ting er ikke den samme som den anden ting.

Grå: denne ting er ødelagt.

Rød: designeren hader dig og vil gøre dig vred.

2. Position betyder mest

Brugere er ligeglad med, hvad din knaps ikoner er, eller hvad deres mærker siger. Du kan redesigne dem hver dag, og ingen vil klage.

Flyt ting rundt, og dine brugere vil have dit hoved på en gedde.

Folk bruger deres naturlige positionshukommelse til at huske, hvordan man bruger din app. At flytte deres interfaceelementer rundt føles for dem som den mest perverse form for tortur. Hvis du vil vide, hvor rent ufiltreret brændende had føles, skal du gå videre og flytte tingene rundt.

3. Ingen læser

Du læser sandsynligvis ikke denne sætning. Hvis du er det, har du sandsynligvis ikke engang læst denne artikel gennem første gang. Du scannede overskrifter og citater, og måske springer du gennem de korte afsnit nu.

Da det er sandt, hvorfor skriver vi instruktionstekst? Hvorfor tillader vi lange afsnit af kopi i vores grænseflader? Hvorfor foregiver vi, at brugermanualer og ofte stillede spørgsmål er en gyldig løsning på brugervenlighedsproblemer?

Fordi vi er dovne, det er derfor. For doven til at læse, og også for doven til ikke at skrive.

4. Navigation er mislykket

Vær ikke stolt af din navigationsgrænseflade eller din informationsarkitektur. Hvis din app har en fremtrædende navigationsgrænseflade, er du allerede på vej til fejl.

Dit job er at hjælpe brugeren med at nå deres mål. Navigation i en grænseflade er aldrig brugerens mål. Hvis du havde gjort dit job rigtigt, ville appen kun gøre en ting og ville gøre det meget godt og ville gøre det hele på en skærm. Men du har undladt at beslutte og fjerne valg, og du overlader det til brugeren at gøre det.

Design gør de hårde valg, så din bruger ikke behøver det. (Tweet dette)

Ja, okay, navigation er nødvendig for de fleste apps, de fleste steder, de fleste oplevelser. Vi er nødt til at indgå nogle kompromiser i livet. Jeg er selvfølgelig enig. Jeg ender næsten altid med at indgå kompromiser og leverer navigation. Stadig, skam over mig og skam over dig.

Tre sandheder om processen:

Ikke alt er lige så vigtigt. Der er nogle ting, du skal gøre først, nogle ting, du skal gøre mere, og nogle ting, du helt kan ignorere. Sådan fortæller du forskellen:

5. Indholdet er godt, brugergrænsefladen er dårlig

Min første UX-relaterede jobtitel, før begrebet “UX” var blevet formuleret, var Informationsarkitekt. Det er stadig det vigtigste job der er på ethvert projekt. Ting har navne og skal skrives. Definition af navne og verb er den vigtigste del af UX.

Indholdet er løsningen. Hvis du ikke designer indholdet, designer du problemer. (Tweet dette)

Hver gang du opretter en wireframe med lorem ipsum, fornærmer du dine brugere og misbruger din klients tillid. Du saboterer også dig selv.

Loremipsitis er at designe, hvad klamydia er at elske. (Tweet dette)

Når du undlader at kæmpe direkte med det faktiske indhold, men fokusere på at designe bokse til hvad indholdet vil være, er det, du faktisk laver, at placere smukke bokse mellem brugeren og deres mål. Stop det. Design indholdet, og du er sandsynligvis næsten færdig.

6. udsæt kompleksiteten væk

Foretag sitemap og navigation senest på et projekt. Faktisk skal du aldrig gøre dem. Start med det vigtigste objekt eller skærm: det, der hjælper brugeren med at nå deres mål. Spild al projektets tid og budget på at gøre denne skærm perfekt. Besætte over enhver detalje. Overdådige timer til udseendet af hver pixel. Forkæl dig med enhver smag og nyd hvert minut af det.

Når der ikke er mere tid eller budget, vil din klient / chef blive meget vred og skrige på dig, at du ikke gjorde alt det andet skidt, de ønskede, at klæbe ned i brugerens hals. Spil stum, undskyld, og tjen dig selv et ry som en flage, der aldrig afslutter noget ... men alligevel, design ikke noget af det.

Undlader at planlægge at designe de dumme dele. (Tweet dette)

Forhåbentlig skubbes det skrammel, du ikke designede, til version 2, og brugerne får glæde af version 1, indtil du bliver fyret og din erstatning ødelægger det hele for alle. Der er ingen mangel på UX-designere, der gør som de får at vide, og leverer, hvad der forventes af dem. Dette er grunden til, at der er så meget bloatware i verden. Vær ikke en af ​​dem. Bliv løbet.

7. Brugertest dræber babyer

Brugertest er spektakulært fantastisk, det er et kendt faktum. Ligegyldigt hvor utroligt smart du er, og hvor klog dit brugergrænseflade er, vil ti minutters brugertestning tidligt i processen redde dig fra ulykkelig fejl på vejen.

Regler for brugertest. Hvis du ikke gør det, er du en idiot. (Tweet dette)

Brugertest frigør dig dog ikke fra ansvaret for at være smart, at arbejde hårdt, at svede detaljerne ud og gå gennem den vanvittige, krænkelige, tarmforbrændende, bizarrely amorfe designproces. Du bliver stadig nødt til at være et geni, buster. Og det er især tilfældet, når du designer innovative løsninger eller produkter.

Det er fordi, når det kommer til innovation, kan brugere være slemme, snævre, myopiske, forgæves, filistinske, små og dumme. Og det kommer fra nogen, der har viet sit liv til at elske sine brugere.

Brugertestning af nye ideer suger. Hvis du gør det, er du en idiot.

Når du har en god ny idé, vil det starte sit liv som et skrøbeligt embryo, som næppe er levedygtigt. Det har brug for pleje og kærlig pleje for at vokse til en fuldt ud dannet innovation, der kan stå på sine egne to ben og modstå uforsigtig håndtering af egoistiske brugere. Brugertestning af en ny idé er som haj-testning af et nyt lam: Det ender ikke godt med ideen eller lammet.

Så lad ikke din idé gå uprøvet ... men kun når den er klar. Hvordan ved du, hvornår det er klar? Når du har arbejdet på det længe, ​​til at du begynder at se dets grundlæggende mangler: Problemer, der ikke handler om, hvordan det er blevet sammensat (improvabelt), men om, hvordan det fungerer i det absolutte (iboende). Når det fungerer tæt nok på den måde, du havde til hensigt, at du kan begynde at tænke på bedre alternativer ... så er den sandsynligvis klar til at teste.

To sandheder om kodere:

Du tror måske, at det, som kodere gør med dit design, ikke er din skyld. Fair nok, men det er stadig dit ansvar. Ligesom at sende en meddelelse, der ikke vil blive modtaget, er levering af design, der ikke vil blive forstået, spild af alles tid.

Du skal forstå dit publikum, og dit publikum er kodere. De er underlige dyr, men så igen, så er du også.

Hvis du passer godt på DevX på din UX, vil devs gøre dig rig og berømt. (Tweet dette)

Du skal virkelig stige af din doven designer-røv og lære at kode allerede. Men indtil du gør det, er det her, du har brug for at vide om kodere:

8. Kodere lærer af forfærdelige eksempler

Udviklere udforsker ikke veldesignede apps og sider for at lære, hvordan man bygger apps og websteder. De bruger deres tid på at lære af demoer og tutorials, som er skrevet af andre udviklere, der prøver at forklare komplekse kodningskoncepter ved hjælp af foragtede, latterlige eksempler.

Kodetutorials underviser i UX dårligste praksis. (Tweet dette)

De tænker ikke på den virkelige livsgyldighed af disse eksempler. De tænker ikke på UX for disse eksempler. De giver ikke en rottes røv, om disse eksempler ville føre til positive resultater for brugeren i deres fiktive scenarier.

Tusinder af udviklere lærer deres håndværk ved blindt at implementere alt for enkle, dårligt designede, dumme scenarier i timevis. Derefter bygger de din app baseret på et par spinkle wireframes og på hundreder af timers forfærdelige tutorials. Så måske skulle du være lidt mere specifik med dine specifikationer?

9. Kodere elsker absurditet

Programmerere er nødt til at bekymre sig om ting, som ikke et sunt menneske nogensinde overvejer. Du slipper et "efternavn" -felt i dit design uden at tænke over det, men til en koder er der hundrede angst forbundet med det:

  • Hvad hvis personen ikke har et efternavn?
  • Hvad hvis deres efternavn udtrykkes som en matematisk ligning?
  • Hvad hvis deres efternavn er længere end 255 tegn?
  • Hvad hvis deres efternavn indeholder fanetegn, flere afsnit, ikke-brudende mellemrum, emoji, parenteser, kommaer, enkelt- og dobbeltcitater?
  • Hvad hvis deres efternavn ændres mellem det tidspunkt, hvor de indtaster det, og det tidspunkt, hvor de indsender formularen?

For ethvert normalt menneske er disse spørgsmål absurde. For en koder er de sund fornuft. Hvad det betyder for dig, som designer, er, at du skal holde dig tæt på dine kodere, prøve så meget som muligt at forudse de ængstelser, der vil belejre dem, og forhindre dem i at afspore oplevelsen med fuldstændig lunhed.

Held og lykke med det forresten. Sørg for, at du nyder turen.

Jeg er UX Lead med WAX Interactive Switzerland. Min besætning og jeg forstyrrer markeder og forretningsmodeller ved at gøre UX anderledes. Vi ansætter også Senior UXers og Full-stackers, der elsker håndværket og årsagen.

Jeg bider ikke (hårdt), så tøv ikke med at nå ud.

Tak!