Startups er berygtede for at få en idé fra et koncept til et færdigt produkt hurtigt.
Selvom der helt sikkert er noget at sige for at tage vores tid og gøre dybtgående forskning på hver milepæl, skal vi nogle gange bare få en ide op og køre hurtigst muligt.
Hurtig prototyper i en opstartskultur slims den typiske design- og udviklingsproces for at ramme de høje punkter og retouchere lows efter faktum. Vi kan lære meget af denne metode og anvende den direkte på vores eget arbejde, selvom dette arbejde ikke er i gang.
Mærkeligt nok kræver denne metode ofte mindre at gøre, og meget mere tænkning og planlægning.
Hurtig prototyper har traditionelt henvist til forsøgsforsøg og test af produkter, før de sendes til masseproduktion til den generelle forbruger. Vi vil tilstræbe noget lignende her med denne tilgang, men med ideen om at holde design og udviklingstid til et minimum.
For at dette skal fungere, skal vi have en klar ide om, hvad vi bygger, og hvorfor det bliver bygget. Feature creep kan nemt dræbe dine ideer af ren kompleksitet alene, så vi vil gerne holde tingene minimalt og barebones for vores kerneprodukt.
Fjern din ide, indtil det er rent et produktnavn og en enkelt kernefunktion. (Hvad er problemet, du forsøger at løse?) Så bygg omkring det. Du kan tilføje flere kernefunktioner, hvis det er absolut nødvendigt, men bare ved, at yderligere funktioner vil tilføje endnu mere kompleksitet i din oversigt.
Det er altid bedre at gøre en ting elegant og godt, snarere end at lave fem ting dårligt.
Nu hvor du har en kerne at fokusere på, kan du begynde at tilføje i de mere specifikke funktioner. Forgrening betyder, at disse funktioner ikke er væsentlige for produktets hovedfokus, men tilføjer værdi i deres eksistens. Disse "grene" er add-ons, ekstra tidbits, der tilføjer interesse og til sidst bliver salgspoint, der adskiller dig fra konkurrencen.
Men selvom de rent faktisk tilføjer interesse eller værdi, tilføjer de også på F & U-tid, så husk det. Du vil gerne smide ind nok til at brænde fremtidige design og udvikling, men ikke så mange som at gøre din disposition til at ligne en spindelvæv.
Taler om spider webs, de er en fantastisk måde at visuelt skitsere disse data. I centrum har du dit kerne formål. Tilføjelse af en ekstra ring af funktioner uden for kernen er dine vigtigste ikke-væsentlige funktioner. Hver ring efter det bliver mindre og mindre vigtigt. Ved at bruge denne ide til visuelt at skitsere dit produkt, kan det hjælpe med at organisere det på en mere naturlig måde - med fokus der flyder fra de fleste til de mindst vigtige elementer.
Dit mindsteparable produkt (MVP) er selve essensen af dit produkt. Det og det alene er kernen og hovedfokuset, hvorfra alt andet grene.
Husk at skitsere du sandsynligvis tilbragte dage eller uger på? Ignorer alt andet lige nu, undtagen de ting, der er nødvendige for at gøre dit produkt funktionelt. Dette er virkelig et minimum levedygtigt produkt. Hvad du ender med er ikke kun en opgaveliste for at få den mest funktionalitet basale produkt muligt, men også en klar oversigt over funktioner at fokusere på efter, samt en generel ide om, hvad man kan forvente endnu længere nede vej. Tanken her er at have et kørekort til design og udvikling for det næste år eller mere. Når du nærmer dig slutningen af denne oversigt, vil dit produkt enten være modnet nok til at have en klar retning, som du kan bygge videre på, eller du har set, hvad der fungerede og ikke fungerede fra din oversigt og justeret i overensstemmelse hermed.
Planlæg og skitsere nu, design og udvikle mens du kører - det er nøglen.
Nu er det også tid til at gøre let forskning i, hvilke teknologier og metoder du vil bruge til at uddybe denne ide af din - herunder nogle af de længere ud funktioner. Dette kan kun involvere dig, eller det kan kræve et helt hold at diskutere muligheder og afregne det, der ville være bedst. Det er vigtigt at gøre din forskning efter planlægning af en MVP, så alle fra design til udvikling har en klar ide om, hvad de kan forvente. Ikke kun fokuserer på kernen, men også kigger på de længere udgrene og sørger også for at planlægge for dem. Efter alt er der intet værre end at få seks måneder til udvikling kun for at indse, at ingen planlagde en meget forventet, men ikke-væsentlig, funktion ...
Alle elsker de smukke high fidelity mockups opført på Dribbble eller i designers porteføljer. Det ville være fantastisk at arbejde på noget af den klarhed for alle produkter også. Men normalt tager disse mockups uger, om ikke måneder, arbejde og iteration for at nå det niveau af troskab. Selv da er sommetider disse mockups mere fokuserede på æstetik end nogen data-driven analytik eller brugerdata.
Selvom super høj troskab er naturligvis ud af spørgsmålet, er lave troskabsskitser stadig en mulighed ret? Nå, sandsynligvis ikke. Vis nogle skitser på servietter til en udvikler, og de har ingen anelse om, hvordan dit produkt vil se eller mere vigtigt, hvordan det vil føle sig at bruge.
Medium troskab er generelt det rigtige svar for et hurtigt design og udviklingsmiljø. Par dette med den ovenfor beskrevne tekstoversigt, og begge sider her skal have en god forståelse af UX bag funktionerne.
Medium troskab genererer stadig mockups, men flere granulære elementer bliver bootstrapped ved at bruge eksisterende forsknings- eller brugsmønstre, ikke baseret på brugerdefineret forskning fra tidligere brugeranalyser eller A / B-test.
Den vigtigste note at lave her er, at der ikke er genveje. Ingen kan skimme ud på design eller udviklingstid og få det til at gå ubemærket.
Mens vi kan holde os til almindelige brugssager og implementere populære kodebiblioteker for at løse de problemer, der i dag er de fleste, hvis ikke alle, vil produkterne drage nytte af den ene til den ene opmærksomhed i både design og udvikling.
Hurtige design- og udviklingsmetoder tager den traditionelt mere tilpassede tilgang på disse områder og skærer ting ned for at blive revideret senere. Det forventes, at produkterne bliver revideret for at give den rette opmærksomhed på design, og at optimere eller endda køre med en mere specialudviklet løsning. Så selv om vi kan spare tid og ressourcer i dag ved at tage en hurtigere eller mere fleksibel tilgang til vores arbejdsgang, skal det altid være med forventning om, at vi igen tjekker tingene for at sikre, at vores arbejde er solidt.
Når kernen er færdig, skal du gennemgå og tilpasse. Når næste runde af ikke-væsentlige funktioner er færdige, skal du gennemgå og tilpasse. Generelt kræver dette kun front-end arbejde og ikke en fuldstændig ombygning af back-end-koden. Så det er typisk begrænset til positionering, farve, størrelse eller andre æstetiske attributter af elementer. Udvikling klogt, at revidere her betyder simpelthen at optimere kode for at køre for ydeevne.
At gå med en "tick, tock" stilcyklus til at revidere vores hurtige design- og udviklingsløsninger er den bedste måde at komme i gang med at revidere i min erfaring. Mens udviklingen arbejder på at udrydde det næste sæt af funktioner, kan design gennemgå det sidste parti for at sikre, at alt holder op eller omvendt. På ethvert tidspunkt er design eller udvikling en cyklus forud for den anden, og den anden gennemgår. I løbet af denne proces arbejder begge hold sammen for ikke blot at gennemgå, men også at skubbe den næste batch også.
Udviklingen kan normalt komme videre med at bruge eksisterende biblioteker eller open source-løsninger til at uddanne produktidéer. Men når det kommer til design, er det meget sværere at skære ting tilbage eller outsource dem til eksisterende løsninger.
Design af naturen er mere one-on-one end udvikling, og hvis du er i en nicheindustri, vil det være svært, hvis ikke umuligt at finde lignende brugssager til at basere arbejdet på. Design er et af de områder, hvor jo mere du skærer ud, jo mere kvalitet vil du tabe i sidste ende. Brugeroplevelse og æstetik spiller en meget stor rolle i, hvor godt et produkt "virker".
I sidste ende bør vi finde os med solide produkter, der står højt mod konkurrenter, der beskæftiger sig med de mere traditionelle "langsomme" design- og udviklingsprocesser.
Målet er ikke helt at springe ud på R & D-dele helt, men at arkivere dem væk for at tage sig af senere, når vi har flere data om vores brugere og hvordan de bruger vores produkt.
Hurtig prototyping kan få dig til en MVP og videre i en brøkdel af den tid, det ville tage traditionelt, men pas på, at du ikke forveksler det med skære hjørner.