Share
Til fordel for programvare og applikasjoner overalt, har UX blitt et stadig viktigere trinn i Software Development livscyklus. Selv om UX er et litt surreptitivt lag med design, er det ikke mindre viktig. Det definerer, etter arten av navnet, brukerens opplevelse. Denne erfaringen avgjør om de ønsker å komme tilbake for mer eller løpe skrikende i den andre retningen.
UX er noe noen kan gjøre. Problemet er ikke at alle kan gjøre det bra. Jeg kan gjennomføre visuell design for et nettsted, men jeg garanterer deg at det vil se fryktelig og uprofesjonelt ut.
Hvis du ikke lærer noe annet om UX, spør jeg deg om å huske disse to tingene.
Hvis du ikke kjenner brukerbasen din, deres vaner og tendenser, og hvorfor de gjør eller ikke utfører bestemte handlinger, kan du ikke forventes å designe en god opplevelse for dem. Selv om du er veldig lik brukerne dine, husk at du bare er en person, og det definerer ikke kvaliteter til brukerbasen som en helhet. Bli kjent med brukerne dine og utform opplevelsen med dem i tankene. En UXers rolle er å ha den kunnskapen, utvide den hele tiden, og designe med de brukerne i tankene, lage fantastiske opplevelser som vil glede seg og oppfylle dem.
La oss se på alle mulige trinn en UXer kan ta i å definere UX av et produkt. Disse trinnene skaper den ideelle prosessen. Disse trinnene er ikke alltid mulige å fullføre i den virkelige verden, men vi må dekke alle dem slik at du er klar over når du kan gå ut av bestemte trinn og hvorfor. Noen ganger forlater du ikke nødvendigvis et skritt, men det meldes inn i et annet trinn, eller erstattes ved hjelp av en kombinasjon av erfaring, kunnskap og intuisjon.
Krav Gathering er et av de første trinnene i å designe UX. I løpet av dette stadiet må du stille mange spørsmål. Mange spørsmål kan kanskje ikke besvares med en gang, men noter dem og være vedvarende. Det finnes flere typer krav:
Disse kravene vil være grunnlaget som vil forme designen din. Uten disse vil designene dine være formålsløse.
Før vi kan designe for en bruker, må vi kjenne våre brukere. Noen ganger vil du ha mye eksisterende kunnskap om dem. Noen ganger vil du bare vite en håndfull forutsetninger om dem. Hvis du ikke har kjennskap til brukerne dine, så er ditt design et utdannet gjetning i beste fall. Brukeranalyse er nødvendig for å forstå brukerens behov og tilbøyeligheter.
Du må stille følgende spørsmål for å få tak i brukerbasen din:
Etter at vi har fullført vår brukeranalyse, må vi gå videre til oppgaven analysen. Hva er den primære handlingen brukerne må utføre? Det kan være mange ting noen kan gjøre på nettstedet ditt eller programmet, men det er alltid en hovedoppgave. Du må finne ut hva denne oppgaven er og optimalisere UX for den oppgaven for den spesifikke brukerbasen som den er beregnet på. Vi har fortsatt ikke nådd designstadiet, men nå vet vi hva vi skal designe, og for hvem vi designer det.
Vi må også bestemme eventuelle sekundære oppgaver. Det er svært få sider / applikasjoner der brukerne bare kan gjøre en ting; Det er ofte flere relaterte oppgaver som skal utføres. Omfang alle disse for å kjenne bredden til det du designer mot.
Andre ting å finne ut i oppgaven analyse:
Funksjonallokering er å finne ut hva som må håndtere alle funksjonene du har bestemt, må skje. Dette skjer på flere nivåer.
Svarene på disse spørsmålene kan dramatisk påvirke effektiviteten og bruken av produktet.
Skisse. Mye. Det er raskt. Det er billig. Det er effektivt.
Sketching får mange ideer ut av hodet og på papir raskt. Det hjelper til med å forme gode ideer og eliminere dårlige. Du kan iterere på skisser veldig raskt. Investeringen er lav for retur.
Kreativitet er også nøkkelen i dette trinnet. Gjør noen knettete, off-the-wall ting. De kan ikke fungere, men de kan anspore en annen ide. Prøv å variere skissene dine betydelig for å se hvor langt du kan strekke en ide.
Penn / blyant + Papir = En bank å tegne fra for når du begynner å definere designene dine.
Nå bør du ha minst en ide om hvor du vil at designen din skal gå. Det første settet av wireframes bør være en iterasjon på skissene dine og begynne å gi mer definisjon. Informasjonsarkitekturen bør begynne å finne sted. Det er her ting går fra en masse løst forbundne konsepter og deler av informasjon til en mer sammenhengende dokumentasjon av hvordan produktet ser ut og fungerer.
Det er mange forskjellige prototyper du kan gjøre. Disse kan variere fra en veldig enkel klikkbar PDF til et nesten fullt fungerende HTML / CSS nettsted. Det er virkelig avhengig av hva du trenger for prosjektet ditt, for hvor langt du går med det. Det er mange verktøy der ute, men å få prototyper opp veldig raskt. En liten prøve inkluderer:
Finn ut verktøyet som passer til arbeidsflyten og kunnskapsbasen for å finne ut hva du kan prototype raskt og effektivt. Prototyper bør ikke ta lang tid, men de burde effektivt kommunisere design og interaksjoner.
Prototyper hjelper deg med å finne ut hvor noen rarhet ligger i samspillet og hva det føles når produktet faktisk er i bevegelse. Det kan bidra til å avdekke noen ting som statiske wireframes kanskje ikke kan avdekke helt.
Dette er hvor du deretter går tilbake og begynner å gjøre wireframes high-fidelity. Legg til all definisjon du trenger. Dekke så mange detaljer om layout og samhandling som du kan. Alt du forlater åpent for tolkning, kan lett bli tatt motsatt måte du ønsket. Ikke anta noe.
Bedre visuell kvalitet kan eller ikke er nødvendig. Mesteparten av tiden dette virkelig bør tas vare på i den visuelle designfasen. Jeg har funnet det ofte bedre å falle tilbake på flere wireframe-y visuals for å unngå forvirring med sluttfarger og visuelle designspesifikasjoner. Imidlertid bruker jeg farge hvis den er relatert til funksjonalitet (for eksempel rød for feilmeldinger).
Dette trinnet kan foregå hvor du trenger det under designprosessen. Det passer noen ganger på slutten og noen ganger mer mot begynnelsen av et prosjekt. Dette er imidlertid her du får faktisk tilbakemelding fra brukerne. De kan bekrefte mistankene dine. De kan slå dine tanker på hovedet. Dette er avgjørende skjønt for å kjenne sine tanker og hvor deres problemer ligger.
Du designer for brukeren. Denne tilbakemeldingen skal drive design eller redesign for å løse problemene som oppstår under denne testen. Rabattering eller ignorering av denne tilbakemeldingen, sans true outliers, er uklok og en absolutt UX synd.
Jeg har sett mange UX-prosesser anser dette som punktet i hånden deres dokumentasjon over gjerdet, krysser fingrene og håper på det beste. Det burde ikke være tilfelle! Jeg jobber veldig collaboratively selv etter at jeg er ferdig med UX-riktig.
Dine visuelle designere bør også tenke på UX. Hvis de ikke er det, ville jeg motsette seg at de ikke jobber fullt ut. Å gjøre din wireframes ser bedre ut er bra, men hvis de har en ide som gjør at UX enda bedre er villig til å lytte og innlemme. Ofte tenker designere forskjellig nok til å anspore gode ideer og forbedringer.
Tilsvarende bør du jobbe med utviklere. Dette kan ikke være ganske samarbeidende, men det er ofte problemer som oppstår i dette stadiet der du må justere UX. Dette hjelper deg også til å få en forståelse av de tekniske begrensningene for fremtidige prosjekter. Utviklerne dine vil være mye lykkeligere for deg å få denne kunnskapen enn å designe umulige løsninger.
Test også UX mot sluttproduktet. Det er her du går tilbake til wireframes og sørger for hva som kommer ut til kundene dine, er det du designet. Det er ikke uvanlig at noe ikke stemmer overens, og du bør være komfortabel nok med utviklerne dine til å peke ut disse problemene. Til slutt er du ansvarlig for brukerens opplevelse, så sørg for at de får produktet du har designet.
Disse er bare grunnleggende for å sette sammen stor UX. Du kan ikke være i stand til å utføre alle disse trinnene, men du må være oppmerksom på at alle skal vite når du kan legge dem ut.
Jeg tror personlig at UX ikke er en formel. Det er forskjellig fra prosjekt til prosjekt og bygger på sammensetning av kunnskap, erfaring, forskning og intuisjon. Vi dykker videre inn i bestemte områder i fremtidige artikler, men vi trengte først grunnlaget for hva en UXer gjør på en gitt dag på jobben. Trinnene som er skissert ovenfor, får deg på vei for å vite hvordan du kan sette sammen flott UX for produkter som brukerne vil elske.
Accentsconagua