Det är ingen hemlighet att den smidiga utvecklingsprocessen har skett genom utvecklingsvärlden i flera år nu, och svävar undan den äldre, klumpiga vattenfallsutvecklingsmetoden. För att vara rättvis, om det var smidigt eller något annat, hade vattenfallet verkligen kommit, eftersom dess riskavvikande top-down-tillvägagångssätt bara inte kan hålla i takt med dagens marknadsplats.
Medan liknande förändringar sker i designvärlden, bör den smidiga designprocessen nödvändigtvis se ut och känna sig lite annorlunda än den smidiga utvecklingen. de är trots allt olika discipliner. Låt oss först ha en djupare titt på vilken smidig utveckling, och sedan på några bra sätt att anpassa processen till designvärlden.
En snabb primer på Agile Development
Agile Manifesto betonar människor och interaktioner över processer och verktyg. I praktiken innebär det att man kommunicerar ofta både inom lag och med kunden, och gör saker som dagliga skrummormöten så att hela laget kan hålla sig in på medlemmarnas aktiviteter. Detta skapar en konsekvent återkopplingsslinga som gör det möjligt för lag att justera baserat på vad kunder, beta-testare och marknaden säger till dem, samtidigt som de ofta kontrollerar att deras arbete är funktionellt i den miljö där den i slutändan kommer att leva.
Mer än någonting understryker agile processen produktion av leveranser på tid och på budget, inte perfektion, eftersom produkterna alltid kan anpassas till vägen. Det här tar oftast formen av iterationer, korta och intensiva produktionsperioder med mindre, mer uppnåliga mål som bygger på ytterligare iterationer på vägen.
Så vilka steg kan du vidta för att anpassa liknande mentaliteter till en designinställning? Låt oss ta en titt.
Ändra din relation med dina kunder
Den traditionella designprocessen spelar direkt in i en gemensam önskan bland designers för att presentera endast de mest perfekta produkterna till kunderna. Detta börjar i förslaget och forskningsfasen med alltför utarbetade PSD-mockups och fortsätter till den slutliga godkännandefasen. Men för de mest komplexa projekten, är det verkligen inte meningsfullt att designa i veckor om inte månader i abstrakt, helt utan kundinmatning. Som vi vet alltför väl får kunderna en mycket tydligare förståelse för vad de letar efter när en webbplats kommer samman. Dessutom har efterfrågan på marknaden förändrats snabbare än konstruktörer kan producera. Detta kan vara frustrerande när man arbetar inom ett paradigm där omdirigering är både arbetskraft och tidskrävande.
Att anta ett smidigt tillvägagångssätt för looping kunder i varje fas av processen och producera en konstant ström av leveranser kan hjälpa till att åtgärda detta, eftersom det tillåter kunder att leka med mönster när de går. Det gör det också möjligt för dem att få en bättre förståelse för hur den realiserade visionen kommer att fungera i ett verkligt världssammanhang. Ju mer regelbundna kommunikationen är desto lägre är risken för överraskningar som uppstår på vägen, desto bättre kan ett lag anpassa sig till förändrade krav på vägen, snarare än att behöva återfå sina steg.
Kort sagt: Gör kunden en medlem av ditt lag.
Samlar ofta arbete över lag
I utvecklingsvärlden är integrationen av arbete inom och mellan lag en avgörande del av något projekt. Detta är ju mer sant när lag växer från tiotusentals till de största organisationerna. Men integrationen i vattenfallmetoden förekommer i sällsynta intervaller, vilket gör det svårare för devs att hitta buggar i en enorm mängd kod. Det leder också till mycket backtracking och skeppsförseningar.
Inte så med den smidiga metoden för kontinuerlig integration, som har devs integrering av kod på en gång om inte tre gånger dagligen. Kontinuerlig integration tar verkligen det oönskade mysteriet ur integration, vilket gör det möjligt för devs att fånga fel när de uppstår och antingen fixa dem omedelbart eller lägga dem i eftersläpningen för nästa iteration av projektet. Det passar också snyggt med det smidiga konceptet av privilegieringsinteraktioner över processer, eftersom devs över lag måste kommunicera ofta för att identifiera och åtgärda sådana typer av fel.
Designers kan dra nytta av en liknande mentalitet, oavsett om det innebär att man gör en daglig incheckning med andra teammedlemmar på daglig basis eller kommunicerar oftare med devs för att avgöra vad som är tekniskt möjligt att genomföra innan man går ner på en spännande men knepig designväg. Cross-team kommunikation och sammanställning av arbete kommer också att hålla designers fokuserade på att designa när design är nödvändig, snarare än överplanering eller till och med implementera designarbete som inte synkroniseras med vad andra team gör.
Test, test, test? Hela tiden
På en liknande men väldigt annorlunda notering är frekvent testning en viktig del av att hålla iterationer på rätt spår. Genom att testa? Jag menar att jag ser bortom integrationen till en designfunktionalitet både på mikro och makronivå genom att utveckla en problemlösande synvinkel. I smidig utveckling bryter devs större problem ner till mindre som bättre kan hanteras inom ramen för snabba iterationer. Genom att testa detta arbete kan de identifiera problem som ska åtgärdas antingen omedelbart eller i nästa iteration. Detta håller devs på spår och på tid, förhindrar att förlamning uppstår när alltför mycket närmar sig på en gång.
På så sätt kan frekvent testning och problemlösnings mentalitet inte bara hålla konstruktionsprocessen på rätt spår utan även bränslekreativitet, eftersom det förhindrar att konstruktörer blir alltför fastna på det största problemet med alla: en webbplats ska se ut och känna. Genom att fokusera på mindre problem kan designers omfamna en mer framträdande kreativ process och upptäcka deras syn när de går.
Allt detta sagt, värdet av att zooma tillbaka till makronivå kan inte ignoreras, annars kommer mönster att bli för ojämn. Som en fin balans mellan agileens mindre problemlösande fokus och vattenfalls mer holistiska syn är det värt att ägna åtskilliga iterationer för att lösa problem i samband med den större bilden och också bara ta sikten på konsistensens skull.
Kortfattat
När du verkligen tänker på det är smidig design helt enkelt tillämpningen av vissa smidiga utvecklingsprinciper för designprocessen. Eftersom varje designer och designteam är annorlunda är du bäst att välja de metoder som fungerar för dig och anpassa dem när du går. Det verkar trots allt som det smidiga att göra.