Verdiløst design 9

Det er dessverre ofte slik at samme hvor bra det vi designer er i utgangspunktet, blir ikke sluttresultatet slik vi ville. Det vi gjør som designere er i bunn og grunn verdiløst om sluttresultatet ikke blir bra. Men hvordan kan vi sørge for at kvaliteten blir bra i faser vi ikke råder over?

Fra pdf til trykk

I min korte karriere som trykkdesigner pleide vi å jobbe tett med et trykkeri som lå i nærheten av kontoret vårt. Trykkeriet var ikke det billigste, men vi valgte det fordi vi raskt kunne ta turen innom og kjøre prøver på tingene vi laget. Vi fikk sett og tatt på papiret vi skulle trykke på, og korrigere tidlig dersom det vi lagde ikke ble helt riktig. Vanligvis kom trykkeriet med veldig gode anbefalinger til papirvalg, kontraster, trykkmetoder og hvilke formater vi skulle lagre filene våre i. Dette bidro også til at vi foretrakk dem over andre trykkerier.

I dag jobber jeg med web, og det er lett å dra paralleller. Vi designere har lett for å se på utviklerene som et produksjonsledd som designet vi lager skal sendes til. Og derifra går det nedover med designet. Ting blir ikke som de skal, og grunnene varierer fra tekniske vanskeligheter til glipper. Kanskje det er på tide å innse at det ikke alltid er lurt å dra disse parallellene og oversette gamle arbeidsmetoder. Nye epoker krever nye måter å jobbe på og vi må kvitte oss med det gamle tankesettet.

The dark side of the utviklingsløp

Min bakgrunn er variert. Jeg har befunnet meg i alle faser av et utviklingsløp – både som designer og utvikler. Jeg har vært både oppdragsgiver og produsent.

Vanligvis har jeg vært fritatt fra å få en backlog dyttet ned over hodet. Men fra tid til annen har det vært nettopp slik, og det er en deprimerende måte å jobbe på. Det er et sted hvor ord som pragmatisk og smidig ofte blir brukt. Hvor man har rigide prosesser for alt. Prosesser som planningpoker (ja faktisk!), Scrum og sprinter osv. Fellesnevneren for disse prosessene er at de er designet for at man skal produsere mest mulig på kortest mulig tid.

Man ender ofte opp i å være uenig i avgjørelsene som er tatt på andre siden. Kanskje fordi man ikke har blitt inkludert i prosessen hvor avgjørelsene blir tatt. Eller kanskje fordi man er oppdatert på det som skjer på nettet, og faktisk vet bedre.

Når man er vrang ender det fort i nye runder med estimeringer der kravene fra backloggen blir formulert tyngere og tyngere for hver gang. Slik at den som lager kravene ikke skal kunne arresteres for noe. Og du som faktisk skal produsere dette skal kunne jobbe uten å bruke din medføtte kritiske sans.

De gangene man til punkt og prikke har fulgt kravet helt uten å bruke sin kritiske sans blir det selvfølgelig aldri helt slik de på andre siden av backloggen hadde tenkt seg det.

“Heldigvis” straffer den superstrenge prosessen folka på begge sider, og da må det lages et nytt krav, samme hvor liten filleting det måtte være. Og det må selvfølgelig gjennom en ny runde med estimering og prioritering før det kan komme med i en sprint.

Og hva med oss som lager arbeidet for utviklerne?

Det er ikke rart at vi, som er på “riktig” side av backloggen, fra tid til annen er frustrerte over hvordan utviklerene som tar over vårt arbeid ramponerer designet vårt og glemmer de perfekte pixlene. Eller legger inn stygg Bootstrap-styling de stedene vi ikke tenkte på at trengte å designes. Eventuelt skal de ha oss til å designe hver minste detalj, selv om vi har laget et designsystem som gjør at det egentlig ikke skal være nødvendig.

Derfor er det avgjørende at vi får laget gode prototyper hvor vi selv kan løse små og store interaksjonsdetaljer. Og det gir mye mer verdi for utviklerene å få en faktisk prototype enn et designdokument. Vi har skrevet flere blogger om hvorfor vi mener prototyping er veien å gå når man designer på nett.

Men selv om vi lager en god prototype med høy kodekvalitet er det ikke alltid ting blir slik vi har tenkt. Og våre viktigste prinsipper og tanker blir ikke alltid ivaretatt. Og det er ytterst skjelden vi ser at kvaliteten på det vi gjør øker når noen tar over det.

Utviklere er smarte folk, inkluder dem!

Det er jo synd at de som kanskje er smartest i et prosjekt ofte blir behandlet som et samlebånd. Som bare skal isoleres fra avgjørelsene som tas og få detaljerte beskrivelser av hva som skal gjøres slik at de kan slave gjennom det som skal produseres.

Jeg tror mange av problemene vi har med utviklere oppstår nettopp fordi vi ikke har inkludert dem i prosessen, så her er mine bud for hvordan jeg tror vi kan jobbe bedre sammen:

For hva har det vel å si om det vi designer er bra om sluttresultatet blir dårlig? Det er sluttresultatet som teller, ikke bare det flotte designarbeidet som ligger foran.