Forstå smidig design og hvorfor det er viktig
Det er ingen hemmelighet at den smidige utviklingsprosessen har såret gjennom utviklingsverdenen i flere år nå, og lagt den eldre, klunkere utviklingsmetoden til side til side. For å være rettferdig, enten det var smidig eller noe annet, hadde fossen virkelig kommet, da den risikoaverse, topp-ned tilnærmingen bare ikke kan holde tritt med kravene fra dagens marked.
Mens lignende forandringer skjer i designverdenen, bør den smidige designprosessen nødvendigvis se og føles litt annerledes enn smidig utvikling; de er tross alt forskjellige fagområder. La oss se nærmere på hva smidig utvikling er, og deretter på noen få gode måter å tilpasse prosessen til designverdenen.
En rask grunning om smidig utvikling
Agile Manifesto legger vekt på mennesker og interaksjoner over prosesser og verktøy. I praksis betyr dette å kommunisere ofte både i team og med kunden, i tillegg til å gjøre ting som daglige skrummøter, slik at hele teamet kan holde seg fast i aktivitetene til medlemmene. Dette skaper en konsistent tilbakemeldingssløyfe som gjør det mulig for team å tilpasse seg basert på hva kunder, betatestere og markedet forteller dem, mens de også sjekker ofte for å sikre at deres arbeid er funksjonelt i miljøet der det til slutt vil leve.
Mer enn noe annet, fremhever den smidige prosessen produksjonen av levering til rett tid og på budsjettet, ikke perfeksjon, ettersom produkter alltid kan finjusteres nede. Dette har stort sett form av iterasjoner, korte, intense produksjonsperioder med mindre og mer oppnåelige mål som bygger inn ytterligere iterasjoner nedover veien.
Så hvilke grep kan du ta for å tilpasse lignende mentaliteter til en designmiljø? La oss ta en titt.
Endre forholdet til kundene dine
Den tradisjonelle designprosessen spiller rett inn i et felles ønske blant designere om å presentere bare de mest perfekte produktene for kundene. Dette begynner i forslaget og forskningsfasen med altfor detaljerte PSD-mockups og fortsetter til den endelige godkjenningsfasen. Men for de mest komplekse prosjektene er det virkelig ikke fornuftig å designe i flere uker om ikke måneder i det abstrakte, helt blottet for klientinnspill. Som vi vet altfor godt, får kunder ofte en mye tydeligere forståelse av hva de leter etter ett nettsted kommer sammen. I tillegg har etterspørselen i markedet en vane å endre seg raskere enn designere kan produsere. Dette kan være frustrerende når du jobber innenfor et paradigme der omdirigering er både arbeidskraft og tidskrevende.
Å ta i bruk en smidig tilnærming av looping av klienter i alle faser av prosessen og produsere en konstant strøm av leveranser kan bidra til å fikse dette, da det lar klienter leke seg med design mens de går. Det lar dem også få en bedre forståelse av hvordan den realiserte visjonen vil fungere i en reell verdenssammenheng. Jo mer regelmessig kommunikasjonen, desto lavere er sjansen for at overraskelser oppstår underveis, jo bedre kan et lag tilpasse seg endrede krav underveis, i stedet for å måtte trene opp trinnene.
Kort sagt: Gjør kunden til et medlem av teamet ditt.
Samler ofte arbeid på tvers av lag
I utviklingsverdenen er integrering av inter- og interteamarbeid en avgjørende del av ethvert prosjekt. Dette er desto mer sant når teamene vokser fra titusen til tusenvis hos de største organisasjonene. Men integrering i fossefallsmetoden skjer med sjeldne intervaller, noe som gjør det desto vanskeligere for devs å finne feil i en enorm mengde kode. Det fører også til mye backtracking og forsinkelser på skipet.
Ikke slik med den smidige metoden for kontinuerlig integrasjon, som har devs integrerende kode på en gang om ikke tre ganger daglig. Kontinuerlig integrasjon tar virkelig det uønskede mysteriet ut av integrasjonen, slik at devs kan fange feil når de oppstår og enten fikse dem umiddelbart eller legge dem inn i etterslepet for neste iterasjon av prosjektet. Det passer også fint inn i det smidige konseptet med privilegerte interaksjoner over prosesser, da devs på tvers av team må kommunisere ofte for å identifisere og fikse denne typen feil.
Designere kan dra nytte av en lignende mentalitet, enten det betyr å gjøre en enkel innsjekking med andre teammedlemmer til daglig, eller kommunisere oftere med devs for å avgjøre hva som er teknisk mulig å implementere før de drar nedover en spennende, men vanskelig designvei. Tverrteam-kommunikasjon og sammenstilling av arbeid vil også holde designere fokusert på å designe når design er nødvendig, i stedet for å overplanlegge eller til og med implementere designarbeid som ikke synkroniserer med hva andre team gjør.
Test, test, test ... hele tiden
På en lignende, men avgjørende anmerkning, er hyppig testing en viktig del av å holde iterasjoner på sporet. Med "testing" mener jeg å se utover integrasjon til et designs funksjonalitet både på et mikro- og makronivå ved å utvikle et problemløsingssynspunkt. I smidig utvikling bryter devs større problemer ned i mindre som kan adresseres bedre innenfor rammen av raske iterasjoner. Testing av dette arbeidet lar dem deretter identifisere problemer som skal adresseres enten umiddelbart eller i neste iterasjon. Dette holder devs på sporet og i tide, og forhindrer at lammingen oppstår når for mye nærmer seg samtidig.
På denne måten kan hyppige tester og mentalitetsproblemer ikke bare holde designprosessen i rute, men også øke kreativiteten, da det forhindrer designere fra å bli for fanget på det største problemet av alle: Å vite fra begynnelsen går nøyaktig hvordan et nettsted skal se og føle på. Ved å fokusere på mindre problemer, kan designere omfavne en mer fremtredende kreativ prosess og oppdage deres visjon mens de går.
Alt dette er sagt, verdien av å zoome tilbake til makronivået kan ikke ignoreres, ellers vil design bli for usammenhengende. Som en fin balanse mellom smidige mindre problemløsningsfokus og fossefallets mer helhetlige syn, er det verdt å vie flere iterasjoner til å løse problemer i sammenheng med det større bildet, og også bare ta inn synspunktet for konsistens skyld.
Kort oppsummert
Når du virkelig tenker på det, er smidig design ganske enkelt anvendelsen av visse smidige utviklingsprinsipper på designprosessen. Ettersom hvert designer og designteam er forskjellige, er det best å velge metodene som fungerer for deg og tilpasse dem mens du går. Det virker tross alt som den smidige tingen å gjøre.
