Design + Utvikling = Prosjektledelse

Det skal ikke være sånn. Det er jo ikke noe gøy. Det finnes en bedre vei å gå!

Én oppskrift kan være at designere må lære seg å kode, eller at utviklerne må lære seg design. Da er problemet løst! Eller? Det er ikke helt sant det heller. Det er ikke stappfullt av folk som kan begge disiplinene. Samtidig er det snakk om mennesker her. Ulike individer, og ikke alle mennesker jobber godt sammen.

Men det finnes håp! Det kan nemlig fungere. Jeg skal gi deg 10 tips, som kan gjøre alle litt lykkeligere.

Bakgrunn

Selv er jeg utdannet grafisk designer, og etter studiene brukte jeg flere år på å lære meg å programmere på egen hånd. Noe jeg gjorde frivillig, fordi koding faktisk er gøy. Det gjør at jeg nå har en slags fot i begge leire, og gjør litt av begge deler. Det tar mye tid og du må ha lyst til å lære deg å kode. Det må vedlikeholdes, hvis ikke så forsvinner det. Jeg hadde både tid og lyst. Og nå føler jeg med både designere og utviklere, og forstår de. Dessverre.

Nøkkelen for å få dette til, er at man må få denne tiden og lov av sin sjef, til å få teste, prøve og feile, om igjen og om igjen, før man plutselig skjønner litt av det man holder på med (og fritiden din må dedikeres til det… neida... joda).

Slik det er nå, og hvorfor det kan være litt skremmende for designere

Vi er alle forskjellige og vi liker ikke endringer, sånn kjempegodt ihvertfall. Derfor gjør vi greiene på vår egen måte. Noen utviklere liker scss, noen liker utility-first css som Tailwind css, noen vanlig css og noen styled components. Noen designere liker Illustrator, noen liker Sketch, noen liker Figma og andre hater alt annet enn Framer X. Verktøy er ikke det viktige, men det hjelper om man vet om hverandres arbeidsmetoder.

Jeg kan fortsette leeeenge med lister på ting man skal vite når man skal kode, men skal avslutte med dette: Noen liker React, noen liker Vue, noen liker (det er helt sant ) Angular og noen tester alltid det nyeste, som i skrivende stund kan være f.eks Sveltejs. Om kort tid er det helt sikkert et nytt rammeverk mange foretrekker.

Ah! Jeg glemte publiseringsløsninger. Noen liker Wordpress, noen liker Craft, noen liker Sanity, noen foretrekker Contentful foran Sanity og noen må dessverre jobbe i episerver. Og alt dette påvirker og/eller begrenser hva man kan få til. Og i tillegg til oss som lager det, er det som regel kunder på andre siden som også vil ha det slik de ønsker.

Det var det man kan forstå

Så, over til det som er vanskelig og komplisert. Og som kan få deg til å hate jobben, livet og noen ganger deg selv.

Om du er designer og skal kode, må du forholde seg til verktøy og ting som terminalen, Github, pull request, trello-boards, jira, merge conflict, installerte og plutselig av-installerte dependencies, node, riktig node versjon, forskjellige rammeverk osv lengre enn langt.

Github er én av disse greiene, og det i seg selv er masse greier. Noe som ofte blir brukt (fordi det er bra, ryddig og nyttig) er pull-request. Det funker ca slik:

1. 🤷‍♂️ Lag en ny branch (på Github? I terminalen?)
2. → Pek til riktig branch i terminalen (HVA ER EN BRANCH????)
3. 🧐 Gjør endringer i koden (i hvilken fil da??)
4. Add og commit til GitHub 🤷‍♂️ (Add og commit?)
5. Push til GitHub (Det tør jeg ikke, da ødelegger jeg sikkert ALT)
6. Lag en ny Pull Request (🤯)
7. Få noen til å se over committen din 😓 (skummelt! Jeg har sikkert skrevet heeelt feil kode…jeg vil ikke at noen skal spør meg om hva jeg tenkte her fordi jeg kopierte bare denne koden fra internett og så funka det)
8. Hvis det er feil, så får du kommentarer på det i retur fra utvikler. (Hvorfor det? Skulle ikke utvikleren fikse det for meg?)
9. Da må du inn i riktig branch igjen 🤦‍♀️🤦‍♂️(hvis du har klart å gå videre til neste oppgave da)
10. Fiks endringene, så commit og push på nytt
11. Be til gud at det var riktig denne gang 🤞

Haha! Livet er for kort til at en designer skal måtte forholde seg til alt dette. En designer skal ikke erstatte en utvikler. Det er ikke poenget. Poenget er at man må forstå hverandre for å samarbeide godt. Poenget er at man må være effektive sammen, og det betyr at man må besøke andre fag-disipliners verden.

Respekt

Man må snakke sammen og finne ut av hvordan man vil jobbe. Det er veldig viktig og det gjør det så sinnsykt mye lettere når man respekterer hverandres fag, vet ting om faget til kollegaen din og lar alle få komme med innspill, selv om du ikke liker de. Og så er det viktig å jobbe åpent/transparent. Figma er et perfekt verktøy for dette, og utviklere må dele kode, selv om den er langt i fra ferdig.

Men allikevel

Ble du litt skremt eller provosert av dette? Greit nok. Jeg tror fremdeles den beste måten du som designer kan bidra med kode i prosjekt, er rett i samme kodebase, samme hva den nå måtte være. Det er bedre for designeren og for utvikleren. Man trenger ikke å jobbe med brancher som beskrevet over, det er ikke overdrevet, men det kan gjøres enklere.

Det man vil til slutt, er at det skal se og føles ut som det du har laget. Alle vil være fornøyd med sluttresultatet. Prosessen er bare viktigst i de prosjektene som ikke ble slik du ville. (Tøyser litt, men ikke helt)

Man begrenses av tid, kjemi med dem du jobber med, kunder som endrer mening, og man irriterer seg over å måtte gjøre de samme tingene flere ganger. Derfor tror jeg at verktøy som Codepen, Codesandbox eller en egen separat kodebase, bare vil generere ekstra arbeid for en utvikler. Hen kommer sannsynligvis ikke til å bruke den koden du har skrevet der allikevel. Og tro meg, jeg er fan (og bruker) av verktøy som Codepen, men jeg kan jo kode. Så for en designer som ikke kan kode, så er det best for prosjektet og for læringskurven til designeren å bidra rett i det som blir til den tingen dere lager.

Figma

Er et veldig bra verktøy, det tror jeg vi kan være enige om. Men for en utvikler å bli invitert til en figma-fil som er rotete, er helt meningsløst. Steg 1 er å organisere figma-filen slik som utvikleren vil forstå det. Bruk delte biblioteker, lag stiler til alle farger, alle typografi-størrelser og lag komponenter av alt du lager. Samle komponentene i et eget art-board, slik at de kan nåes separat. Navngi ting slik utvikleren du skal jobbe med vil navngi ting i koden. Og alle ting som er skisser eller tester, legg dem i en side som heter skisser eller tester.

Start enkelt

Få utvikleren du jobber med til å fikse alt, få opp en localhost av det dere lager på din maskin, koble deg til Github og å pushe og comitte endringene dine i starten.

Og start med mindre deler. De aller fleste prosjekter har en fil som har alle variabler som brukes. _vars.scss kan den hete feks, der finnes det som regel variabler til farger, typo-størrelser, paddings, margins og breakpoints. La designeren få lov til å justere helt til man er fornøyd i den filen. Dette er ikke mye, men veldig ofte er det dette som er vanskeligst for en utvikler å oversette fra dine skisser. Pluss at, begynner designeren med dette, så er det lettere å se hvordan andre ting andre steder fungerer.

10 tips for å unngå at designere eller utviklere bytter jobb

1. Snakk sammen.
2. Forstå hverandre.
3. Hvis dere ikke forstår hverandre, snakk sammen en gang til.
4. Er det fremdeles vanskelig å forstå hverandre, involver prosjektlederen og prøv å forstå hverandre.
5. Om det rett og slett ikke går an å forstå hverandre, forbli gode kollegaer og sett sammen et nytt team og start på nytt med steg 1, eller gå til steg 6.
6. Bli enige om hvordan dere skal jobbe, hvem skal gjøre hva når, hvilke verktøy/rammeverk osv skal dere bruke.
7. Gi hverandre rom og tid til å finne ut av oppgavene deres. MEN, ikke på et rom alene, jobb åpent og del hele tiden underveis.
8. Så fort utvikleren har noe som du kan jobbe med, få hen til å sette opp alt for deg på din maskin slik at du kan bidra i koden.
9. Spør en utvikler om hjelp når du sitter fast.
10. Spør en designer om hjelp når du sitter fast.

Forøvrig handler ikke dette egentlig om designere eller utviklere. Det handler om folk. Og du kan benytte den til samarbeid med folk helt uavhengig av disiplin eller oppgave.