Fordele og ulemper ved Big Design Up Front - og hvad jeg gør i stedet

Kan et vandfald sprint? Kan en vindhunde sænke farten?

Jeg har drevet min egen uafhængige designvirksomhed i 18 år. Startende tilbage, da vandfaldet var alt, hvad vi havde, derefter overgang til ekstrem adræt og alle variationerne imellem.

Som freelancer arbejder jeg for en række kunder - store og små - på en bred vifte af digitale produkter: fra enkle brochurewebsites til komplekse web- og mobilapps. Jeg bruger stadig en BDUF-vandfaldsproces, når det passer til projektet. Andre gange kræver atmosfæren en meget iterativ og smidig tilgang.

Jeg skifter ofte mellem disse polar modsatte designmetoder på daglig basis, da jeg skifter fokus fra et projekt til et andet. Det har hjulpet mig med at tilpasse mig begge dele og indse styrker og svagheder ved hver proces. Øvelse af begge metoder gør mig regelmæssigt unik til at forstå, når den ene fungerer bedre end den anden. Og det fik mig til at tænke på, om BDUF stadig har en plads i den moderne design- og udviklingsverden.

Før vi diskuterer BDUF vs. Agile, lad os starte med et par definitioner:

Vandfald

En relativt lineær sekventiel designtilgang, hvor fremskridt i stort set en retning ("nedad" som et vandfald) gennem faser af forskning, undfangelse, design, konstruktion, test, implementering og vedligeholdelse.

Zoom ind eller ud

I design betyder zoom ud at fokusere på helheden i et designsystem, evaluere dets effektivitet og sikre, at det fungerer sammen konsekvent og harmonisk.

Zoom ind er handlingen med at fokusere på et mindre stykke af helheden - en funktion, side, brugerflow osv. - praktisk design, der udarbejder individuelle designløsninger.

Iteration

En cyklisk proces med prototypebestemmelse, test, analyse og raffinering af et produkt eller en proces. Baseret på resultaterne af feedback fra interessenter eller test foretages ændringer og forbedringer.

Integration

En handling, der kombineres til en integreret helhed.

Omkostninger, billige, dyre

I denne sammenhæng henviser det til den tid og kræfter, der bruges på design eller udvikling, ikke nødvendigvis en direkte relation til de monetære omkostninger.

Ingeniørarbejde, udvikling, kodning

Brugt noget om hinanden - til at tegne linjen mellem hvor design stopper og teknisk implementering begynder.

Hvad er BDUF?

Big Design Up Front er en tilgang, hvor et websted, en app eller et softwaredesign afsluttes og perfektioneres på forhånd, inden implementeringen påbegyndes. Det nødvendiggør en vandfaldsproces og er afhængig af forudsigelse . Dette var den fremherskende metode i årtier før Agile kom. Websites og software plejede at være meget dyre at bygge, så det var nødvendigt at stryge så mange kinks ud som muligt, før den dyre teknik skete.

Tænk på det som at kortlægge et skibs kurs. Hvis du allerede kender ruten, vejret, strømme og tidevand, kan du planlægge turen, inden du rammer vandet. Når du forlader havnen, behøver du ikke spilde tid på at få din kuglelejer.

Designere, der har eksisteret i mere end et årti - eller arbejder uden for Silicon Valley "produkt" -boblen - har sandsynligvis finpudset deres håndværk ved hjælp af BDUF. Det er deres designkomfortzone.

BDUF antagelser

  • Vi kan fuldt ud kende målene, kravene og omfanget af designet foran - og det er usandsynligt, at der oplever væsentlige ændringer.
  • Designrevisioner er generelt sværere og dyrere at lave, efter at kode er skrevet. Effektivitet opnås ved at sortere så meget som muligt i design.
  • Vi kan og skal bedømme, om en designløsning er god eller effektiv, før den er fuldt funktionel.
  • Ingeniører kan finde udviklingsudfordringer, mens de stadig er i design, så vi kan finde alternative designløsninger, inden vi trykker på kode.
  • Hvis de overlades til deres egne enheder, vil ingeniører lave et rod af ting. Design skal gå foran, ellers vil UX og æstetik lide.

BDUF styrker

  • Hvis du ved præcis, hvad du vil, er dette den mest effektive måde at komme derhen.
  • Da alt design udføres på én gang, er der rig mulighed for at zoome ud, integrere ofte og designe holistisk.
  • Brugeroplevelse er designet og raffineret af designere, og denne designdokumentation dikterer funktionaliteten for ingeniører til at udvikle sig. Hver rolle spiller efter deres styrker.
  • Let at koste og planlægge design, da det er en kendt mængde fra starten.

BDUF svagheder

  • Ikke let at tilpasse til ændringer i omfang eller drejelige formål. Du bliver muligvis nødt til at svømme tilbage op ad vandfaldet for at starte igen, hvis mål eller krav bevæger sig.
  • Design er ikke så let testet og valideret, fordi ingen del af det er fuldt funktionelt indtil nær slutningen af ​​den lineære proces.
  • Udnytter ikke ny læring eller bedre løsninger, der kan opstå i de senere faser af vandfaldsprocessen.

Agilt og Emergent Design

Den agile udviklingsmetode blev designet til komplekse, ikke-deterministiske, ikke-lineære projekter. Det prioriterer at være adaptiv snarere end forudsigelig , hvilket reducerer springet af tro, der er nødvendigt, før bevis indhentes.

Agile sigter mod at nedbryde et projekt i mindre stykker. Tværfunktionelle teams bruger derefter sprints med korte tidsrammer til at arbejde igennem accelererede versioner af hele vandfaldsprocessen - med det mål at designe, producere og teste noget i hver sprint. Deres læring integreres derefter i projektets udviklingsomfang og hjælper med at forme retningen af ​​de næste sprints og iterationer.

Hvis BDUF er en meget veldokumenteret rejse planlagt på forhånd, får Agile dit skib ud af havnen med kun en vag idé om, hvor du skal hen, og derefter udforske, planlægge og tilpasse sig i vandet. Det er en række små indsatser snarere end en enkelt godt beregnet indsats.

Den Manifest for Agile Software Development er baseret på tolv principper (via Wikipedia):

  1. Kundetilfredshed ved tidlig og kontinuerlig levering af værdifuld software.
  2. Velkommen skiftende krav, selv i sen udvikling.
  3. Lever arbejdssoftware ofte (uger snarere end måneder)
  4. Tæt, dagligt samarbejde mellem forretningsfolk og udviklere
  5. Projekter er bygget op omkring motiverede individer, som man skal have tillid til
  6. Ansigt til ansigt samtale er den bedste form for kommunikation (samlokalisering)
  7. Arbejdssoftware er det primære mål for fremskridt
  8. Bæredygtig udvikling, i stand til at opretholde et konstant tempo
  9. Løbende opmærksomhed på teknisk ekspertise og godt design
  10. Enkelhed - kunsten at maksimere mængden af ​​arbejde, der ikke er udført - er afgørende
  11. De bedste arkitekturer, krav og design fremgår af selvorganiserende teams
  12. Regelmæssigt reflekterer holdet over, hvordan man bliver mere effektiv, og tilpasser sig i overensstemmelse hermed

Emergent Design

Agile metoder kræver en ny måde at tænke på, som er blevet beskrevet som et nyt design . Emergent design sigter mod at gøre det modsatte som BDUF - minimal eller intet design foran, så vi kan komme til forsendelse, test og validering så hurtigt som muligt.

Emergent design antagelser

  • Vi kan ikke fuldt ud forstå problemet eller dets ideelle løsning uden meget test og læring. Kravene og designet skal udledes , så det er bedre at begynde at opbygge testen ASAP.
  • Ændring er billigere i kode end under design. (Eller i det mindste lige så dyre).
  • Design kan ikke bedømmes eller valideres, før det er bygget og anvendeligt i den virkelige verden.
  • Designere kan skabe teknisk umulige eller dyre løsninger, hvis deres arbejde ikke ofte integreres og testes.
  • For meget design foran (og al dokumentation) er spildt kræfter, da kravene vil ændre sig, eller nye løsninger vil opstå, før designet overhovedet implementeres.

Emerging design styrker

  • Design udvikler sig over tid og kan drage fordel af nye læringer.
  • Design er en samarbejdsindsats og ikke en solo, reclusive proces. Som Manuel Dahm sagde: "Dette kræver, at designeren flytter fra det ensomme elfenbenstårn af kreativt geni ind i teamsindets fælles lejlighed."
  • Design og udvikling sker parallelt, hvilket letter et enormt samarbejde på tværs af team og hurtig problemløsning. Brande kan slukkes ved det første tegn på røg.
  • Lidt er tilbage til antagelse eller intuition. Design implementeres kun, hvis det er bevist, at data lykkes. Usikkerhed om designeffektivitet fjernes.

Emergent design svagheder

  • Agile kan være for outputfokuseret og opmuntrer funktionsfabrikken.
  • Ironisk nok tillader konteksten af ​​sprints hyppigere integration på makroniveau, men giver færre muligheder for dyb, holistisk designtænkning. For meget snævert fokus og ikke nok bred vision betyder mindre chance for integration på niveau med designsystemer. Dette kan føre til et middelmådigt, inkonsekvent design, der mangler polskhed og helhed.
  • Design er svært at koste, fordi det er et bevægeligt mål dikteret af feedback fra interessenter og sprintcyklusser. Fuldt omfang af design opstår muligvis først halvvejs (eller længere) gennem et projekt.
  • Den sprint og gentag cyklus slutter ofte, når ”god nok” design opstår. Derefter sendes det uden megen mulighed for at løfte design forbi middelmådighed. Designere mister deres prioriteter for kvalitetskontrol, når beslutningen dikteres af data alene.

Bare nok design foran

”Stort design foran er dumt, men at lave intet design foran er endda dummere.” - Dave Thomas

Jeg plejede at tro, at agil var fjenden af ​​godt design, men så indså jeg, at det bare er, at bad agile ikke giver plads til godt design. Jeg modstod at omfavne en smidig måde eller arbejde, fordi mange af mine oplevelser fremhævede svaghederne ved det nye design og ikke kompenserede for dem med deres styrker.

In Er Agile the Enemy (med godt design)? , John Cutler siger "Godt" vandfald slår misbrugt Agile enhver dag.

Jeg bliver nødt til at være enig.

Enhver produktudviklingsmetode forsøger at besvare designspørgsmål, når det er billigste at gøre det . Agile tilhængere tror stærkt på, at det er billigste i små intervaller under korte sprints. BDUF fungerer, når det er billigste foran og betragtes som en helhed. Men ingen af ​​dem arbejder for designere, når de ikke giver et godt designresultat.

Jeg tror ikke, at hverken BDUF eller Agile finder den rette balance. Det er et sted imellem. Derfor er min foretrukne designmetode Just Enough Design Up Front (JEDUF).

JEDUF til undsætning

JEDUF erkender, at der kræves noget overordnet design for at muliggøre mere detaljeret arbejde. Vi kan ikke altid skyde fra hoften med "cowboy-udvikling". For det første har vi brug for et par målstolper. Vi har brug for arkitektur og design for at skabe et fundament for vores sprints.

  • Tidligt designarbejde kan være groft, men bør altid være så godt som det kan, givet de tilgængelige oplysninger på det tidspunkt. Ja, meget mere designarbejde bliver nødt til at dukke op senere, men vi vil ikke gentage noget design, hvis vi kan få det rigtigt første gang.
  • Up-front design bør betragtes som de mest grundlæggende aspekter af et projekt eller produkt, så det informerer om de prioriteter, der skal bygges og testes under tidlige sprints. Med andre ord identificer de højeste risici, og design derefter først til dem. Dette lægger grundlaget for et designsystem, stresstestet tidligt og ofte af udviklede stykker af højeste værdi. Nogle kalder dette nødvendige up-front design for den ”primitive helhed”.

Ud over JEDUF

Min egen version af JEDUF inkluderer muligheder for designkompression og integration på forskellige stadier under projektet. Jeg kalder det Just Enough Design Up Front & Middle .

JEDUF & M afbalancerer små sprints - zoomet ind - og muligheder for holistisk designintegration fra et bredt perspektiv. Når en kritisk masse af funktionalitet er opstået, kan sprintcyklussen sættes på pause for at overveje dybere design.

Tænk på det som en anden forudgående designsession, kun dens mål handler om samhørighed snarere end udforskning . Når designsystemet føles holistisk og under kontrol - integrering og harmonisering af revisionerne fra tidligere sprints og læringer - begynder den næste runde sprints. Det er op til designeren at erkende, hvornår behovet for en "mellem" -designpause er påkrævet, og ikke lade projektet blive for fanget i detaljerne.

Jeg har fundet JEDUF & M som den ultimative designmetode. Det afbalancerer tilpasningsevne, hurtige iterationer og fokus på validering, der gør adræt så kraftig - samtidig med at det giver mulighed for perioder med hvile, integration og helhedsorienteret designsystemtænkning, der kan gå tabt blandt sprints og funktioner.

Hvis du selv under denne ideelle balance mellem metoder er bekymret for antallet af usikkerheder, så tænk på det i stedet: omfavn usikkerheden . Nu er du i stand til at forme, hvad disse begrænsninger bliver , snarere end at have dem forudbestemt og dikteret til dig. Dette er mere ansvar, men også mere fleksibilitet. Hvis du håndterer den rolle med aplomb, leverer du et resultat uden beklagelse eller kompromiser, selvom processen er mere udfordrende undervejs.

Der er stadig masser af plads til BDUF

Du har ikke råd til at afskedige din dinosaur helt. Big Design Up Front er en meget gyldig og effektiv model, når den bruges til de rigtige projekter.

Fordelen ved frontdesign øges, efterhånden som systemets kompleksitet aftager.

Ikke alle designere arbejder på komplekse virksomhedsapps med variable interessentmål og usikre løsninger. Ikke alle projekter kræver massiv efterforskning, test og kundevalidering.

Jeg kan ikke forestille mig at tage en agil tilgang til at designe og opbygge en simpel brochure eller portefølje-webside. Mine klienter ville tro, at jeg er sur. I disse tilfælde er BDUF stadig i live og sparke.

BDUF og Agile er to ender af et enkelt spektrum. Identificer, hvad du skal validere før, under og efter du bygger, og skræddersy din proces for at lette det rigtige design på det rigtige tidspunkt. De fleste projekter vil falde et sted midt i spektret, ikke de radikale frynser.

Og lad os ikke glemme, at vandfaldsprocessen ikke behøver at være så stiv og lineær, som dens kritikere gør det. BDUF kan stadig "levere tidligt og ofte", indsamle feedback fra interessenter, gentage sig hurtigt og udvikle sig over tid. Det er bare, at denne udvikling sker fuldstændigt inden for designområdet.

Vi kan lave mini-vandfald i vores store vandfald. Der er masser af nyttige måder at opnå små valideringer og komme videre uden at et helt tværfunktionelt team skubber det lige ind i koden og skynder sig at sende.

BDUF betyder ikke, at der ikke er nogen mulighed for at lære, tilpasse og forbedre design gennem feedback og iteration. Hvis det er det, du synes, BDUF er, har du måske gjort det forkert i alle disse år?

Venligst ? c skød, hvis du fandt dette værdifuldt, og? f o llow mig f eller flere skriver på denne måde, da jeg udfolde 18 års freelance design viden?

Abonner for at få mine bedste artikler i din indbakke.

Denne historie kan også findes på solowork.co