26 trinn til perfekt produktdesign
I løpet av de siste fire årene har jeg designet dashboards og applikasjoner, og jeg har lært hvordan jeg skal håndtere ulike avdelinger, og utnytte deres kunnskap for å gjøre produktdesign mer effektiv.
I dag skal jeg dele alle trinnene jeg har bygget inn i min daglige rutine, som jeg tror har gjort meg til en bedre designer.
Pre-prosess
1. Få så mye informasjon som mulig (be om tre eksempler)
For meg gir ingenting mer klarhet enn å se et reelt fungerende eksempel. Når jeg jobber med en ny klient eller på en splitter ny destinasjonsside for et produkt, finner jeg at det enkleste utgangspunktet er å be klienten om å gi tre eller fire inspirerende sider, fordi dette virkelig hjelper begge parter. Å få kunden til å sette ideer på bordet gir deg muligheten til å forstå hva de liker, og hva de forventer av den ferdige designen.
Hvis du jobber med flere lag, bør du sikte på å bruke så mye tid med utviklerne på et produkt som du gjør med dine designer kolleger. Det jeg har lært er at nøkkelen til å lage en effektiv designbeslutning er å sikre at du snakker med dev-teamet så mye som mulig. I mitt tilfelle har det vært tilfeller der en løsning på et problem ble funnet, at jeg ikke kunne komme opp med meg selv.
Målet er å eliminere så mange spørsmål som mulig før du går inn i utviklingen.
2. Lær om personas
Først må jeg si at jeg var skeptisk til personas, men nå er det helt fornuftig for meg.
Så i fullstendig kontrast til min eldre prosess, kan jeg se hvordan personasjer er super viktige når du jobber med produktegenskaper, spesielt når løsningen har mange forskjellige kantsaker. Det hjelper deg å forstå hvem du virkelig designer for. Jeg tar sikte på å ha rundt fire til fem personas.
3. Sett opp nøyaktige mål - hva skal vi spore?
Jeg tror de fleste designere / klienter ignorerer dette trinnet, men et av de viktigste aspektene ved design for begge parter er å forstå målene for produktet du designer. Vi pleier å hoppe rett inn i piksler og raskt kutte ut prosjektets brukergrensesnitt. Hvis det er et helt nytt nettsted, eller en ny funksjon, må du sørge for å angi klare mål for hva du vil oppnå først.
Siden alt er sporet, snakk om de eksakte punktene du skal spore. For eksempel kan disse variere fra nye registreringer, til en rekke kunder som bruker Paypal vs kjøp med kredittkort. Sørg alltid for at du vet hvor høyt du sikter mot i begynnelsen!
(Du trenger dette uansett for å sette opp trekk på Mixpanel senere i denne prosessen.)
4. Sett opp en prosjektmappe og begynn å bygge et moodboard
Det er mange steder for inspirasjon - Dribbble , Behance , Pttrns etc. Det er veldig enkelt å finne lignende prosjekter til den du jobber med. I tillegg kan det allerede være en løsning på et problem du opplever og prøver å løse.
Når jeg begynner å jobbe med et nytt prosjekt, konfigurerer jeg alltid en mappe med mapper kalt - Kildefiler , Skjerm og eksport , Inspirasjon og ressurser . Jeg lagrer alt jeg finner på internett til Inspiration-mappen for å kunne bruke det senere for å lage grunnleggende moodboards. Denne mappen kan fylles med alt fra plugins, stikkord eller til og med full case studies fra Behance.
Går lav troskap
5. Whiteboard
Hvis vi vil legge til en ny funksjon eller redesign en prosess, setter vi oss ned, og alle på møtet begynner å skissere ideer på en tavle, papir eller til og med en iPad. Denne handlingen tillater oss å sette alle på laget i designerenes posisjon. Senere slutter vi med to designalternativer for å se hvilken som fungerer best.
Vi prøver alltid å gå gjennom hele opplevelsen og diskutere de fleste av kantsakerne i denne delen av prosessen. Det er veldig viktig å adressere dem nå i motsetning til i designfasen, eller enda verre, under utviklingsdelen. Det er da du kan miste mye tid og energi.
6. Kart ut alle skjermbildene dine (hvilke data en bruker må skrive inn)
Dette er på tide å gå utover whiteboardet og liste ut alle brukerens innspill og historier. Skriv ned hva en bruker skal sette inn i en bestemt skjerm og hvordan en bruker kan oppnå sine ønskede mål.
7. Skriv ned alle mulige tilstander
Fordi alle skjemaer i dashbord, apper eller nettsteder har forskjellige stater, er dette et annet viktig steg du ikke bør glemme.
Mens du designer, må du være sikker på å adressere dem alle. Det er hyggelig å ha skinnende grafer og kule profilbilder i Sketch-filer eller PSD-er. Men mest sannsynlig vil brukerne se motsatt side av appen din. Spesielt når de kommer til produktet ditt. Det er nødvendig å være forberedt. Nedenfor er et eksempel på hvordan vi håndterer tomme stater i en av våre datakomponenter.
8. Forbered ditt første diagram
Alt dette fører til den siste delen av lav troskap. Takket være resultatet av whiteboard-oppgaven, kjenner vi nå alle mulige tilstander, brukerens innspill og mål. For å oppsummere alle samspill jeg lager et diagram og for å være ærlig, har jeg endret stilen med å gjøre dette mange ganger: Går fra Sketch-filer med rasteriserte oppsett til bare rektangler som symboliserer hver side med navnene nedenfor. Når det er sagt, var prosessen alltid smertefull, jeg ender vanligvis på en situasjon der vi ønsker å endre eller legge til noe senere i prosessen. Med disse løsningene er jeg vanligvis tvunget til å gjøre mange flere trinn; som for eksempel endring av posisjoner av linjer, piler og bilder.
Nylig har jeg brukt Camunda Modeler , som ikke er et designverktøy; det er en enkel app for å lage tekniske diagrammer. Det høres rart ut, men denne appen er utviklet for å hjelpe deg med å bygge grunnleggende diagrammer. Viktigst er alt opprettet, helt skalerbart. Du kan enkelt dra og slippe et hvilket som helst punkt, og det vil automatisk lage linjer og piler for deg. Du kan også velge mellom ulike typer poeng som kan være nyttig for å markere når en bruker mottar en epost fra Intercom. Camunda eksporterer til SVG, noe som gjør det enkelt å fargespore spor i Sketch.
Arbeid / Design
9. Moodboard
Jeg kan begynne med opprettelsen av humørbrett, da jeg samler alle bilder til Inspirations-mappen min. Jeg bruker mood boards hovedsakelig for å diskutere mine tanker med kolleger og beskrive noen av de visuelle ideene, før jeg starter med pikselprosessen.
10. Første utkast
Design er alltid en pågående prosess. Du kommer til å iterere mye langs veien til et godt resultat. Med første utkast er også en måte å samle tilbakemelding på. Du trenger ikke å komme til perfekt design for piksler for å begynne å motta tilbakemelding fra dine lagkamerater, klienter eller potensielle brukere. For å få sine første tanker og å starte en diskusjon, pleier jeg å blande skjermbilder fra våre nåværende design. Dette gjør at vi kan begynne å spille med ekte utseende på mindre enn en dag. Du kan gjøre en første enkel prototype for å teste om ting kobler seg godt sammen.
11. Skriv din kopi
Kopier er en av de viktigste aspektene ved brukernes beslutninger, og jeg tar det som en viktig del av designen. Det er ikke noe verre enn en fin design med forvirrende dialoger hvor brukere sliter med å finne det neste trinnet.
12. Første interntest
Med ditt første utkast kan du raskt lage en prototype i Marvel eller Invision . Dette er noe jeg begynte å gjøre nylig, og det viser seg at det er et annet fantastisk valideringsaspekt. Med en prototype kan du nå enkelt sette opp en samtale med 3 eller 4 personer fra teamet ditt og dele prototypekoblingen med dem, og prøv å stille noen få spørsmål mens du tester på dem bestemte strømmer / scenarier.
På denne måten kan du enkelt teste dine spørsmålskompetanse og selvsagt teste designbeslutninger på virkelige brukere uten å bekymre deg om bortkastet ressurser og tid. Jeg pleier å velge folk som ikke er så mye involvert i dashbordutvikling. Prøv også å unngå å se noen som allerede har hatt mulighet til å spille med prototypen før.
13. Etiquette
Vi vet alle hvor vanskelig det er å holde seg ryddig. Hvordan leverer du enda en funksjon. Dette fører vanligvis til en rotete Sketch- eller PSD-fil. Jeg har lært mye om forskjellene mellom å jobbe som en enkelt designer i en oppstart, jobbe i lag eller jobbe med mine digitale produkter.
Når du jobber i et lag, tenk på PSD'en din som om du lager dem for noen andre. Jeg bruker regelen om at hvis du har mer enn 8 lag i en mappe, bør du opprette en ny.
Jeg fant en flott plugin for Sketch, som lagret meg timer mens jeg jobbet på minbrukerpakker: Gi nytt navn til det .
Tips: Sett alt på lerretet. Jeg har alltid slitt med å designe flotte hoder mens jeg var resten av lerretet hvitt. Under designen lærte jeg å sette alt innholdet på plass først - bare spill med layout og typografi. Det er mye enklere å utforme fine detaljer og spille med hele konseptet med innholdet på plass.
14. Lag UI-elementer og begynn å spille med Lego
Jeg er sannsynligvis sen til festen, og dette vil allerede høres utdatert mens jeg skriver det. Grunnen til at vi ikke har gjort noen wireframing på reisen her er enkel. Skisse 39 kommer med noe jeg har funnet utrolige, og det er "former med resizing egenskaper". Dette er noe som gjør utformingen enkelt for alle på laget. Vår Sketch-fil er ren dra-og-slipp nå. Du kan enkelt gi noen av lagkameratene dine et tomt lerret, og de kan skape nesten høyt troverdighetstrykk. Takket være dette er vi i stand til å hoppe over alle wireframing verktøy og starte med nesten ekte utseende piksler.
Dette går også hånd i hånd med at vi faktisk kan konvertere wireframes til ekte design. Enhver PM kan lage en wireframe og så kan jeg lett ta den over og transformere til hi-fidelity.
Eiendeler og levering
Når du er ferdig med å designe og iterere basert på første tilbakemelding, er du ikke ferdig ennå. Nå kommer tiden til å gi designene dine over til ingeniører / devs.
15. Spesifikasjoner
Et hovedmål er å alltid kunne kommunisere mine beslutninger med teamet og kunne redusere vanskeligheter for utviklerne så mye jeg kan for å gi dem de beste ressursene. Det for meg er definitivt den viktigste delen av jobben min som designer.
Siden vi dokumenterte alt samspillet og har alt klart fra begynnelsen av prosessen, er å lage spesifikasjoner et stykke kake. Jeg pleier å skrive spesifikasjoner i Google Dokumenter eller under skjermbildene i Sketch files. Det er fint å håndtere designene dine med forklaringer på alle funksjoner, slik at noen kan gripe filen din i fremtiden.
16. Diagram
Denne teknikken er hyggelig å skrive ut design og diskutere dem med laget. Men i dag tror jeg det er bedre alternativer. Slik som å ha klar den endelige prototypen.
17. Endelig prototype
En av de viktigste tingene for meg er å alltid ha all interaksjon klar i prototype. Jeg ender opp med å ha 3-5 prototyper på vei til den endelige for den lille økten med lagkamerater eller for å vise bestemte strømmer. Jeg pleier å forberede alle statene i Skisse i en tavla og deretter kopiere de tavlene for å få hver stat klar når du eksporterer.
Det er flott å legge til kommentarer til deler av designene dine for å utvide spesifikasjonen mye mer, slik at selv en tekstforfatter lett kan gå og sjekke inn ekte piksler og flyter hvis hver kopi og dialog fungerer etter behov.
18. Quicktime Video> Notater
Når jeg ikke presenterer ting i Hangout til teamet eller en klient, sender jeg en skjermdelsvideo av meg som går gjennom prototypen og forklarer alt det jeg har designet. Det er en fin bekreftelse for meg før en presentasjon som jeg vet svaret på spørsmål og mulige fancy interaksjoner jeg har bestemt meg for å designe. Kan også brukes pent når du arbeider i eksterne lag. Alle har tilgang til å spille hele samhandlingstanken når som helst.
19. Animate
Som en fin endelig touch kan du bruke Etter effekter eller Prinsipp . Det er godt å forklare hvordan du vil at denne eller den skal flytte.
20. Styleguide
Et annet viktig punkt for ingeniører er å vite hvordan ting vil reagere i forskjellige scenarier. Tenk på feiltillatelser for input eller hvor du skal vise feilmeldinger. På samme måte hvordan deaktiverte tilstanden til en sende-knapp vil se, hvor skal du sette en spinner etc.
Det er super enkelt for ingeniører å gå bare gjennom Symbols-tavlen og stilelementene en etter en før de selv begynner å kode alle skjermbilder takket være å ha en Sketch-fil som Lego-blokker.
Endelig testing
Siden vi er ferdige med å overlevere våre design til ingeniører, kan vi fokusere på den siste delen av prosessen - teste våre beslutninger!
21. Inspektør / HotJar
Etter at designene er omgjort til arbeidskode, ikke glem å inkludere din Inspectlet eller HotJar JS snippets. Jeg er alltid spent (eller frustrert) for å se hvordan brukere navigerer gjennom dashbordet eller hva gjør de på porteføljesiden min. Inspectlet er fantastisk i å fange hele brukerens økt. Fungerer bra for større prosjekter også.
Det kommer med enkel "/ side" filtrering som hjelper deg med å se økter av en bestemt funksjon eller flyt.
22. Mixpanel
Mixpanel Fungerer bra for å validere våre mål (de som vi oppretter i begynnelsen av prosessen). Mixpanel bidrar til å se hvor mange brukere som fyller bestemte strømmer. Hvor mange brukere droppet før du opprettet kontoen. Hvor mange mennesker gikk fra hovedlandingssiden for å lagre og til vårt mest verdifulle produkt.
23. Google Analytics
Jeg er ikke i stand til å kode store ting, men i det minste kan jeg jobbe med CSS-filer og med enkel kode. I det siste var jeg interessert i å se hvor brukere klikker og mens jeg ser på Hotjar heatmaps, så jeg har bestemt meg for å sette opp grunnleggende klikktracker i Google Analytics også. Du kan enkelt spore alle brukerens klikk på nettstedet ditt også.
Dette hjelper meg å enkelt kartlegge brukerens oppførsel. For eksempel fant jeg ut at folk brukte toppnavigasjon på nettstedet mitt 5x mer over den uthevede lenken i introtekst. Dessverre teller det ikke klikk fra brukere med AdBlock.
24. Intercom
Da vi ble enige om våre innledende strømmer, snakket vi om en del av strømmen der brukeren mottok en epost fra Intercom . Vårt ansvar her er å sikre at alt kopi og meldingen selv gir mening og er faktisk nyttig for den besøkende. Pass på at e-postene dine veileder brukeren din, og du prøver alltid å gi spesifikke støtteartikler og informasjon om hvordan du fortsetter i strømmen.
De siste få ordene
25. La dribble bak
Fra det jeg har lært og hvordan designet mitt har endret seg i løpet av de siste 4 årene, har jeg kommet til det punktet hvor Dribbble ikke nødvendigvis er stedet du vil lage dine design for. Jeg har alltid tenkt å ha fine piksler med sexy profilbilder, men det er ikke hva ekte brukere trenger og vil bruke.
Her er et eksempel, til venstre ser du noe jeg designet for Dribbble. Til høyre ser du noe jeg designet når jeg brukte litt tid på å se på folk som redigerte profilene sine og skjønte at visjonen min ikke leverte det de trengte.
Du kan få 500 liker for lyse, galne animasjoner av en potet- eller glidende pizza, men det som virkelig er viktig er at brukerne vil finne hvordan man styrer hyppigheten av firmaets e-post eller hvordan man filtrerer resultatene sine.
[- Dette innlegget ble opprinnelig postet på medium , publisert med forfatterens tillatelse. -]