For å lage digitale produkter og tjenester som fungerer er vi helt avhengig av et godt samspill mellom tech og design.
Men fortsatt er det altfor mange tilfeller av fossefall, overlevering, dårlig kommunikasjon, forvirring og forventninger som ikke innfris.
Så hva kan vi gjøre for å bli mer samstemte?
#1. Løft blikket
Dette høres kanskje grunnleggende ut – men jeg har vært i situasjoner der ulike folk på teamet har forskjellige ideer og tanker om hva produktet vi lager egentlig er, hva det løser og hvem brukerne er.
I en travel hverdag med standup-møter, Jira-oppgaver og bugs som må fikses kan det være vanskelig å finne tid til å løfte blikket. Men det trengs. En samstemt forståelse for produktet, en omforent strategi, og felles mål gjør at alle de daglige oppgavene går smidigere.
Produktet eller tjenesten du jobber med må ses i en større sammenheng: Hva er strategien bak produktet? Hvem finansierer produktet? Er produktet en del av en større produktportefølje?
En produktleder vil forhåpentligvis ha kontroll på disse spørsmålene. Men det er viktig at alle på teamet – inkludert utviklere og designere – også ser de store linjene.
![image: Han inspirerte Apple, nå inspirerer han Eddie: - Sånn påvirker Dieter Rams våre prosjekter](https://www.kode24.no/images/77074926.jpg?imageId=77074926&x=0&y=0&cropw=100&croph=100&width=245&height=164&compression=80)
Han inspirerte Apple, nå inspirerer han Eddie: - Sånn påvirker Dieter Rams våre prosjekter
#2. Forstå hverandres fagfelt
En utvikler trenger ikke å bli designer. Og en designer trenger ikke å kunne skrive kode på strak arm. Men det hjelper å vite hva de ulike medlemmene på teamet jobber med.
Hvis du er designer, sitter i et standup-møte og lurer på hva “rebasing”, “refactoring” eller “hardening” er, så er det lov å rekke labben i været og spørre. Det kan også være lurt å ta en runde i Jira, se på de ulike utviklingsoppgavene, og stille oppfølgingsspørsmål.
Og hvis du er utvikler, så er det lov å spørre om tilgang til Figma, stille kritiske spørsmål om skisser og designvalg – og aller helst komme med forslag til hvordan forbedre designet.
Design er nemlig ikke bare estetikk, merkevare, logoer og farger. Design er funksjonelt og systematisk.
«Dette er sikkert smått kontroversielt å si»
#3. Utviklere er også designere
Dette er sikkert smått kontroversielt å si, spesielt i de mest hardbarka designmiljøene. Men en utvikler bør blande seg i designet så mye som mulig.
Her handler det ikke om preferanser og magefølelse. Utviklere trenger kanskje ikke å ha så mange formeninger om hva de liker – estetisk sett. Men de fleste utviklere jeg som designer har jobbet med har ofte veldig gode innspill på det funksjonelle.
Det som handler om oppbygging av komponenter, systemtankegang, gjenbruk, logikk og ikke minst ytelse. Hvordan kan vi tilpasse designet slik at det henger på greip med resten av logikken og elementene i tjenesten eller produktet?
Da jeg jobbet med designsystemet til Lyse var jeg helt avhengig av å spille ball med utviklerne. De kommer inn med et annet perspektiv på designet, og stiller spørsmål som gjør at veien fra tegnebrett og skisser til implementasjon blir mye kortere.
![image: Ber utviklere være bevisst på dark patterns: - Lag et mindre manipulerende internett!](https://www.kode24.no/images/77049578.jpg?imageId=77049578&x=10.526315789474&y=17.5&cropw=67.86703601108&croph=31.458333333333&width=245&height=151&compression=80)
Ber utviklere være bevisst på dark patterns: - Lag et mindre manipulerende internett!
#4. Snakk sammen (og still spørsmål)
Verdens beste designer og verdens beste utvikler klarer ikke å lage verdens beste produkt hvis ikke de snakker sammen. Kommunikasjon er nøkkelen til fremdrift.
Kommunikasjonen tar mange former: I Aize, der jeg er i oppdrag nå, har vi daglige standups. Vi bruker også Slack, og spesielt Huddle, til å gjøre kjappe avklaringer. Veien til Huddle er ekstremt kort. Vi setter ikke av en time og booker et møterom. Vi tar det muntlig i åpent landskap, deler skjerm, diskuterer og forklarer.
Dette fordrer at det er en kultur for å kunne dele og kommunisere på denne måten. Som designer er jeg avhengig av kontinuerlig input for å gjøre en god jobb. Noen ganger er det muntlig, andre ganger skriftlig på Slack.
Poenget er: Som designer er det umulig å jobbe i vakuum.
«Design er også en prosess.»
#5. Jobb sammen fysisk
Slack, Huddle, Discord – til og med Teams – er gode verktøy på veien til et mer samstemt forhold mellom utviklere og designere.
Vi har lært oss å jobbe digitalt, remote fra Bali eller fra hvert vårt kontor. Men jeg tør å påstå at de viktigste gjennombruddene jeg har vært med på de siste årene har skjedd når vi jobber sammen fysisk.
Og her snakker jeg ikke (nødvendigvis) om kreativ designprosess og nyskapende lappeøvelser. Det kan være så enkelt som å stå rundt en skjerm, peke og diskutere. Eller samles i et rom for å tegne løsningsforslag på en tavle.
Ikke bare løser det faglige utfordringer, det bygger også kultur og skaper en felles forståelse.
Jeg har alltid vært opptatt av tverrfaglig samarbeid. Og jeg har alltid vært opptatt av at design ikke er noe som er forbeholdt designere – design er ikke bare bokser og piler i Figma. Design er også en prosess og noe teamet gjør sammen. Derfor er vi avhengig av at alle bidrar og at vi er samstemt.
Uten utviklere, deres perspektiv og kontinuerlig dialog innad i teamet strander vi fort – og designet (eller produktet?) risikerer å ende opp i en støvete skuff.
![image: Hva bør en UX-designer kunne? "Vi er jo knapt enige om hva UX egentlig innebærer!"](https://www.kode24.no/images/75132996.jpg?imageId=75132996&x=0&y=0&cropw=100&croph=100&width=154&height=116&compression=80 640w, https://www.kode24.no/images/75132996.jpg?imageId=75132996&x=0&y=0&cropw=100&croph=100&width=245&height=185&compression=80 1024w, https://www.kode24.no/images/75132996.jpg?imageId=75132996&x=0&y=0&cropw=100&croph=100&width=308&height=232&compression=70 320w)