Design ikke dette hjemme ... 3 UI-katastrofer at undgå
Jeg lavede et udtryk i dag: Loathsome Design.
Det betyder noget i retning af " design beslutninger, der får mig til at dø." Med andre ord er det modsat af den nyligt populære " designe for glæde " koncept.
Loathsome design fanger essensen af frustration. Ofte kommer det til som følge af forsømmelse - i et forsøg på at opnå en ting, skal der være noget andet, der skal tilbage af vejen.
Hvorfor skal du bekymre sig om uhyrlige designpraksis?
Fordi de er type beslutninger der kan køre brugere fra dit indflydelsessfære og ind i dine konkurrenters.
1) Skjulte indstillinger
Jeg åbnede min Spotify-app i dag med det formål at vise en uafklaret medarbejder sine "ekstrem kvalitet" streaming muligheder, så han kunne træffe en informeret beslutning om hvilken musikplatform der ville tjene ham bedst - Google Play Musik, Spotify eller Tidal.
Før Spotify redesignede deres Android-app for at efterligne designsproget for deres iOS-app (og i virkeligheden, iOS selv), blev indstillingsikonet placeret i hamburgermenuen. Det var ligetil og intuitivt.
Nu hvor hamburgermenuen er toast, er de fire menupunkter blevet flyttet til et permanent sted nederst på skærmen.
Så hvor er indstillingerne knappen?
Det er spørgsmålet, jeg selv spurgte.
Det viser sig, at Spotify's designere har gemt indstillingerne væk i øverste højre hjørne af fanen "Din bibliotek" en ekstremt uintelligent placering, hvis du spørger mig.
Og har du bemærket, hvor knappen "Min profil" gik? Ja heller ikke mig. Det lille ikon i øverste venstre hjørne af fanen "Din bibliotek" (den der næsten ikke passer til en stavfigur) er det, du leder efter.
Det nye design kan blive foruroligende for brugerne, fordi det tvinger dem til at fyre med menuen for at finde indstillingerne eller deres profil.
For nogle kan dette være et glimrende eksempel på ulemperne ved Apple-stil bundmenuen; for andre er det kun et tilfælde af larmende design .
2) Forstyrrende Lancering
Et særligt larmende design valg er den forstyrrende lancering. Uber og Wikipedia er begge meget skyldige i dette, undtagen Wikipedia gør kun dette under deres fundraising sæson , mens uber gør dette år rundt.
En forstyrrende lancering er en, hvor brugeren er forpligtet til at gennemføre en opgave, før han bruger appen. I de fleste tilfælde er dette en engangs ting, der kræves af brugerne ved første start-aka, skal brugeren tilmelde sig, før de kan bruge tjenesten. Det giver mening, og det er ikke så meget af et besvær.
Uber tager dette et skridt videre ved at tvinge brugerne til at vurdere deres tidligere driver, før de kan bestille en tur. Uanset om du har travlt, eller hvis du ikke ønsker at bedømme en chauffør, kan du ikke bestille en tur uden bedømmelse af den forrige.
Dette er ikke kun en ulejlighed, men det ændrer aktivt den måde, brugerne interagerer med appen. Ved at bede brugerne om at bedømme en driver ved hver lancering, er de i det væsentlige betingelse for brugerne at ubevægeligt klikke på en rating så hurtigt som de kan (se: Klassisk konditionering ).
Hvad der sandsynligvis lignede en god ide på Uber designteamets tavle er faktisk en frygtelig taktik, der har gjort mig, og sandsynligvis andre brugere, apatisk over for ratingsystemet.
Brugere opfordres effektivt til ikke at tænke før rating, fordi det gør det forsinke deres tilfredsstillelse . Hver chauffør får en fem stjerneklassifikation (eller hvor en brugers tommelfinger komfortabelt falder på ratingskalaen) uanset oplevelsen.
Wikipedia er også skyldig i dette, hvis i mindre grad. I løbet af fundraiser sæsonen, er besøgende på Wikipedia bedt om at donere til online-encyklopædi-noget, jeg ikke er indiøst imod.
Det er den måde , som webstedet beder brugerne om at donere, der gør det modbydeligt.
Donationsprompten overtager skærmens fulde højde og giver ingen indikation, at brugeren kun skal rulle ned for at se deres påtænkte side.
Over tid vil de fleste brugere selvfølgelig lære at hvis de ikke ønsker at donere, behøver de kun at rulle ned, men for første gangs brugere er det sandsynligvis en katastrofal irritation.
3) besværlige interaktioner
Lejlighedsvis kræver alt, at et designvalg skal blive voldsomt, for at det kræver besværlige interaktioner. Et glimrende eksempel på dette er den måde, hvorpå Apple og nogle tredjepartsversioner af Android har designet deres alarmklokke apps.
Det er ikke appsne som helhed, der får mig til at føle sig belastende, men snarere den måde, hvorpå designerne kræver, at brugerne indtaster den tid, hvor en alarm lyder.
Dette er det rene onde. Hvem besluttede at rulle til en bestemt tid, i trin af en, var en god idé?
Det tager ikke kun længere tid at rulle, end det ville være at indlæse en tid på en håndfuld andre almindelige måder, men det kan heller ikke gøres i én bevægelse. På ZTEs Android-hud, for at komme fra "01" minutter til "59" minutter, skal brugerne skubbe flere gange .
På iOS, vil en swipe sende numrene spinning med momentum . Selvfølgelig er det køligt og realistisk, men det er næppe mere effektivt eller brugbart. Dette synes at være en nuværende tendens med apple
En dramatisk mere effektiv og brugbar metode til indlæsning af alarmværdier er præsenteret på lager Android.
Googles designere har fundet ud af et layout, der giver brugerne mulighed for at indtaste alarmværdier i kun to vandhaner . Det betyder, at når søvnige brugere forsøger at indstille en alarm, bliver de ikke tvunget til at være ekstra opmærksomme på inputmetoden og kan i stedet fokusere på at blive i seng.
Lad dine brugere ikke ødelægge dit design
Der er ikke så mange ting, der får brugere til at ødelægge din app. Typisk er nummer ét lovovertrædelse simpelthen forstyrrende for brugerne.
Skjul kritiske funktioner, forstyrre lanceringen af en app og udformning af alt for komplicerede interaktioner vil generere dine brugere, og afhængigt af hvor meget det generer dem, kan de komme til at ødelægge din app.
At undgå faldgrubernes faldgruber er ikke svært.
Du skal bare starte (og afslutte) alle funktioner med et enkelt spørgsmål: gør jeg det så bekvemt og intuitivt som det kunne være?
Hvis svaret på et af disse spørgsmål er nej, så er der stadig arbejde, der skal gøres.