Agile Design begrijpen en waarom het belangrijk is
Het is geen geheim dat het agile ontwikkelingsproces al enkele jaren door de ontwikkelingswereld raast en de oudere, onhandige watervalontwikkelingsmethode opzij schuift. Om eerlijk te zijn, of het nu behendig was of iets anders, waterval heeft het echt laten komen, omdat de risicomijdende, top-down benadering gewoon niet kan voldoen aan de eisen van de hedendaagse markt.
Hoewel vergelijkbare veranderingen plaatsvinden in de ontwerpwereld, moet het agile ontwerpproces er noodzakelijkerwijs een beetje anders uitzien en aanvoelen dan agile ontwikkeling; het zijn immers verschillende disciplines. Laten we eerst dieper kijken naar wat agile ontwikkeling is, en vervolgens naar een paar geweldige manieren om het proces aan te passen aan de ontwerpwereld.
Een snelle inleiding op Agile Development
Het Agile Manifest legt de nadruk op mensen en interacties boven processen en tools. In de praktijk betekent dit dat er regelmatig moet worden gecommuniceerd, zowel binnen teams als met de klant, en dat er bijvoorbeeld dagelijkse scrum-vergaderingen worden gehouden, zodat het hele team op de hoogte kan blijven van de activiteiten van zijn leden. Dit zorgt voor de consistente feedbacklus die teams in staat stelt zich aan te passen op basis van wat klanten, bètatesters en de markt hen vertellen, terwijl ze ook regelmatig controleren of hun werk functioneel is in de omgeving waarin het uiteindelijk zal leven.
Meer dan wat dan ook benadrukt het agile proces de productie van op tijd en binnen budget leverbare producten, niet van perfectie, omdat producten altijd op de weg kunnen worden aangepast. Dit neemt meestal de vorm aan van iteraties, korte, intensieve productieperioden met kleinere, beter haalbare doelen die verdere iteraties in de weg inbouwen.
Dus welke stappen kun je nemen om vergelijkbare mentaliteit aan te passen voor een ontwerpomgeving? Laten we kijken.
Verander uw relatie met uw klanten
Het traditionele ontwerpproces speelt in op een gemeenschappelijke wens van ontwerpers om alleen de meest perfecte producten aan klanten te presenteren. Dit begint in de voorstel- en onderzoeksfase met overdreven uitgebreide PSD-mockups en loopt door tot de laatste goedkeuringsfase. Maar voor de meest complexe projecten is het echt niet logisch om weken of zelfs maanden abstract te ontwerpen, zonder enige input van klanten. Zoals we maar al te goed weten, krijgen klanten vaak een veel duidelijker begrip van wat ze zoeken als een site samenkomt. Bovendien verandert de marktvraag sneller dan ontwerpers kunnen produceren. Dit kan frustrerend zijn als u werkt binnen een paradigma waarin herroutering zowel arbeidsintensief als tijdrovend is.
Door een agile benadering te hanteren door klanten in elke fase van het proces te lussen en een constante stroom van producten te produceren, kan dit worden verholpen, omdat klanten hiermee kunnen spelen met ontwerpen terwijl ze bezig zijn. Het stelt hen ook in staat om beter te begrijpen hoe de gerealiseerde visie zal werken in een echte wereldcontext. Hoe regelmatiger de communicatie, hoe kleiner de kans op verrassingen die zich onderweg voordoen, hoe beter een team zich kan aanpassen aan veranderende eisen onderweg, in plaats van dat het hun stappen opnieuw moet volgen.
Kortom: maak de klant lid van uw team.
Compileer regelmatig werk tussen teams
In de ontwikkelingswereld is de integratie van intra- en interteamwerk een cruciaal onderdeel van elk project. Dit geldt des te meer naarmate de teams groeien van tientallen naar duizenden bij de grootste organisaties. Maar integratie in de watervalmethode gebeurt met onregelmatige tussenpozen, waardoor het voor ontwikkelaars des te moeilijker wordt om bugs in een enorme hoeveelheid code te vinden. Het leidt ook tot veel backtracking en vertragingen bij het schip.
Niet zo met de agile methode van continue integratie, die devs heeft die code op een eenmalige, zo niet driemaal dagelijkse basis integreren. Continue integratie haalt echt het ongewenste mysterie uit de integratie, waardoor ontwikkelaars bugs kunnen opvangen zodra ze zich voordoen en deze ofwel onmiddellijk repareren of toevoegen aan de backlog voor de volgende iteratie van het project. Het past ook mooi in het agile concept van het bevoordelen van interacties boven processen, omdat ontwikkelaars tussen teams regelmatig moeten communiceren om dit soort fouten te identificeren en op te lossen.
Ontwerpers kunnen profiteren van een vergelijkbare mentaliteit, of dat nu betekent dat ze dagelijks eenvoudig met andere teamleden moeten inchecken, of dat ze vaker met ontwikkelaars moeten communiceren om te bepalen wat technisch mogelijk is om te implementeren voordat ze een spannende maar lastige ontwerproute volgen. Communicatie tussen teams en het samenstellen van werk zal ontwerpers ook gefocust houden op ontwerpen wanneer ontwerp nodig is, in plaats van ontwerpplanning te overplannen of zelfs te implementeren dat niet synchroon loopt met wat andere teams doen.
Test, Test, Test ... Altijd
Op een vergelijkbare maar cruciaal andere manier is frequent testen een belangrijk onderdeel om iteraties op schema te houden. Met "testen" bedoel ik verder kijken dan integratie naar de functionaliteit van een ontwerp, zowel op micro- als op macroniveau, door een probleemoplossend standpunt te ontwikkelen. Bij agile ontwikkeling splitsen ontwikkelaars grotere problemen op in kleinere die beter kunnen worden aangepakt in het kader van snelle iteraties. Door dit werk te testen, kunnen ze vervolgens problemen identificeren die onmiddellijk of in de volgende iteratie moeten worden aangepakt. Dit houdt ontwikkelaars op schema en op tijd, waardoor wordt voorkomen dat er verlamming optreedt wanneer er te veel tegelijk wordt benaderd.
Op deze manier kunnen frequente tests en een probleemoplossende mentaliteit niet alleen het ontwerpproces op het goede spoor houden, maar ook de creativiteit stimuleren, omdat het voorkomt dat ontwerpers te verstrikt raken in het grootste probleem: weten vanaf het begin precies hoe een site moet er uitzien en aanvoelen. Door zich te concentreren op kleinere problemen, kunnen ontwerpers een meer opkomend creatief proces omarmen en hun visie onderweg ontdekken.
Dat gezegd hebbende, de waarde van terugzoomen tot op macroniveau kan niet worden genegeerd, anders worden ontwerpen te onsamenhangend. Als een mooie balans tussen de kleinere probleemoplossende focus van agile en de meer holistische visie van waterval, is het de moeite waard om verschillende iteraties te besteden aan het oplossen van problemen in de context van het grotere geheel, en ook om het standpunt in te nemen omwille van de consistentie.
In het kort
Als je er echt over nadenkt, is agile design simpelweg de toepassing van bepaalde agile ontwikkelingsprincipes op het ontwerpproces. Omdat elke ontwerper en elk ontwerpteam anders is, kunt u het beste de methoden kiezen die voor u werken en deze onderweg aanpassen. Dat lijkt tenslotte het behendige ding om te doen.
