Startups är berömda för att snabbt få en idé från ett koncept till en slutprodukt .
Medan det verkligen finns något att säga för att vi tar oss tid och gör fördjupad forskning vid varje milstolpe, behöver vi ibland bara få en idé igång så fort som möjligt.
Snabba prototyper i en startkultur slims den typiska design- och utvecklingsprocessen för att slå höga punkter och retuschera lågorna efter det faktum. Vi kan lära oss mycket av denna metod och tillämpa den direkt på vårt eget arbete, även om det inte går att starta det.
Otroligt nog kräver denna metod ofta mindre och mycket mer tänkande och planering.
Snabba prototyper har traditionellt hänvisat till försöksförsök och testning av produkter innan de skickas till massproduktion för den allmänna konsumenten. Vi kommer att sträva efter något liknande här med detta tillvägagångssätt, men med tanken på att hålla design och utvecklingstid till ett minimum.
För att detta ska kunna fungera måste vi ha en klar uppfattning om vad vi bygger och varför det byggs. Feature creep kan enkelt döda dina idéer med ren komplexitet ensam, så vi vill hålla sakerna minimala och barebones för vår kärnprodukt.
Ta bort din idé tills det är rent ett produktnamn och en enda kärnfunktion. (Vad är problemet du försöker lösa?) Bygg sedan upp det. Du kan lägga till fler kärnfunktioner om det är absolut nödvändigt, men bara vet att ytterligare funktioner kommer att lägga till ännu mer komplexitet i din skiss.
Det är alltid bättre att göra en sak elegant och bra, istället för att göra fem saker dåligt.
Nu när du har en kärna att fokusera på, kan du börja lägga till i de mer specifika funktionerna. Förgrening innebär att dessa funktioner inte är avgörande för produktens huvudfokus, men lägger till värde i deras existens. Dessa "grenar" är tillägg, extra prenumerationer som lägger till intresse och så småningom blir försäljningsställen som skiljer dig från tävlingen.
Men samtidigt som de verkligen lägger till intresse eller värde, lägger de också till på FoU-tid också, så håll det i åtanke. Du vill slänga in tillräckligt för att bränna framtida design och utveckling, men inte så många som att göra din kontur ser ut som en spindelväv.
Tala om spindelbanor är de ett fantastiskt sätt att visuellt beskriva dessa data. I mitten har du din kärnändamål. Att lägga till ytterligare en ring av funktioner utanför kärnan är dina viktigaste icke-väsentliga funktioner. Varje ring efter det växer mindre och mindre viktigt. Genom att använda denna idé för att visuellt beskriva din produkt kan det hjälpa till att organisera det på ett mer naturligt sätt - med fokus som strömmar från de flesta till de minst viktiga elementen.
Din minsta livskraftiga produkt (MVP) är själva kärnan i din produkt. Det och det ensamma är kärnan och huvudfokuset från vilket allt annat avgrenar sig.
Kom ihåg att skissera du troligen spenderade dagar eller veckor på? Ignorera allt annat just nu, förutom de saker som behövs för att göra din produkt funktionell. Detta är verkligen en minsta lönsam produkt. Vad du äntligen kommer att sluta med är inte bara en att-göra-lista för att få den mest funktionella basprodukten möjlig utan också en klar skiss av funktioner att fokusera på efter, samt en allmän uppfattning om vad man kan förvänta sig ännu längre ner väg. Tanken här är att ha en färdplan för design och utveckling för nästa år eller mer. När du är i slutet av denna översikt kommer din produkt antingen att ha mognat tillräckligt för att ha en tydlig riktning för att bygga vidare, eller du har sett vad som fungerade och inte fungerade från din skiss och justerades därefter.
Planera och skissera nu, designa och utveckla under körning - det är nyckeln.
Nu är det också dags att göra ljusforskning om vilken teknik och praxis du skulle använda för att krossa denna idé av din - inklusive några av de längre funktionerna. Det här kan bara involvera dig, eller det kan kräva ett helt lag att diskutera alternativ och avgöra vad som är bäst. Det är viktigt att göra din forskning efter att ha planerat en MVP så att alla från design till utveckling har en klar uppfattning om vad man kan förvänta sig. Inte bara fokuserar på kärnan, men tittar också på de längre utgrenarna och ser till att planera för dem också. När allt kommer omkring är det inget värre än att få sex månader till utveckling för att inse att ingen planerade för en mycket förväntad men icke-väsentlig egenskap ...
Alla älskar de vackra high fidelity mockupsna som publiceras på Dribbble eller i designers portföljer. Det skulle vara fantastiskt att arbeta bort något av den klarheten för alla produkter också. Men vanligtvis tar dessa mockups veckor, om inte månader, arbete och iteration för att komma till den nivåen av trohet. Även då är ibland dessa mockups mer fokuserade på estetik än någon datadriven analys eller användardata.
Medan super hög trovärdighet är uppenbarligen ur frågan, är lågtrohetsskisser fortfarande ett alternativ rätt? Tja, troligtvis inte. Visa några skisser på servetter till en utvecklare och de har ingen aning om hur din produkt kommer att se ut eller ännu viktigare hur det kommer att känna att använda.
Medium trohet är i allmänhet det rätta svaret för en snabb design och utvecklingsmiljö. Koppla det här med den ovan beskrivna textraktionen och båda sidorna här borde ha en bra förståelse för UX bakom funktionerna.
Medium trohet genererar fortfarande mockups, men mer granulära element startas upp med hjälp av befintliga forsknings- eller användningsmönster, inte baserat på anpassad forskning av tidigare användaranalys eller A / B-testning.
Den viktigaste anmärkningen att göra här är att det inte finns några genvägar. Ingen kan skymma på design eller utvecklingstid och få det att gå obemärkt.
Medan vi kan hålla fast vid vanliga användningsfall och genomföra populära kodbibliotek för att lösa dagens problem, om inte alla, kommer produkterna att dra nytta av någon på en uppmärksamhet både i design och utveckling.
Snabba design- och utvecklingsmetoder tar det traditionellt mer anpassade tillvägagångssättet på dessa områden och skär ner saker som ska ses över senare. Det förväntas att produkterna är omarbetade för att uppmärksamma designen, och att optimera eller ens springa med en mer anpassad lösning. Så medan vi kan spara tid och resurser idag genom att ta ett snabbare eller agile tillvägagångssätt till vårt arbetsflöde, borde det alltid vara med förväntan att vi återkommer saker efter faktum för att säkerställa att vårt arbete är solidt.
När kärnan är klar ska du återgå och anpassa. När nästa runda av icke-väsentliga funktioner är färdiga, granska och anpassa. I allmänhet kräver detta endast front-end-arbete och inte en fullständig ombyggnad av back-end-koden. Så det är normalt begränsat till positionering, färg, storlek eller andra estetiska attribut av element. Utvecklingskunnigt, ombesörjning här innebär helt enkelt att optimera koden för att köra för prestanda.
Att gå med en "tick, tock" stilcykel för att återgå till våra snabba design- och utvecklingslösningar är det bästa sättet att närma sig revidering i min erfarenhet. Utvecklingen arbetar med att kasta ut nästa sats av funktioner, men designen kan se över det sista batchet för att se till att allt håller sig uppe eller omvänd. Vid varje given tillfälle är antingen design eller utveckling en cykel före den andra, och den andra granskar. Under denna process arbetar båda lagen tillsammans för att inte bara granska, men också för att driva ut nästa sats också.
Utvecklingen kan vanligtvis komma ifrån med att använda befintliga bibliotek eller lösningar med öppen källkod för att utarbeta produktidéer. Men när det gäller design är det mycket svårare att skära saker tillbaka eller lägga ut dem till befintliga lösningar.
Design av natur är mer en-mot-en än utveckling och om du är i en nischindustri blir det svårt, om inte omöjligt, att hitta liknande användarfall för att bygga upp arbetet. Design är ett av de områden där ju mer du skär ut, desto mer kvalitet kommer du att förlora i slutet. Användarupplevelse och estetik spelar en mycket stor roll i hur bra en produkt "fungerar".
I slutändan bör vi hitta oss med solida produkter som står höga mot konkurrenter som engagerar sig i de mer traditionella "långsamma" design- och utvecklingsprocesserna.
Målet är inte att helt och hållet hoppa över delar av FoU, men att lämna in dem för att ta hand om senare när vi har mer information om våra användare och hur de använder vår produkt.
Snabba prototyper kan få dig till en MVP och bortom på en bråkdel av tiden som det skulle ta traditionellt, men var försiktig så att du inte förvirrar det med skärsnivar.