Det er viktig å være bevisst på hva man kan gjøre i hverdagen når man utvikler digitale tjenester. Denne artikkelen gir deg noen tips til hvordan du kan begynne å tenke mer på bærekraft i hverdagen som medlem av et digitalt produktutviklingsteam!

I dag bruker vi mye tid på å snakke om bærekraft, og da spesielt bærekraft i et miljøperspektiv. Det er likevel ikke så kjent at IT-bransjen står ansvarlig for mer enn 2% av de globale utslippene. Det er omtrent like mye som karbonavtrykket fra drivstoffutslippet til flyindustrien. 



Hvorfor skal jeg bry meg?

Det er ikke lenge siden jeg tenkte at digitale tjenester egentlig ikke påvirker miljøet. Det digitale er jo ikke fysiske produkter, så det har vel ikke noe utslipp? Men dette stemmer jo ikke. Alt som er digitalt vil på en eller annen måte også være fysisk. Det digitale er også maskinene og verktøyene vi sitter med når vi utvikler. Maskinene brukerne sitter med. Det er energien datasentrene bruker for å driftes. 

Et begrep jeg for ikke så altfor lenge siden ble bevisst på er digital vekt. Alt som er digitalt har en eller annen vekt, antall bits og bytes som til sammen utgjør tjenesten. Mange bytes veier mer enn få bytes. Hver eneste byte med data krever energi å lage- og også energi å sende og lagre. Bytes med data gir ikke noe i seg selv. Jobben vår som digitale produktutviklere er å gjøre om bytes med data til informasjon som brukerne våre forstår.



Hva kan jeg gjøre?

Vi er vant til å tenke på at vi skal levere verdi, og møte reelle brukerbehov. Men vi må også ta ansvar på en annen måte. Vi må ta ansvar for dataen, og utslippene, vi produserer. Her er noen ting du kan ha i bakhodet i hverdagen som designer, eller som medlem av et digitalt produktutviklingsteam.



Bruk lettere materialer

Her er det mange ting man kan, og burde, tenke på. Et konkret tiltak man kan gjøre er å tenke på løsningens «Page Weight Budget». Dette betyr at man rett og slett kan sette opp et budsjett for hvor mye data som blir lastet over nettet når siden til tjenesten din loader. Her kan man tenke på hvordan man kan oppnå målene for løsningen med minst mulig databruk. En god kilde for å begynne med dette er denne artikkelen fra Tom Greenwood.  Noen konkrete spørsmål du kan tenke på er for eksempel:

Hvor kompleks funksjonalitet trenger vi? Enkel funksjonalitet veier mindre. For eksempel, trenger vi bilder, animasjoner, video, eller holder det med tekst?

Hvor mye informasjon trenger brukeren? Prøv å dekke brukerens behov med minst mulig informasjon. Dette vil jo også gjøre selve brukeropplevelsen bedre!

Må vi ha høyeste oppløsning? Tenk på filstørrelsen på bilder og videoer. Hvor god kvalitet trenger det egentlig å være for at det gir verdi til brukeren?

Hvilke visuelle elementer bruker vi? Trenger løsningen en egen custom font? Hvor mye farger trenger vi? Desto mer visuelt kompleks løsningen er, desto lenger tid vil det ta for brukeren å laste ned de visuelle elementene- og desto mer data brukes.


Tenk over brukerflyt

Studer adferd og optimaliser hierarki og flyt slik at brukerne med færrest mulig sidelastinger finner frem og løser behovet sitt. Vi kan spare mye data ved å unngå at brukeren må trykke seg frem og tilbake og laste mange sider for å finne det den var ute etter. I tillegg kan vi jobbe med å bytte ut komponenter som skaper friksjon. Hvor er det brukerne sliter med å finne frem? Hva er det som gjør at de bruker lang tid på siden vår? Lag små og enkle tjenester, med god og tydelig informasjon- så brukeren ikke må gjennom mer enn nødvendig for å komme i mål.


Kan du bruke noe som har blitt laget før?

Et spørsmål vi kan stille oss selv er trenger vi egentlig et helt nytt produkt for dette? Finnes det en løsning, eller deler av en annen løsning vi kan gjenbruke eller ta i bruk i vår tjeneste?


Skru av det som ikke blir brukt!

Tenk på hvor lang levetid tjenestene man lager skal ha. Når man produserer data har man et ansvar. Og man burde ta ansvar for det til det øyeblikket det har blitt slettet. Slett tjenester og funksjonalitet som ikke brukes. Tenk over hver eneste linje med tekst, hvert bilde, og hver knapp. Blir dette egentlig brukt? Gir det noe verdi? Hvis ikke, kanskje vi kan fjerne det?





Ta ansvar

Vi må fortsette med å være kritiske til det vi selv lager. Vi må fortsette med å lage produkter som gir skikkelig bra verdi til brukerne. Samtidig må vi tenke på at vi har et ansvar for dataen vi bruker og utslippene det produserer.

Til slutt vil jeg også oppfordre til å være interessert i hvordan man kan bidra til mer bærekraftig utvikling. Det er mange steder vi kan påvirke. Designere står ofte i sentrum av det som skjer i et produktteam. Snakk med de rundt deg om dette. Med utviklerne, produktledere, kunde, og andre designere og kolleger. Designeren kan ikke løse dette alene. Vi som jobber med grensesnitt og brukeropplevelse vet ikke alltid hva som foregår under panseret, men vi kan bidra til endring også her ved å være nysgjerrige på hva vi sender og lagrer av data. Spør ofte, deg selv og andre: Hvordan kan vi forenkle dette?

Det finnes mange ting man kan tenke på, og mange gode kilder til hvordan man som designer (eller utvikler) kan bidra. Her er noen gode kilder til deg som vil lære mer:

World Wide Waste: How Digital Is Killing Our Planet-and What We Can Do About It av Garry McGovern

Håkons artikkel fra julekalenderen 2020

How to set a Page Weight Budget for a greener, faster website, Tom Greenwood

Hvordan du som designer kan begynne å tenke på digital bærekraft

Hva er egentlig greia med Webpack? I samme åndedrag hører du gjerne “loaders”, “plugins” og annen babbel. Hvilket problem er det Webpack egentlig prøver å løse?

Hva er egentlig greia med Webpack? Jeg skjønner at du spør. I samme åndedrag hører du gjerne “loaders”, “plugins” og annen babbel.

Webpack er litt mystisk. Jeg har undret når jeg trenger det, hva den lange Webpack-konfigurasjons-filen betyr og hva som egentlig foregår i praksis når Webpack er i bruk. I denne artikkelen ønsker jeg å demystifisere Webpack. Hvilket problem er det Webpack egentlig prøver å løse?


Problemet med kun HTML og JavaScript

La oss først ta noen steg tilbake - til en verden uten Webpack. Når du lager en enkel nettside med HTML og JavaScript trenger du ikke Webpack. Prosjektet er lite, og du simpelthen importerer JavaScripten i HTML-filen.



Det er greit nok når du kun har én script-tag som importerer inn JavaScripten. Det er derimot noen problemer som dukker opp etter hvert som kodebasen blir større. Som utvikler, ønsker du ikke å ha all kode i én fil, så du lager flere JavaScript-filer. For at også de filene skal fungere, må flere script-tags importeres i HTML-filen.



Du kan kanskje allerede nå ane et problem? Det er lite vedlikeholdbart å stadig legge til alle nye JavaScript-filer i HTML-filen. Ikke bare er det ork, men du må også legge inn scriptene i riktig rekkefølge. Om script2.js avhenger av script1.js, må script1.js importeres først.

Et annet problem er at ved å importere JavaScript i HTML-filen, blir alle disse variablene globalt tilgjengelig. Det betyr at de globale variablene kan bli overskrevet av andre scripter. Som utvikler er det heller ikke en løsning å legge all kode i én fil, da det er vanskelig å ha oversikt i én enorm fil.



Løsningen på avhengighetsproblemet

En løsning for import-problemet kommer fra JavaScript-kjøretidssystemet Node.js, som vanligvis kjøres på serveren. Med bruken av require klarer Node.js å hente opp riktige filer og løse opp i avhengigheter selv - ved å lete frem i filsystemet.



Selv om det fungerer på serveren, fungerer det dessverre ikke (i utgangspunktet) på nettleseren. Siden nettleseren ikke har tilgang til filsystemet, får du en feil som opplyser deg om at require ikke er definert.

Det er her Webpack kommer inn. Webpack er en modul-bundler. En modul-bundler samler (bundler) alle filer (moduler) til et format som nettleseren kan forstå. Webpack pakker om alle JavaScript-filene om til én fil. Dermed vil ikke nettleseren ha behov for tilgang til filsystemet. Webpack gjør dette ved å ta utgangspunkt i index.js, og så bytter den ut alle import-setningene med faktisk innhold. Dermed vil Webpack lage en veldig lang fil, som inneholder all koden.

La oss ta et enkelt eksempel for å vise hvordan koden Webpack spytter ut ser ut. I kodesnutten bruker jeg import, som er en mer moderne standard for å importere kode enn require. I index.js importerer jeg filen script1.js.



I kodesnutten under ser du koden Webpack spytter ut etter å ha massert innholdet koden til noe en nettleser vil forstå. Det vil være denne nye filen som importeres i index.html for å levere rett kode til nettleseren.

Her er en liten utfordring: Finner du igjen console.log-ene?



Avsluttende ord

Enkelt sagt gjør Webpack om koden din til noe nettleseren kan forstå. Dette gjør Webpack ved å ordne avhengighetene mellom filene dine.



Videre lesing

https://blog.bitsrc.io/why-learning-webpack-is-important-as-front-end-developer-247bc0ca40bd

https://webpack.js.org/concepts/

https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html

Hvilket problem prøver Webpack å løse?

Å bidra inn i prioriteringsprosessen som utvikler blir bare viktigere og viktigere.

I mange team er avstanden mellom utviklerne og forretning stor og de som faktisk kjenner til kompleksiteten ved å bygge systemer har liten påvirkning på hva som bygges. Samtidig er vi utviklere veldig komfortable med å “bare progge”, og jeg mener det er på tide å utfordre begge parter til å samarbeide bedre i prioriteringsprosessen — både på et organisatorisk og daglig nivå.

Noen av suksesskriteriene for et høytpresterende produktutviklingsteam er:

Høy grad av tverrfaglighet — alle fagdisipliner som kreves sitter i teamet.

Myndiggjort — teamet tar egne valg og må i liten grad forholde seg til annet enn de langsiktige målene til organisasjonen.

Kontinuerlige leveranser — utrulling av ny funksjonalitet er hyppig, aller helst daglig.

Fokus på å lage det riktige produktet — teamet evner å heve blikket for å sørge for at det man lager skaper mest mulig verdi.

Et produktteam som utvikler digitale løsninger kan for eksempel bestå av teamleder, produkteier, forretning, UX, og utviklere. Det er også ofte slik at hovedparten av et team består av utviklere og jeg mener det er rom for å utfordre utviklerne i teamet til å involvere seg i fokus på å lage det riktige produktet. Som utvikler har man gode forutsetninger for å bidra til at teamet har riktig fokus, samt sikre at teamet lager det som gir mest verdi for sluttbruker.

Men hvordan defineres verdi? Vel — it depends, og, det defineres gjerne ulikt av ledelsen, teamet selv og sluttbruker. Det er også derfor, “building the right product” (les mer om dette her), sannsynligvis er en av de vanskeligste tingene et team står ovenfor. Ved at du som utvikler involvere deg i større grad, kan du være med på å diskutere ulike tiltak som skaper verdi og faktisk mene noe om størrelsen/vanskelighetsgraden av de ulike tiltakene. Du som utvikler har et unikt perspektiv som er uvurderlig i diskusjonen om verdiskapende tiltak. På denne måten kan teamet fortløpende prioritere og balansere tiltak basert på verdi og størrelse.

Etterhvert som man bygger produktet kan du også mene noe om hva som må være med for å lansere funksjonalitet X. Dette er et veldig kraftig verktøy for teamet fordi flere fagfelt i samme team nå forstår hva man skal lage og hvorfor.

Hvor starter jeg?

Hvis du ikke allerede vet hvorfor dere lager tjeneste X, start med å spørre noen ™️. Når du forstår hvorfor dere lager tjeneste X kan du spørre produkteier/leder om å få bidra inn i neste prioriteringsmøte. Hvis man jobber ekte smidig skjer det prioritering daglig, både høyt og lavt, og da kan et tiltak være å ta av headsettet og prøve å få med seg litt av hva som skjer på kontoret. Hører du noen snakke om noe nytt og spennende — sleng deg på! Plutselig sitter du i en samtale hvor man faktisk prioriterer uten å i det hele tatt vite om det.

Kjære utviklerkollega — inkluder deg inn i prioriteringsprosessen!

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips.

Hvem er jeg?

Ragnhild Finsveen Liven

27 år

Lillehammer

Industriell design på NTNU i Trondheim med spesialisering i produktdesign

Har jobbet i 3,5 år (siden 2019)

Det er litt tilfeldig at jeg ble designer, egentlig. Jeg har alltid likt både realfag, psykologi og å kunne utfolde meg kreativt, så planen var å bli arkitekt eller maskiningeniør. Ved en ren tilfeldighet så fant jeg Industriell design da jeg satt og scrollet på NTNU sine nettsider mens jeg gikk på videregående. Jeg fikk med en gang inntrykk av at denne studieretningen var perfekt for meg. Så jeg søkte, kom inn og har aldri snudd meg tilbake.

Nå har jeg jobbet i Bekk i 3,5 år, hvorav det siste året har vært ute på oppdrag hos Entur. Entur er et statlig selskap som blant annet samler hele kollektiv-Norge i en tjeneste. Så du kan søke opp reiser i hele Norge og kjøpe billetter til alle tog og noen busselskaper. I tillegg kan man se alle bysykler, elsykler og elsparkesykler.

Hva gjør jeg (og hvordan)? 

Jeg jobber hovedsakelig med Entur-appen, men også litt med Enturs reiseplanlegger på web og produktet Entur Tavla. Det overhengende målet vårt er at flere skal velge å reise kollektivt og at denne prosessen skal være så enkel som mulig.

I hverdagen er det særlig to ting som motiverer meg veldig: Det ene er at det er kjempegøy å jobbe med en tjeneste som “hvem som helst” tar i bruk. Brukerbasen vår er utrolig stor og mangfoldig – noe som gjør jobben min som designer utfordrende, spennende og ikke minst veldig viktig! Vi har hatt et spesielt stort fokus på universell utforming dette året og det har utvidet horisonten min med ny empati for særlig skjermleserbrukere.

Det andre som motiverer meg er at det er kjempegøy og lærerikt å sitte i et smidig utviklingsteam hvor vi designerne sitter tett på utviklerne. Å jobbe hurtig sammen med små, kontinuerlige leveranser gjør at vi har et veldig godt moment i arbeidsprosessen. Likevel er dette også noe som jeg synes kan være vanskelig å “naile” skikkelig. Det er ikke alltid like enkelt å få til tett samarbeid i en travel arbeidshverdag hvor teamet er opptatt med sine arbeidsoppgaver. Derfor diskuterer og utforsker vi stadig hvordan vi kan få til enda bedre samhandling i arbeidsprosessen.

Hvilket tips ville jeg gitt meg selv i starten av oppdraget?

Du har masse å bidra med selv om du er fersk i arbeidslivet! Å komme inn med nye, friske idéer og perspektiver er en stor gavepakke for de du samarbeider med.

9-Dec

Today's posts

Hvordan du som designer kan begynne å tenke på digital bærekraft

Hvilket problem prøver Webpack å løse?

Kjære utviklerkollega — inkluder deg inn i prioriteringsprosessen!

Dagens designtips