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.

Jørgen Blindheim

Flere artikler av Jørgen CV

9 kommentarer

  1. Veldig bra bloggpost! Dette er noe som vi som jobber i utviklingsselskap virkelig brenner for. Det er en mye mer effektiv prosess at utviklerne våre involveres i tidlig fase, på samme måte som at designene også bør involveres i sluttfasen av prosjektene ifm kvalitetssikring av design og innhold.

  2. Ingen sitter med all kunnskap om hvordan en nettside bør se ut og fungere.

    En inkluderende prosess med innspill fra alle de som skal være med å lage dem, kan spare mye bortkastet tid og bidra til langt bedre løsninger. Ikke minst når tekniske begrensninger parkerer en kreativ og fiffig idé mange har brukt mye tid på, men som ikke går an å realisere.

    Det er også forskjell på utviklere; noen kan ta et designspråk og lage uspesifiserte ting basert på det, andre vil ha alt detaljert beskrevet. Problemet med førstnevnte er at designer antageligvis ikke får det akkurat slik de så for seg – men det er straffen for å ikke ha “tenkt på alt” og spesifisert hvordan alt skal være.

    Utviklere er ikke tankelesere, og avhengig av deres designsans og -kunnskap, kan ikke designeren forvente at de tryller fram noe som aldri har blitt skissert på akkurat den måten de forventer. Og det inkluderer all form for interaksjon som forventes/trengs – dette er ikke noe man kan overlate til tilfeldighetene.

    På sin side, er det utviklers ansvar å melde fra dersom designet ikke kan løses på måten det var tenkt, fremfor å bare finne på noe som “funker”. Utvikleren må også løse designet i tråd med den overordnede ideen bak det. Dersom denne finnes. (“Designsystem” ser jeg skrevet i innlegget. Show me the money!)

    Dersom utvikleren er involvert fra begynnelsen av designprosessen, kan man luke ut mange frustrasjoner og spare inn bortkastet tid senere i utviklingsfasen.

    Så blir alle mer fornøyd!

  3. SÅ ENIG.

    Men det gjelder ikke bare utviklere (som meg selv) – det gjelder alle parter. Designere, utviklere av alle slag og prosjektledere som skal delta i prosessen. Om alle er inkludert fra børjan av, så blir resultatet garantert bedre enn om én av partene er ekskludert inntil de “skal begynne å jobbe”. Jeg er helt overbevist at om et prosjekt skal bli så smertefritt som mulig, så må alle typer parter med tidlig. Helst med en gang.

  4. Godt blogginnlegg!

  5. Bra saker. Synes Magne i Dekode sa det fint under fagdagen vår på fredag: De ønsker å være en samarbeidspartner, ikke en underleverandør.

  6. God og viktig post. Men du har – som mange andre – vært utsatt for en misforstått form for Scrum (ja, det er ikke noe akronym og staves med små bokstaver).

    Du skriver “Fellesnevneren for disse prosessene er at de er designet for at man skal produsere mest mulig på kortest mulig tid.” NEI. Dette er helt feil. I ordentlig Scrum gjøres jobben i selvstyrte, tverrfaglige team (design, utvikling, test, dok etc) og fokus er på teamets læring gjennom feedback, ikke produktivitet.

    Planning Poker er en fin liten teknikk man kan bruke for å anslå relativ størrelse på oppgaver slik at blir mulig å prioritere innsatsen basert på kost/nytte.

  7. At designet skal fungere i alle skjermstørrelser fra starten – både mobil, pad, liten og stor skjerm – har gjort at webdesignfaget har fjernet seg så langt fra papirtradisjonene at enkelte papirdesignuvaner er virkelig til bry for å få ok sluttresultat.

  8. @Geir: Du har helt rett, men det er skjelden slik i praksis etter min erfaring. Rettet opp i Scrum nå :)

    Ang. planning poker, så er dette en morsom øvelse (for å være estimering). Men summen av alle disse møtene og rigide prosessene syntes jeg ikke resulterer i noe jeg vil kalle effektivitet, heller ikke noen form for høy læringskurve, selv om det ofte er målet. Dette er jo selvfølgelig kun mine erfaringer, og det finnes helt sikkert alltid steder det fungerer med rigide prosesser.

  9. Pingback: → Frontend-utvikler med øye for design — iAllenkelhet

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>