Ikke designe dette hjemme ... 3 UI-katastrofer å unngå
Jeg laget en term i dag: Loathsome Design.
Det betyr noe i form av " designbeslutninger som får meg til å dø." Med andre ord er det motsatt av den nylig populære " designe for glede "Konsept.
Loathsome design fanger essensen av frustrasjon. Ofte kommer dette til som et resultat av forsømmelse - i et forsøk på å oppnå en ting, må noe annet bli forlatt av veikanten.
Hvorfor bør du bryr deg om uhyggelig designpraksis?
Fordi de er type beslutninger som kan lede brukere fra ditt innflytelsessfære, og inn i konkurrentene dine.
1) Skjulte innstillinger
Jeg åpnet Spotify-appen min i dag med det formål å vise en ubestemt samarbeidspartner sine "ekstrem kvalitet" streaming alternativer, slik at han kunne ta en informert beslutning om hvilken musikkplattform som ville tjene ham best, Google Play Musikk, Spotify eller Tidal.
Før Spotify redesignet sin Android-app for å etterligne designspråket i deres iOS-app (og i virkeligheten, iOS selv), ble innstillingsikonet plassert i hamburger-menyen. Det var grei og intuitivt.
Nå som hamburger-menyen er toast, har de fire menyalternativene blitt flyttet til et permanent sted nederst på skjermen.
Så hvor er innstillingene knappen?
Det er spørsmålet jeg spurte meg selv.
Det viser seg at Spotifys designere har gjemt innstillingene vekk i øverste høyre hjørne av "Din bibliotek" -fanen; en ekstremt unintuitiv plassering, hvis du spør meg.
Og la du merke til hvor "Min profil" -knappen gikk? Ja, jeg heller ikke. Det lille ikonet i øverste venstre hjørne av "Din bibliotek" -fanen (den som knapt passer for en pinnefigur) er det du leter etter.
Det nye designet kan forstyrre brukerne, fordi det tvinger dem til å fla med menyen for å finne innstillingene, eller deres profil.
For noen kan dette være et godt eksempel på ulempene ved Apple-stil-bunnmenyen; for andre, dette er bare et tilfelle av loathsome design .
2) forstyrrende lansering
Et spesielt loathsome design valg, er den forstyrrende lanseringen. Uber og Wikipedia er begge ekstremt skyldige i dette, bortsett fra Wikipedia gjør bare dette under deres innsamlingssesong , mens Uber gjør dette året rundt.
En forstyrrende lansering er en hvor brukeren er pålagt å fullføre en oppgave før du bruker appen. I de fleste tilfeller er dette en engangstakt som kreves av brukere ved første start-aka, må brukeren registrere seg før de kan bruke tjenesten. Det er fornuftig, og det er ikke så mye av et problem.
Uber tar dette et skritt videre ved å tvinge brukerne til å vurdere sin tidligere sjåfør før de kan bestille en tur. Uansett om du har det travelt, eller hvis du ikke vil vurdere en sjåfør, kan du ikke bestille en tur uten vurdering forrige.
Dette er ikke bare et ulempe, men det endrer aktivt måten brukerne kommuniserer med appen. Ved å oppfordre brukere til å rangere en sjåfør ved hver lansering, er de i utgangspunktet betinget av at brukere klikker på en vurdering så raskt som mulig (se: klassisk kondisjonering ).
Det som egentlig så ut som en god ide på Ubers designteamnes tavle er faktisk en fryktelig taktikk som har gjort meg, og sannsynligvis andre brukere, apatisk mot ratingsystemet.
Brukerne oppfordres effektivt til ikke å tenke før vurdering, fordi det gjør det forsink deres tilfredstillelse . Hver sjåfør får fem stjerner (eller hvor en brukers tommel faller komfortabelt på karakterskalaen), uavhengig av opplevelsen.
Wikipedia er også skyldig i dette, om i mindre grad. I løpet av fundraiser sesongen, blir besøkende til Wikipedia bedt om å donere til den elektroniske encyklopedi-noe jeg ikke er oppriktig imot.
Det er måten at nettstedet ber om at brukerne skal donere som gjør det uhyggelig.
Donasjonsprompten tar over hele skjermens høyde, og gir ingen indikasjon på at brukeren bare trenger å bla ned for å vise sin tiltenkte side.
Over tid, selvfølgelig, vil de fleste brukere lære at hvis de ikke ønsker å donere, trenger de bare å rulle ned, men for førstegangs brukere er det sannsynligvis en katastrofal irritasjon.
3) besværlige interaksjoner
Av og til, alt som trengs for at et designvalg skal bli avskyelig, er at det krever tungvint interaksjoner. Et godt eksempel på dette er måten Apple og noen tredjepartsversjoner av Android har designet sine alarmklokkeapps på.
Det er ikke appene som helhet som får meg til å føle seg plaget, men heller måten designerne krever at brukerne skal legge inn tid når en alarm vil høres ut.
Dette er ansiktet av rent ondt. Hvem bestemte seg for at man rullet til en bestemt tid, i trinn på en, var en god ide?
Ikke bare tar det lengre tid å bla enn det ville legge inn en tid på en av en rekke andre vanlige måter, men det kan heller ikke gjøres i en bevegelse. På ZTEs Android-hud, for å komme fra "01" minutter til "59" minutter, må brukerne sveipe flere ganger .
På IOS, vil en swipe sende tallene spinner med momentum . Selvfølgelig er det kult og realistisk, men det er neppe mer effektivt eller brukbart. Dette synes å være a nåværende trend med Apple.
En dramatisk mer effektiv og brukbar metode for innlasting av alarmverdier er presentert på lager Android.
Googles designere har funnet ut et oppsett som lar brukerne legge inn alarmverdier i bare to kraner . Dette betyr at når søvnige brukere forsøker å stille en alarm, vil de ikke bli tvunget til å være ekstra oppmerksom på inngangsmetoden, og kan i stedet fokusere på å sovne.
Ikke la brukerne fange ditt design
Det er ikke så mange ting som vil få brukerne til å ødelegge appen din. Vanligvis er nummer én lovbrudd ganske enkelt ulempe for brukerne.
Å gjemme kritiske funksjoner, forstyrre lanseringen av en app og å designe altfor komplekse interaksjoner, vil forstyrre brukerne, og avhengig av hvor mye det plager dem, kan de komme til å ødelegge appen din.
Å unngå fallgruvene til avskyelig design er ikke vanskelig.
Du må bare starte (og fullføre) hver funksjon med ett enkelt spørsmål: gjør jeg dette så praktisk og intuitivt som det kan være?
Hvis svaret på noen av disse spørsmålene er nei, så er det fortsatt arbeid å gjøre.