Et hett tema som har vært diskutert de siste årene har vært hvorvidt interaksjonsdesignere bør kunne kode. Det er ingen hemmelighet at for at et utviklingsprosjekt skal kunne lykkes så må designere og utviklere jobbe i tett samarbeid. Av flere grunner bør det være lav terskel for kommunikasjon mellom disse to partene. Utvikleren ønsker ofte å bli inkludert i designarbeidet, både for at hun ikke skal føle seg fremmedgjort når utviklingen starter, men også fordi utviklerne ofte også sitter på gode innspill, når det gjelder brukervennlighet og design, som de gjerne ønsker å dele.

På den andre siden bør designerne ha tett dialog med utviklerne for å kunne vite mer om hvilke muligheter og begrensninger som finnes i teknologien som er i bruk. Denne kommunikasjonen kan åpne for større innsikt i hva som er billig og hva som er dyrt å implementere. Dette er kunnskap som er kritisk for en designer, og uten kommunikasjon med utviklere, scrum-mastere, tekniske og funksjonelle arkitekter, i tillegg til brukerne, kan man lett havne i en situasjon der man bommer fullstendig på et design.

For et par uker siden kom det frem i mediene at Statoil måtte kutte ut sitt 100-millioners utviklingsprosjekt fordi brukerne ikke ville ha det. Det var ikke brukervennlig. Hvorfor ble det slik? Man kan jo spørre seg om de har hatt designere i prosjektet i det hele tatt?

I våre prosjekter har vi ofte interaksjonsdesignere som likeverdige medlemmer av utviklingsteam eller som en egen enhet i prosjektet. Min personlige erfaring er at både designere som er generalister og spesialister fungerer på hver sin måte i et utviklingsprosjekt. Kanskje det beste er å ha en av hver i prosjektet?

I prosjektet jeg er i nå er vi to interaksjonsdesignere. Den ene designeren er mer erfaren og er i en rolle som er mer spesialistrettet. Han har mange års erfaring og har et større ansvar for det overordnede og langsiktige design- og brukskvalitetsperspektivet, mens jeg jobber mer detaljfokusert og er tettere på koden og utviklerne. Dette gjør at jeg kan gjøre front-end kodeendringer selv med alle de fordeler det medfører. Blant annet fører det til at ting vi mener er essensielt for å sikre brukervennligheten faktisk blir gjort. GUI-forbedringer og andre ting som kanskje utviklerne og andre synes er unødvendig mas, kan vi sitte og flikke på uten at vi “stjeler” andres tid. Dette samspillet har fungert svært bra hittil i vårt prosjekt, og vi tror at vi oppnår det beste resultatet ved å gjøre det slik.

Poenget er ikke at man må være en topp-programmerer, samtidig som man er ekspert innen brukervennlighet. Det tør jeg påstå er en utopi – man kan rett og slett ikke være spesialist i begge fagområder. Men, jeg tror at man er en bedre designer om man kan noe om koding, og dersom man har en viss innsikt i det.

Ja, det er en drøss av utviklere som kan lage bedre kode raskere, men de er som regel opptatt med egne arbeidsoppgaver. Om man kan noe kode kan man få til designet slik det er tiltenkt. Man kan lett lage realistiske og høyoppløste prototyper. Interaktive prototyper kan lette kommunikasjonen mellom deg og kunden eller med utviklerne, noe som igjen kan gjøre at flere forstår designet man prøver å kommunisere. Og det vil man jo?

Hvordan gjør dere det der ute i prosjekthverdagen?

Les mer:

Statoils mislykkede utviklingsprosjekt

Jared Spool – “3 Reasons Why Learning To Code Makes You A Better Designer”

Jeff Sauro – “5 Valuable Skills For UX Professionals”

Austin Center for Design – “Code is material: why designers must learn to code”

 

Bånn i bøttaDårligHelt greitBraDritbra! (Antall stemmer: 2 Gjennomsnittscore 4.50 av 5)
Loading ... Loading ...

9 Responses to “Bør designere kunne kode?”

  1. Geir Amsjø Says:

    Hei Øyvind,
    jeg er veldig enig i at utviklere og designere må jobbe tett sammen. Og gjerne beherske hverandres fagfelt, uten at noen behøver å være spesielt på begge felt. Det er nok svært få som vil kunne oppfylle dette.

    Men jeg synes du legger for lite vekt på en gruppe, nemlig brukerne. Det er vel de som til syvende og sist vil avgjøre om det faktisk ble brukervennlig eller ikke.

    Statoil-prosjektet er dypt tragisk. Det store spørsmålet her er etter min mening ikke hvorvidt det har vært interaksjonsdesignere i prosjektet, men hvorfor de klarte å holde på i 5 år, før de “oppdaget” at det ikke var bra nok! Om brukerne hadde vært med underveis (med en viss inflytelse), og de hadde hatt delleveranser, burde de kunne spart noen hundre millioner og skrinlagt eller omdefinert prosjektet mye tidligere. Et trist poeng i dette er at Statoil virkelig satser på Scrum. Man kan spørre seg hva slags Scrum det er…

    Bra? Thumb up 2 Thumb down 0

  2. Lill Says:

    Enig i at designeren bør kunne noe koding. Er ganske fersk interaksjonsdesigner (faktisk, så fersk som man kan bli), men skulle gjerne kunnet mer koding, og det er jo noe som ikke kommer av seg selv. Har jo noe basics inne, men hvorvidt jeg kan si at jeg ‘kan’-kode.. njeh.. :)

    Fantastisk kommentar. Hva synes du? Thumb up 4 Thumb down 0

  3. Øyvind Nordseth Pettersen Says:

    Takk for kommentarer, Geir og Lill!

    Geir: Jeg er helt enig med deg i at det er brukerne som, når alt kommer til alt, kan gi svaret på om noe er brukervennlig eller ei. Gruppen man designer og utvikler for må alltid være i fokus.

    Der jeg har jobbet hittil har det primært vært designerne som har hatt mest kontakt med brukerne og vært den naturlige lenken mellom utviklerne og brukerne. Så det er derfor jeg lurer på om Statoil-prosjektet har hatt designere i prosjektet eller ei, siden det virker som at det har vært null brukerinvolvering. Jeg kunne nok presisert det tydeligere i innlegget, og lagt mer vekt på brukerinvolvering, så den ser jeg :)

    Delleveranser der minidemoer med brukerne, brukertester, samt jevnlig kontakt med brukerne er i mine øyne helt uunværlig for å oppnå et brukervennlig resultat.

    Lill: Gratulerer som fersk interaksjonsdesigner! Og så bra at du har et ønske om å kunne mer om koding! Da er det jo bare å utforske dette videre :) Har man nysgjerrigheten og læreviljen så kan man jo lære seg alt!

    Jeg tror det er viktig å huske på at vi som designere aldri kan være 100% designer og koder samtidig. Men at det å kunne “snakke språket” til utviklerne kan ha en positiv effekt når det gjelder kommunikasjonen oss i mellom. Likevel tror jeg det er viktig å ikke “bikke over”, slik at vi mister vår kreative sans og fortsetter å foreslå gode og spennende design, som ikke nødvendigvis er det letteste å utvikle ;)

    Bra? Thumb up 2 Thumb down 0

  4. Ole Fredrik Lie Says:

    Hei. Interessant problemstilling!

    Om designere bør kunne kode avhenger slik jeg ser det av to faktorer:
    1) Hva ligger i begrepet ‘designer’?
    2) Hva ligger i begrepet ‘å kode’?

    En grafisk designer som i hovedsak jobber med trykte medier er sannsynligvis i liten grad tjent med å ha masse kunnskaper om å kode websider.

    Samtidig vil en interaksjonsdesigner eller web designer (er det egentlig så stor forskjell nå til dags?) slite dersom vedkommende ikke har evne eller i det minste interesse for å lære html, css og noe javascript.

    I disse dager hvor kundene med god grunn forventer et design som kan tilpasses ulike enheter, gjør man seg selv en bjørnetjeneste om man ignorerer html og css som en viktig del av designprosessen.

    Det er naturligvis ikke enkelt å være dyktig på alt. Man må sette en grense ett sted for å være i stand til å rendyrke sin egen kompetanse. Jeg mener det er rart og synd om web designere setter den grensen ved lagre-knappen i Photoshop.

    Bra? Thumb up 2 Thumb down 0

  5. M. Mikkel Rummelhoff Says:

    Det er sjelden mye tid å spare i prosjektet på at designeren leverer f.eks. markup og CSS, og mitt inntrykk er at programmeringskompetanse hos designere er ikke lenger noe bransjen legger særlig vekt på. En stund (før Flash svant hen) var multimediepotetene veldig populære, men med de siste årenes plattform- og teknologifragmentering, er det min oppfatning at feks crossplattformutviklere i dag står langt høyere i kurs enn grafiske designere som kan litt CSS og jQuery. Så nei, jeg mener at designere definitivt ikke må kunne kode. 

    Det designere på skjermbaserte/interaktive prosjekter derimot *må*, er å tilegne seg et høyt nivå av kunnskap om plattformen de designer for – på lik linje med designere i alle andre disipliner.

    Finnes det f.eks. en printdesigner i verden som ville sendt avgårde en 72DPI RGB jpg-fil til trykkeriet? Antagelig ikke, all den tid det forventes at en kompetent printdesigner har en god del teknisk fagkunnskap om trykk.

    Skjermbasert/interaktiv design er ikke noe annerledes, også her bør man forvente at en kompetent designer har et høyt nivå av teknisk fagkunnskap om plattformen han eller hun jobber på. Hvorfor det da “greit” at mange webdesignere fortsatt kan så lite om web?

    Vi trenger altså ikke designere som kan kode, men vi trenger designere med mye kunnskap om teknologi – og i den forbindelse kan det å kode litt absolutt være en god måte å øke kunnskapen på.

    Bra? Thumb up 1 Thumb down 0

  6. Ole Fredrik Lie Says:

    @M.Mikkel: Om det er tid å spare på at designeren leverer f.eks markup og CSS avhenger vel av prosjektet og kompetansen hos prosjektdeltakerne? Vil det ikke være tidsbesparende om webdesigneren leverer god, semantisk markup og css dersom utviklerne i teamet har størst kompetanse på backend kode?

    Ellers, godt sagt. Jeg er enig i det meste du skriver. Som vanlig :)

    Bra? Thumb up 3 Thumb down 0

  7. Øyvind Nordseth Pettersen Says:

    Takk for mange gode poenger, Ole Fredrik og M.Mikkel :) Jeg er enig i det meste begge skriver.

    Jeg tror at fokuset på kunnskap om materialet og plattformen noe bygges i, er helt essensielt. Om det nødvendigvis betyr at man “kan kode” er jeg usikker på.

    Uansett så er jeg overbevist om at dersom interaksjonsdesigneren har en viss innsikt i materialet/plattformen/koden, så kan det kanskje være lettere å designe løsninger som kan være spennende og brukervennlige, som ikke nødvendigvis er de enkleste å implementere, men som man vet er mulig å få til innenfor de rammene man har.

    Bra? Thumb up 0 Thumb down 0

  8. M. Mikkel Rummelhoff Says:

    @Ole Fredrik: Så klart, alt er relativt. For mindre komplekse prosjekter med små teams er det klart at designere med god kompetanse på markup og CSS er gull verdt, og absolutt noe som kan spare både tid og penger. En designer med innsikt og kompetanse i teknologi har definitivt et ekstra ess i ermet (personlig syns jeg egentlig det er vanskelig å forstå at det finnes UX designere som *ikke* er nysgjerrige på teknologien, men det er en annen sak…)

    Samtidig: Spaghettikode er en killer fordi det genererer bugs, og bugs er hovedgrunnen til at estimater sprekker. Frontendprogrammering er et utrolig komplekst fag, og for de aller fleste tar det lang tid å få hodet ut av spaghettiboksen – det tar imidlertid ikke særlig lang tid å oppnå en god, grunnleggende forståelse for de fleste viktige prinsipper, og *derfor* er jeg for at alle designere bør teste ut koding, i det minste HTML/CSS. Ikke fordi det er en god idé i seg selv med folk som “kan alt” eller fordi man satser på å spare masse penger på å få designeren til å levere stilark, men fordi koding er en ypperlig måte å oppnå det nivået av teknisk innsikt man strengt tatt *må* ha som f.eks. webdesigner.

    Eks: En webdesigner som ikke kjenner implikasjonene ved bruk av ikke-standard fonter, som leverer ustrukturerte PSD-filer med rasterisert vektorgrafikk, som bruker punkter i stedet for pixler eller som ikke følger et godt gridsystem, mangler det nivået av teknisk kompetanse man bør forvente – jfr. printdesigneren som leverer til trykk i 72DPI. Det er en litt merkelig greie at man i interaktiv design i mange tilfeller virker å stille lavere krav til underliggende teknisk fagkompetanse enn man gjør i andre designdisipliner – men her er jeg på litt tynn is, så jeg gir meg her :)

    Bra? Thumb up 0 Thumb down 0

  9. M. Mikkel Rummelhoff Says:

    @Øyvind: Poenget ditt om prototyping er også ekstremt relevant. Designere som har kompetanse til å raskt produsere interaktive mockups har en *stor* fordel i det å kommunisere ideer til både utvikler og kunde. Det finnes imidlertid flere helt OK prototyping-verktøy som ikke egentlig krever noen særlig teknisk innsikt. Og kode skrevet til prototyper bør sjelden tas med over i produksjon.

    Bra? Thumb up 0 Thumb down 0