Startups zijn berucht om het snel overbrengen van een idee van een concept naar een gefinaliseerd product .
Hoewel er zeker iets te zeggen valt om onze tijd te nemen en diepgaand onderzoek te doen bij elke mijlpaal, moeten we soms zo snel mogelijk een idee in gebruik nemen.
Snelle prototyping in een startup-cultuur verlaagt het typische ontwerp- en ontwikkelingsproces om de hoogtepunten te bereiken en de dieptepunten na te bootsen. We kunnen veel leren van deze methodiek en deze direct toepassen op ons eigen werk, zelfs als dat werk niet voor een startup is.
Vreemd genoeg vereist deze methodologie vaak minder doen en veel meer denken en plannen.
Rapid Prototyping verwijst van oudsher naar het testen en testen van producten voordat ze naar de massaproductie worden gestuurd voor de algemene consument. Met deze aanpak gaan we naar iets soortgelijks, maar met het idee om ontwerp- en ontwikkelingstijd tot een minimum te beperken.
Om dit te laten werken, moeten we een duidelijk idee hebben van wat we bouwen en waarom het wordt gebouwd. Feature creep kan eenvoudig uw ideeën doden door de enorme complexiteit alleen, dus we willen de dingen minimaal en barebones voor ons kernproduct houden.
Verdoe je idee tot het puur een productnaam en een kernelement is. (Wat is het probleem dat u probeert op te lossen?) Bouw daar vervolgens omheen. Je kunt meer kernfuncties toevoegen als dat absoluut noodzakelijk is, maar weet gewoon dat extra functies je overzicht nog complexer maken.
Het is altijd beter om één ding elegant en goed te doen, in plaats van vijf dingen slecht te doen.
Nu u een kern hebt waarop u kunt focussen, kunt u beginnen met het toevoegen van de meer specifieke functies. Vertakken betekent dat deze functies niet essentieel zijn voor de hoofdfocus van het product, maar waarde toevoegen in hun bestaan. Deze "filialen" zijn add-ons, extra kanttekeningen die interesse toevoegen en uiteindelijk verkooppunten worden die je van de concurrentie scheiden.
Maar terwijl ze zeker interesse of waarde toevoegen, voegen ze ook R & D-tijd toe, dus houd daar rekening mee. Je wilt genoeg inleveren om het toekomstige ontwerp en de ontwikkeling van brandstof te voorzien, maar niet zozeer dat je overzicht er uit ziet als een spinnenweb.
Spreken van spinnenwebben, ze zijn een fantastische manier om deze gegevens visueel te schetsen. In het centrum heb je je kerndoel. Het toevoegen van een extra ring met functies buiten de kern zijn uw belangrijkste niet-essentiële functies. Elke ring daarna wordt steeds minder belangrijk. Als u dit idee gebruikt om uw product visueel te schetsen, kunt u het op een meer natuurlijke manier ordenen, waarbij de focus van de meeste naar minst belangrijke elementen gaat.
Uw minimale levensvatbare product (MVP) is de essentie van uw product. Alleen het is de kern en belangrijkste focus van waaruit al het andere vertakt.
Weet je nog die schets waar je waarschijnlijk dagen of weken aan hebt besteed? Negeer al het andere nu, behalve de dingen die nodig zijn om uw product functioneel te maken. Dit is echt een minimaal levensvatbaar product. Waar u uiteindelijk mee komt, is niet alleen een takenlijst om het meest functioneel basisproduct mogelijk te krijgen, maar ook een duidelijke schets van functies waar u zich later op kunt concentreren, evenals een algemeen idee van wat u nog verder kunt verwachten. weg. Het idee hier is om een routekaart te hebben voor ontwerp en ontwikkeling voor het volgende jaar of meer. Tegen de tijd dat u aan het einde van deze schets komt, is uw product ofwel volwassen genoeg om een duidelijke richting te hebben om meer op te bouwen, of heeft u gezien wat wel en wat niet uit uw overzicht werkte en dienovereenkomstig aangepast.
Plan en schets nu, ontwerp en ontwikkel tijdens het hardlopen - dat is de sleutel.
Nu is het ook het moment om licht onderzoek te doen naar welke technologieën en praktijken u zou gebruiken om dit idee van u uit te werken - inclusief enkele van de verder weg gelegen functies. Dit kan alleen betrekking hebben op jou, of het kan een heel team vereisen om opties te bespreken en te bepalen wat het beste zou zijn. Het is belangrijk om je onderzoek te doen na het plannen van een MVP, zodat iedereen van ontwerp tot ontwikkeling een duidelijk idee heeft van wat hij kan verwachten. Niet alleen focussen op de kern, maar ook kijken naar de verder gelegen vestigingen en ervoor zorgen dat die ook worden gepland. Er is tenslotte niets erger dan zes maanden in ontwikkeling te zijn, alleen om te realiseren dat niemand gepland was voor een langverwachte, maar niet-essentiële eigenschap ...
Iedereen houdt van de prachtige high fidelity-modellen die op Dribbble of in portefeuilles van ontwerpers zijn geplaatst. Het zou geweldig zijn om iets van die helderheid ook voor alle producten uit te werken. Maar meestal nemen die mockups weken, zo niet maanden, van werk en iteratie om dat niveau van trouw te bereiken. Zelfs dan zijn die modellen soms meer gericht op esthetiek dan op gegevensgestuurde analyses of gebruikersgegevens.
Hoewel supersnelle trouw natuurlijk niet mogelijk is, zijn low-fidelity-schetsen nog steeds een optie, toch? Nou ja, waarschijnlijk niet. Laat een paar schetsen op servetten zien aan een ontwikkelaar en ze zullen geen idee hebben hoe uw product eruit ziet of, nog belangrijker, hoe het voelt om te gebruiken.
Mediumfidelity is over het algemeen het juiste antwoord voor een snelle ontwerp- en ontwikkelomgeving. Koppel dit met de hierboven gegenereerde tekstopmaak en beide zijden moeten hier een goed begrip hebben van de UX achter functies.
Medium-getrouwheid genereert nog steeds mockups, maar meer korrelige elementen worden bootstrapped door gebruik te maken van bestaand onderzoek of gebruikspatronen, niet op basis van aangepast onderzoek van eerdere gebruikersanalyses of A / B-testen.
De belangrijkste opmerking die u hier moet maken, is dat er geen snelkoppelingen zijn. Niemand kan de ontwerp- of ontwikkeltijd beknibbelen en onopgemerkt laten.
Hoewel we ons kunnen houden aan gangbare use-cases en populaire codebibliotheken kunnen implementeren om de problemen van vandaag op te lossen, zullen de meeste, zo niet alle, producten voordeel hebben van één op één aandacht in zowel ontwerp als ontwikkeling.
Snelle ontwerp- en ontwikkelingsmethodologieën nemen de traditioneel meer op maat gemaakte aanpak in deze gebieden en snijden de zaken terug om later te worden herzien. Er wordt verwacht dat producten opnieuw worden bekeken om de juiste aandacht te geven aan het ontwerp en om deze te optimaliseren of zelfs uit te voeren met een meer op maat ontwikkelde oplossing. Dus terwijl we vandaag op tijd en middelen kunnen besparen door een snellere of agile benadering van onze workflow te nemen, moet het altijd met de verwachting zijn dat we de dingen na het feit opnieuw bekijken om ervoor te zorgen dat ons werk solide is.
Zodra de kern compleet is, opnieuw bezoeken en aanpassen. Wanneer de volgende ronde met niet-essentiële functies is voltooid, kunt u opnieuw bezoeken en aanpassen. Over het algemeen vereist dit alleen front-end werk en niet een volledige herontwikkeling van de back-endcode. Dus het is meestal beperkt tot de positionering, kleur, grootte of andere esthetische kenmerken van elementen. Wat de ontwikkeling betreft, betekent het opnieuw bezoeken hier eenvoudigweg het optimaliseren van de code om te presteren.
Gaan met een "tick, tock" -stijlcyclus voor het opnieuw bezoeken van onze snelle ontwerp- en ontwikkelingsoplossingen, is de beste manier om revisiting in mijn ervaring te benaderen. Terwijl de ontwikkeling werkt aan het invullen van de volgende reeks functies, kan het ontwerp de laatste batch beoordelen om ervoor te zorgen dat alles recht blijft staan of omgekeerd. Op een gegeven moment loopt ontwerp of ontwikkeling de ene cyclus voor op de andere en de andere is aan het herzien. Tijdens dit proces werken beide teams samen, niet alleen om te beoordelen, maar ook om de volgende batch uit te zetten.
Ontwikkeling kan meestal rondkomen door bestaande bibliotheken of open source-oplossingen te gebruiken om productideeën vorm te geven. Maar als het gaat om ontwerp, is het veel moeilijker om dingen terug te schroeven of ze uit te besteden aan bestaande oplossingen.
Design van nature is meer één op één dan ontwikkeling en als je in een niche-industrie zit, zal het moeilijk, zo niet onmogelijk, zijn om vergelijkbare use-cases te vinden om op te baseren. Design is een van die gebieden waar hoe meer je knipt, hoe meer kwaliteit je uiteindelijk gaat verliezen. Gebruikerservaring en esthetiek spelen een zeer grote rol in hoe goed een product "werkt".
Uiteindelijk moeten we onszelf bevinden met solide producten die goed staan tegenover concurrenten die zich bezighouden met de meer traditionele "langzame" ontwerp- en ontwikkelingsprocessen.
Het doel is niet om delen van R & D volledig over te slaan, maar ze weg te zetten om later te zorgen als we eenmaal meer gegevens hebben over onze gebruikers en hoe ze ons product gebruiken.
Rapid prototyping kan u in een fractie van de tijd van oudsher naar een MVP en verder brengen, maar zorg ervoor dat u dit niet verwart met de nieuwste invalshoeken.