Startups er beryktede for å få en ide fra et konsept til et ferdigstilt produkt raskt.
Mens det er sikkert noe å si for å ta vår tid og gjøre grundig forskning på hver milepæl, noen ganger trenger vi bare å få en ide oppe og løpe så snart som mulig.
Raskt prototyping i en oppstartskultur slims den typiske design- og utviklingsprosessen for å slå høye poeng og retusere lavt etter faktumet. Vi kan lære mye av denne metoden og bruke den direkte på vårt eget arbeid, selv om dette arbeidet ikke er i oppstart.
Merkelig nok, krever denne metoden ofte mindre å gjøre, og mye mer tenkning og planlegging.
Raskt prototyping har tradisjonelt referert til prøvekjøringen og testingen av produkter før de sendes til masseproduksjon for den generelle forbrukeren. Vi skal sikte på noe lignende her med denne tilnærmingen, men med ideen om å holde design og utviklingstid til et minimum.
For at dette skal fungere, må vi ha en klar ide om hva vi bygger, og hvorfor det blir bygget. Feature kryp kan enkelt drepe dine ideer av ren kompleksitet alene, så vi vil holde ting minimal og barebones for vårt kjernevareprodukt.
Strip bort ideen din til det er rent et produktnavn og en enkeltkjernefunksjon. (Hva er problemet du prøver å løse?) Bygg deretter rundt det. Du kan legge til flere kjernefunksjoner hvis det er absolutt nødvendig, men bare vite at flere funksjoner vil gi enda mer kompleksitet til oversikten.
Det er alltid bedre å gjøre en ting elegant og bra, i stedet for å gjøre fem ting dårlig.
Nå som du har en kjerne å fokusere på, kan du begynne å legge til i de mer spesifikke funksjonene. Forgrening betyr at disse funksjonene ikke er avgjørende for produktets hovedfokus, men gir verdi i deres eksistens. Disse "grenene" er tillegg, ekstra tidbiter som legger til interesse og til slutt blir salgspunkter som skiller deg fra konkurransen.
Men mens de sikkert legger til interesse eller verdi, legger de også på FoU-tid også, så hold det i bakhodet. Du vil ha kastet inn nok til å brenne framtidig design og utvikling, men ikke så mange som å få oversikten til å se ut som en edderkoppnett.
Når det gjelder spindelbaner, er de en fantastisk måte å visuelt skissere disse dataene på. I sentrum har du kjernens formål. Hvis du legger til en ekstra ring av funksjoner utenfor kjernen, er de viktigste ikke-essensielle funksjonene. Hver ring etter det blir mindre og mindre viktig. Ved å bruke denne ideen til å visuelt skissere produktet, kan du organisere det på en mer naturlig måte - med fokus som flyter fra mest til minst viktige elementer.
Min minste levedyktige produkt (MVP) er selve essensen av produktet ditt. Det og det alene er kjernen og hovedfokuset som alt annet grener av.
Husk at skissere du sannsynligvis tilbrakt dager eller uker på? Ignorer alt annet akkurat nå unntatt de tingene som trengs for å gjøre produktet ditt funksjonelt. Dette er virkelig et minimum levedyktig produkt. Det du ender med er ikke bare en oppgaveliste for å få det mest funksjonelle basale produktet, men også en klar oversikt over funksjoner som skal fokusere på etter, samt en generell ide om hva du kan forvente enda lenger ned vei. Tanken her er å ha et veikart for design og utvikling for det neste året eller mer. Når du er nær slutten av denne oversikten, vil produktet enten ha blitt modnet nok til å ha en klar retning som du skal bygge videre på, eller du har sett hva som gjorde og ikke fungerte fra oversikten og justert tilsvarende.
Planlegg og skisser nå, design og utvikle mens du kjører - det er nøkkelen.
Nå er det også på tide å gjøre lysforskning om hvilke teknologier og praksis du vil bruke til å utrydde denne ideen din - inkludert noen av de lengre funksjonene. Dette kan bare involvere deg, eller det kan kreve et helt lag å diskutere alternativer og avgjøre hva som ville være best. Det er viktig å gjøre din forskning etter å ha planlagt en MVP, slik at alle fra design til utvikling har en klar ide om hva du kan forvente. Ikke bare fokuserer på kjernen, men ser også på de lenger utgrenene og sørger for å planlegge for dem også. Tross alt er det ingenting verre enn å få seks måneder til utvikling bare for å innse at ingen har planlagt for en forventet, men ikke-essensiell, funksjon ...
Alle elsker de vakre high fidelity mockupene som er lagt ut på Dribbble eller i designers porteføljer. Det ville være fantastisk å jobbe med noe av den klarheten for alle produktene også. Men de fleste mockups tar vanligvis uker, om ikke måneder, med arbeid og iterasjon for å komme til det nivået av troskap. Selv da, noen ganger er disse mockups mer fokusert på estetikk enn noen data-drevet analyse eller brukerdata.
Selv om super høy troskap er åpenbart ute av spørsmålet, er lavt troverdighet fortsatt et alternativ? Vel, sannsynligvis ikke. Vis noen skisser på servietter til en utvikler, og de har ingen anelse om hvordan produktet vil se ut eller enda viktigere hvordan det vil føle seg å bruke.
Medium trohet er generelt det rette svaret for et raskt design og utviklingsmiljø. Pair dette med teksten skissert ovenfor og begge sider her skal ha en god forståelse av UX bak funksjoner.
Medium troskap genererer fortsatt mockups, men flere granulære elementer blir bootstrapped ved å bruke eksisterende forsknings- eller bruksmønstre, ikke basert på tilpasset forskning av tidligere brukeranalyser eller A / B-testing.
Det viktigste notatet å lage her er at det ikke er noen snarveier. Ingen kan skimp på design eller utviklingstid og få det til å gå ubemerket.
Selv om vi kan holde fast i vanlige bruksområder og implementere populære kodebiblioteker for å løse dagens problemer, hvis ikke alle, kan de ha nytte av en og en oppmerksomhet i både design og utvikling.
Raske design- og utviklingsmetoder tar den tradisjonelt mer tilpassede tilnærmingen i disse områdene og skjærer ting ned for å bli revidert senere. Det forventes at produktene blir revidert for å gi riktig oppmerksomhet til design, og å optimalisere eller til og med kjøre med en mer tilpasset løsning. Så mens vi kan spare tid og ressurser i dag ved å ta en raskere eller smidig tilnærming til arbeidsflyten vår, bør det alltid være med forventning om at vi går tilbake til ting etter at vi har et solidt arbeid.
Når kjernen er fullført, besøk og tilpass. Når neste runde av ikke-essensielle funksjoner er fullført, besøk og tilpass. Vanligvis krever dette bare front-end arbeid og ikke en fullstendig ombygging av bakre endekoden. Så det er vanligvis begrenset til posisjonering, farge, størrelse eller andre estetiske attributter av elementer. Utviklingsvis, revisjon her betyr bare å optimalisere kode for å kjøre for ytelse.
Å gå med en "tick, tock" -syklus for å revidere våre raske design- og utviklingsløsninger er den beste måten å nærme seg revidere i min erfaring. Mens utviklingen jobber med å kutte ut neste sats av funksjoner, kan design gjennomgå siste sats for å sikre at alt holder opp eller omvendt. På et gitt tidspunkt er enten design eller utvikling en syklus foran den andre, og den andre vurderer. I løpet av denne prosessen arbeider begge lagene sammen for ikke bare å vurdere, men også for å presse ut neste batch også.
Utvikling kan vanligvis gå videre med å bruke eksisterende biblioteker eller åpen kildekode løsninger for å kutte ut produktideer. Men når det gjelder design, er det mye vanskeligere å kutte ting tilbake eller outsource dem til eksisterende løsninger.
Design av natur er mer en-mot-en enn utvikling, og hvis du er i en nisjeindustri, vil det være vanskelig, om ikke umulig å finne lignende brukstilfeller som baserer seg på arbeidet. Design er et av de områdene hvor jo mer du kutter ut, jo mer kvalitet kommer du til å tape i slutten. Brukeropplevelse og estetikk spiller en svært stor rolle i hvor godt et produkt "virker".
Til slutt bør vi finne oss med solide produkter som står høye mot konkurrenter som engasjert seg i de mer tradisjonelle "sakte" design- og utviklingsprosessene.
Målet er ikke å hoppe over deler av FoU helt, men å sende dem bort for å ta vare på senere når vi har mer data om våre brukere og hvordan de bruker produktet vårt .
Rapid prototyping kan få deg til en MVP og utover i en brøkdel av tiden det ville ta tradisjonelt, men pass på at du ikke forveksler det med kuttekroner.