Innhold
- Har du et designmønster? Planlegg det
- Tenk gjennom prosessen
- Designmønstre fjerner gjetning
- Brukertesting: innsikt du ikke kan ignorere
- Forbered deg på å teste prototyper
- Neste skritt
Det er mange grunner til å hoppe over wireframing og lo-fi prototyping. Ingen av dem er gyldige.
Vel, kanskje hvis du trenger det i morgen og planlegger å revidere senere: bygg først, planlegg andre, håp på det beste hele tiden.
Prototyping er et kritisk trinn i produktdesign. Sluttprodukter er kompliserte, og derfor vanskelige å endre. Prototyper er relativt billige å bygge og omorganisere. Og mens de tar innsats foran, er det vel verdt innsatsen å planlegge og teste en prototype.
Prototyper skaper et felles designspråk. Med dem kan designere oppsøke problemer mens innholdsfolk ser hvordan deres arbeid passer inn i prosjektet. I mellomtiden forstår utviklere interaksjonene, og klienter kan gi godkjenning eller foreslå endringer.
I dette innlegget vil vi undersøke hvordan prototyping hjelper deg med å bruke smartere designmønstre og samarbeide bedre med utviklere.
Har du et designmønster? Planlegg det
Som forklart i Web UI Pattern Handbook, er designmønstre ikke begrenset til det visuelle. Det er også aksepterte prosessmønstre. Før vi velger visuelle mønstre, må vi søke disse overordnede prosessmønstrene.
Ta for eksempel finn-et-hotell-prosessen. Ved første øyekast er det ikke engang verdt å nevne. Mønsteret er så vanlig at vi tar det for gitt:
- Reisende kommer til hjemmesiden.
- Reisendes søk etter hotell.
- Reisende sammenligner alternativer.
- Reisende velger hotell.
Det kan til og med forenkles til "søk, sammenlign, velg". Et løst designmønster. Men det gloser over noen få kritiske detaljer - detaljer som utviklere ikke kan ta for gitt, og detaljer som designere bør vurdere nøye.
En mer nøyaktig prosess kan omfatte:
- Reisende ankommer et sted på nettstedet, avhengig av hvordan de fant nettstedet til å begynne med.
- Den reisende bruker søkeverktøyet - enten det alltid tilstedeværende søkefeltet i menylinjen, eller hjemmesidens mer fremtredende "finn det!"
- Den reisende tapper gjennom sider med alternativer og sammenligner på en eller annen måte lovende hoteller mot hverandre.
- De velger et hotell ved å trykke på "bestill dette" på enten detaljsiden eller søkeresultatsiden.
- Nettstedet presenterer et skjema for navn, antall personer og netter, datoer og kredittkortinformasjon.
- Den reisende legger inn informasjonen sin og klikker "bestill nå".
- Nettstedet sender informasjon til det aktuelle hotellet.
- De mottar en e-post som bekrefter avtalen.
Alle disse "ifs" og "dependings" og "somehows" er åpne for tolkning. Innenfor det finner vi mange designbeslutninger å ta.
Bør hjemmesiden si "finn den" eller "søk nå"? Hvor mange resultater vises per side, og hvordan er de fordelt? Etter hvilke parametere søker de til å begynne med? Og av og på ...
Prototyper kommuniserer til utviklere hva de bygger. Å fjerne tvetydighet betyr at de har mindre å bestemme selv. Når du gjør det, avdekker du også manglende kritiske trinn. Du vil ikke oppdage hva disse trinnene er, og enda mindre finne kreative måter å skille seg fra konkurrentene, med mindre du setter deg i brukerens sko og prøver designet selv.
Tenk gjennom prosessen
En morsom ting skjer når du prototype: du begynner å bruke designet. I motsetning til statiske modeller, vil du finne deg selv å jobbe både visuelt og interaktivt samtidig.
Denne doble tilnærmingen fører til alle slags kreative UI-mønsterbeslutninger. Ta shopping på hotell. Hva om vi finner opp en hybridvisning (vist nedenfor i prototypeverktøyet UXPin) mellom søkeresultatene og en detaljeside, hvor den reisende kan sammenligne utvalgte hoteller etter pris, beliggenhet, fasiliteter osv.?
- Avkrysningsruter og en "legg dette til alternativene dine" -knappen.
- Evnen til å rangere og sortere favoritthotell, kanskje ved å dra og slippe
- Evnen til å si "nei" til visse alternativer
- Muligheten til å søke etter lignende hoteller basert på favorittene deres
Sjekk ut demoen.
La oss nå se på 'søk etter sted'. Hva om søkeresultatsiden vår var et kart i stedet for en liste?
- Utviklere må bruke et søk, mest sannsynlig Googles API.
- Å velge flere hoteller for vår hypotetiske sammenligningsvisning kan bli problematisk, avhengig av API-alternativene.
- Mobilbrukere trenger en måte å bla gjennom siden, og unngå kartet.
Alle disse designbeslutningene kommer fra spørsmålstegn ved antagelser mens du går gjennom en prototype.
Designmønstre fjerner gjetning
Alle beskrivelsene så langt er åpenbart tekstbaserte. Gi dette til en utvikler, så får han eller hun en grov ide om hva han skal bygge.
Men altfor ofte skjuler tekst antagelser. "Denne siden vil ha et søkeskjema" overlater for mye til fantasien. Ikke gjør det. Det er din jobb som designer å ta disse beslutningene og komme med så mange mulige unntak som mulig.
En hjemmeside for hotellfunn har mange mulige konfigurasjoner. Det kan vise til spesialtilbud, et søkeskjema, de mest populære eiendommene eller hva annet designeren mener vil tjene reisende best på jakt etter et sted å bo. Noen av disse løsningene kan fungere, avhengig av dine prioriteringer og begrensninger.
Men det er ikke nok å fortelle utviklere. Du må vise dem hvordan designet fungerer.
Koderkode. Implementering er deres jobb. De trenger ikke å være opptatt av hvordan et produkt skal oppføre seg, undersøke brukerpersoner eller håndtere kunders ønsker og designbegrensninger.
Deres bekymring for å lage et nettsted mobilvennlig er mer relatert til mediespørsmål enn hvor mange bilder som passer komfortabelt på et nettbrett. Prototyping gjør jobben deres enklere ved å stave ut nøyaktig hvordan et produkt skal fungere, og la dem være fritt til å dykke ned i HTML / CSS / PHP / Ruby.
Så prototyper hjelper også designere å utarbeide mønstre i full grad. Det er lettere sagt enn gjort, ettersom planlegging av et design krever mye tanke i begynnelsen av et prosjekt. Det er der beslutningsprosessen skal skje, men tidlig før vi leverer en prototype til utviklere.
Hva skjer for eksempel hvis beskrivelsen på et hotell er ekstra lang? Hvordan skal søkeresultatene trimme teksten? Det er mange måter (mønstre, selvfølgelig) for å løse dette spesielle problemet. Kanskje fortjener den fulle beskrivelsen å vises på resultatsiden. Vi kan ende med en ellips ... eller vi ser bort fra tekstbeskrivelsene helt.
Mockups er ikke mye bedre. Å kompensere sider gir ingen følelse av nettstedets flyt, og frarøver utviklerne ånden bak beslutningene dine. De kan ikke se hvordan et nettsted henger sammen - og kan derfor ikke hjelpe deg med å stille spørsmål ved antagelsene. Utviklere er en smart mengde, og vi reduserer hjernekraften på vår bekostning.
Brukertesting: innsikt du ikke kan ignorere
Få ting frustrerer utviklere som å lære at de har laget feil produkt. Derfor er det viktig å søke ytre meninger før koding. Muligens den viktigste grunnen til å prototype med mønstre er å gi brukerne sjansen til å påpeke feil i designet - før du bruker tid på å bygge det endelige produktet.
For eksempel er et nøkkelordssøk i en hotellfinner ganske ubrukelig. Ekte hotellfunn lar reisende søke etter tilgjengelighet, pris og beliggenhet. Brukere vil påpeke det i en hast, men ikke fra statiske modeller.
Inntil de har prøvd det med en prototype, kan en bruker lett glanse over slike kritiske detaljer.
En bruker som jobber gjennom hotellfunn-appen, kan finne ut at visse mønstre er for enkle. Mer sannsynlig vil de påpeke behovet for å søke etter tilgjengelighet på gitte datoer, nærhet til turistattraksjoner, røykfrie / røykfrie rom og andre faktorer.
Mens de teknisk sett teller som et søkemønster, vil bruk av en prototype avsløre nødvendige detaljer. Det er ikke nok å bruke lorem ipsum. Ingenting slår å teste mønsteret i et ekte produkt.
Forbered deg på å teste prototyper
Det er andre grunner til å be folk som ikke er relatert til prosjektet om å teste en prototype. Å teste et produkt uavhengig er en god sjanse til å finne ut om vi bruker det mest passende mønsteret for å løse et designproblem. Trikset er å komme seg ut av veien og:
- Vær forberedt på å forlate mønstre. Noen ganger ordner ting seg bare ikke. Brukere ignorerer eller feiltolker dine nøye utformede baner gjennom et produkt. Å anerkjenne og fikse det er lettere hvis prototypen din er enkel og fleksibel nok til å redigere i en hast (det er derfor du alltid bør teste din lo-fi prototype først).
- Se etter løsninger. Brukere er naturlige prosessfunn. Når de blir kjent med en prototype, vil de oppdage måter å bruke den på som du aldri har vurdert. Hvis du holder deg utenfor veien, vil de ofte peke på mønstre og arbeidsflyter som du kan legge vekt på og finjustere for neste iterasjon.
- Vurder alternativer. Brukere peker ikke alltid direkte på hvilke mønstre som forvirrer dem. De vil vanligvis spørre hvorfor og hvordan, som i "hvorfor kan jeg ikke ...?" og "hvordan skal jeg ...?" Å lytte til deres bekymringer og observasjoner er en fin måte å identifisere hvilke arbeidsflytmønstre som ikke fungerer, og hvilke visuelle mønstre som ikke er klare. Vær oppmerksom, og still smarte oppfølgingsspørsmål.
Brukervennlighetstesting er avgjørende fordi andre stoler på at du har tatt best mulig beslutninger. La oss si at utviklere stoler på valgene dine og bygger et søkeord etter, i dette eksemplet, et hotellnavn og kanskje fasiliteter. Å plassere disse fasilitetene på hovedsiden for brukere å velge mellom, kan være en god idé - en som kommer fra å bruke tid på faktiske data, slik utviklere ikke pleier å gjøre.
Utviklere er smarte mennesker. Men å gi dem ansvar for å finne ut ting som søkeparametere, tar bare verdifull utviklingstid. De må stoppe opp og tenke på ting du burde ha vurdert før du la prosjektet på skrivebordet.
Og det er først og fremst kraften med å prototype designene dine: beslutningstaking på forhånd sparer tid for alle på sikt.
Neste skritt
Hvis du syntes dette innlegget var nyttig, kan du gå videre og sjekke ut den gratis Web UI Pattern Handbook.
Boken ble skrevet basert på min erfaring med design av nettsteder de siste 20 årene. Guiden på 104 sider forklarer hvordan du velger og bruker de beste designmønstrene med 100+ eksempler fra ESPN, Adobe, AIGA, Discovery Channel og mer.
Ord: Ben Gremillion
Ben Gremillion er en innholdsdesigner ved prototyping-appen UXPin hvor han skriver for det gratis ebokbiblioteket. Han har designet og kodet for nettet i nesten 20 år. Han bygger og vedlikeholder også et CMS for webcomic artister.
Likte dette? Prøv disse ...
- De beste wireframing verktøyene
- Lag wireframes som fungerer for deg
- 100 fantastiske Adobe Illustrator-opplæringsprogrammer
