Denne artikkelen utforsker utfordringene og potensialet knyttet til å oversette designforskningens noen ganger svevende og astrakte teorier og perspektiver til praktisk bruk i designhverdagen.

Når jeg tenker tilbake til tiden som designstudent på Universitetet i Oslo (UiO) er det spesielt ett minne som dukker opp - som nesten har blitt representativt for de årene. I de lange korridorene i 7. etasje på Institutt for informatikk (IFI), blant radene av små vinduer inn til professorenes kontorer, var det ett man måtte stoppe litt ekstra opp ved. Bak glasset vajet unormalt høye stabler av forskningsartikler, fra gulvet og halvveis opp til taket, og midt blant dem kunne en noen ganger skimte issen til en av professorene. Hvis en våget seg til å banke på og bli invitert inn i papirjungelen for å stille et spørsmål, ble du som oftest stående igjen som et stort spørsmålstegn i det du lukket døra bak deg. Svarene du fikk svevde så høyt at ingen av oss normalt intelligente klarte å plukke dem ned og bruke dem til noe vettugt.

Når jeg nå forestiller meg det lille vinduet inn til papirskyskrapere, og det lille hodet, melder det seg et spørsmål: Slipper den enorme mengden av kunnskap og forskning på design, som er fanget der inne, noen gang ut til den virkelige verdenen? Når det ut til oss som faktisk praktiserer designyrket?

Motivasjonen min for å skrive denne artikkelen er derfor å, metaforisk sett, klatre opp i det høye elfenbenstårnet og se om jeg kan få noen av svarene som akademia mener å tilby oss til å sveve litt lavere. Rett og slett se om de har noe for seg i hverdagen vår som designere, eller om de egentlig bare bør forbli fanget i 7. etasje på IFI?





Vi er ikke enige om virkeligheten

Hvis vi ser for oss at alle verdens forskningsmiljøer var som tusenvis av små øyer (noen nærmere hverandre enn andre), hvor det på hver av dem bor en koloni av forskere, kan en del av forskningsmiljøet på IFI sees på som en egen liten øy ved navn IS (informasjonssystemer).

På hver av øyene er det to grunnleggende spørsmål som kolonien av forskere må prøve å enes om, nemlig (1) hva er virkeligheten og (2) hvordan kan vi skaffe oss sikker kunnskap om den? (se ontologi og epistemologi). Ettersom disse spørsmålene ikke har ett enkelt riktig svar, men er heller av filosofisk karakter, vil forskere som befinner seg på øyer langt unna hverandre kunne komme til ganske ulike svar. Noe av grunnen kan være at de studerer ganske ulike typer fenomener (sosiale fenomener er ganske ulike geologiske fenomener) men også at de er grunnleggende uenige i hva naturen av det de studerer egentlig er.

Siden virkeligheten som de på IS-øya ønsker å genere kunnskap om, er relasjonen mellom menneske og teknologi, kan man si at spørsmål om hva naturen av denne relasjonen egentlig er også er grunnleggende filosofisk. Fra sin spede begynnelse har de på IS-øya blitt skylt over av tre ulike bølger, hvert sitt paradigme, som kom med hver sine svar på disse spørsmålene. Den første bølgen kom påstanden om at det materielle og sosiale er to helt isolerte ting (dualiatisk) og at påvirkning, eksempelvis teknologiens påvirkning på menneskelig adferd, flyter èn vei (deterministisk). I den andre bølgen var det heller var snakk om en slags gjensidig påvirkning som utviklet seg over tid, og i den tredje startet man å snakke om en slags sosiomateriell sammenveving av mennesker og teknologi (her starter det å bli ganske komplisert og vanskelig å snakke om på en enkel måte). Teoretisk sett ser sistnevnte på virkeligheten som et enormt nettverk der egenskapene og innflytelsen til eksempelvis en teknologisk artefakt defineres av dens plasseringen og relasjoner i nettverket. Dette kan eksempelvis bety at den får veldig ulike egenskaper i veldig ulike brukskontekster (mer om det senere).

Akademia gir oss altså innsikt i tre ulike perspektiver på menneske-teknologirelasjonen som en kan ha. Denne innsikten kan muligens være anvendbar for å belyse og forstå vår egen bransje, da spørsmål om hva relasjonen mellom det vi utvikler og brukerne våres egentlig er, og hvordan vi kan skaffe oss sikker innsikt om brukere, brukeradferd, opplevelser og lignende er noe som vi også må ta stilling til hver dag. Kanskje var det, som i akademia, etterdønninger av en bølge to som førte oss fra fossefallsmetodikken til en smidig tilnærming. Vi innså at relasjonen mellom teknologi og mennesker er mer intrikat enn at vi kan lage en kravspekk og så vil mennesker bare “rette seg inn” etter teknologien (deterministisk). Vi skjønte at teknologien og mennesker faktisk former hverandre og at denne gjensidige påvirkningen utvikler seg idet innflytelsen beveger seg fram og tilbake. Begreper og konsepter slik som OKR, smidig, teste i prod, MVP, personas, brukersentrert utvikling, deltagende design, å våge å feile, generisk teknologi - er alle ting som springer ut av en bestemt oppfatning av relasjonen mellom mennesker og teknologi. Uten å nevne noen spesifikt, vil jeg si at det fortsatt finnes selskaper i Norge som bygger hele sin businessstrategi rundt et svært teknokratiske perspektiv, der de tar for gitt at det teknologi determinerer menneskelig adferd.

Et forsøk på å kategorisere det litt.



I arbeidshverdagen kan man oppleve at ulike mennesker vi samarbeider med også kan ha ulike perspektiver på dette. Noen surfer litt på bølge 1, setter pris på personas, mens andre mer på bølge 2, foretrekker å brukerteste i produksjon og ikke med prototyper. Mange av diskusjonene og uenighetene man kan ha i et team, eller med en interessent, når vi skal prøve å overbevise om verdien av å gjennomføre kvalitative intervjuer eller argumenterer imot at kvantitative OKR-målinger er den eneste fornuftige måten å ´bevise´ verdiskapning på, har også i realiteten en filosofisk komponent. Dersom du tror på enkle og stabile årsakssammenhenger i relasjonen mellom menneske og teknologi (første bølge), vil du naturlig være opptatt av å observere og måle disse sammenhengene. Hvis du derimot mener at virkelighetens natur er mer rotete, stadig endrende og at mennesker både tilpasser seg selv, og tilpasser teknologien til eget bruk og brukskontekst (andre bølge), vil du være mer skeptisk til reduksjonistiske fremstillinger av bruk og brukere, og kanskje være mer opptatt av å supplere med kvalitativ innsikt. Et eksempel på dette kan man lese i Don Norman sin nye bok som kritiserer folk som går i en av to feller (i) Hvis jeg ikke kan måle det, så er det ikke viktig! eller (ii) Dersom det er noe i nærheten som kan måles så later jeg bare som at det var det jeg hadde tenkt til å måle helt fra starten!



Kan vi lære noe nyttig av den tredje bølgen da?

Hvilken av disse bølgene vi surfer på, påvirker altså hvilke metoder og verktøy vi anser som gode. Mange av de vi benytter oss av i dag, passer med svarene som den andre bølgen gir oss på menneske-teknologirelasjonen (smidig, brukersentrert osv). Hva hvis vi adapterer det enda mer teoretiske sosiomaterielle perspektivet? Ville det da vært andre og nye metoder, verktøy og tilnærminger som ville fremstått som fornuftige å ta i bruk?

Først litt mer forklaring av det sosiomaterielle perspektivet. Som beskrevet tidligere så hevder dette perspektivet at virkeligheten er et komplekst sosiomaterielt nettverk der eksempelvis en teknologisk artefakt får bestemte egenskaper og evne til å påvirke sine omgivelser i kraft av sine mange relasjoner i nettverket. Det legges også vekt på at virkeligheten er noe som oppstår og vedlikeholdes gjennom folks praksis. La meg gi et eksempel: Jeg jobber i et team med en kollega som heter Markus, som er blind og bruker et Braille-tastatur. Ut i fra den sosiomaterielle forståelsen vil tastaturet kun eksistere som et leseverktøy i relasjon til blant annet en riktig kodet nettside, internett, strøm og Markus, og først når han tar det i bruk på en bestemt måte. På samme måte er det også først i relasjonen med Brail-tastaturet og Markus sin bruk at nettsiden får egenskapene av å være en tilgjengelig nettside. Med andre ord gir det ikke mening å forstå hva noen av disse tingene er om ikke det er i relasjon til hverandre.

Det er en rekke teoretiske konsepter innenfor det sosiomaterielle paradigmet som er ment å gi oss noen analytiske verktøy for å forstå og forklare virkeligheten (empirien). Mange av disse er særs svevende og abstrakte, og den praktiske nytten de kan ha i å gjøre mening ut av designvherdag våres er en utfordring. Ett konsept som jeg synes er interresant, og som jeg tenke å utforske videre heter Body Multiple. “Enkelt” forklart beskriver konseptet hvordan den “samme tingen” manifesterer seg som ulike ting i ulike kontekster og praksiser, og hvordan “tingen” til og med kan være to motstridende ting samtidig. For å undersøke nytteverdien av dette konseptet tok jeg på meg “Body-multiple” brillene for å se på min egen arbeidshverdag og tidligere erfaringer. To eksempler viste seg særlig interessante:



Et team jeg jobbet med hos en stor offentlig organisasjon, som utviklet et saksbehandlingssystem for saksbehandlere på sentraler i hvert fylke i Norge, oppdaget at avstanden deres til brukerne var mye større enn de trodde. Med team medlemmenes IT-utdanning og praksis som utviklere og designere, samt verktøyene de brukte, som Figma og Github, fremstod saksbehandlingssystemet for dem som et "minimum viable product", med egenskaper slik som å være enkelt og raskt å tilpasse og endre. Etter at saksbehandlerne ble intervjuet i forbindelse med en rapport (gjenomført av noen eksterne) viste det seg a det på ingen måte var en smidig MVP for saksbehandlerne, med sin bakgrunn og i sin praksis, opplevde de heller at systemet hadde egenskaper som statisk og vanskelig å tilpasse til egne behov. Disse to versjonene eksisterte parallelt, uten å trenge å møtes - helt til rapporten ble laget.

Da jeg intervjuet flere personer tilknyttet utviklingen av en helseteknologi, ble jeg fortalt av IT-bedriften selv at teknologien og produktene deres var såkalt generiske og enkelt kunne implementeres i ulike sektorer i kommunene, fra energi til helse. Kommunene på sin side hevdet at potensialet for besparelser som lå i enkelt gjenbruke teknologien i mange av kommunens områder, gjorde den genial. Imidlertidig, da jeg snakket med sykepleierne, som brukte systemet, åpenbarte det seg jeg en helt annen versjon av teknologien. De hadde blant annet lagt til seg mange workarounds for å få systemet til å fungere etter sine behov. Sykepleierne hadde til og med gitt systemet et eget kallenavn for å gjøre narr av dets ubrukelighet. Begge disse versjonene eksisterte helt fint parallelt, og til min forbløffelse vant den ene versjonen til og med en Smart By-pris. Til sykepleiernes forargelse valgte de å plassere denne prisen inne på et kott.



Poenget som jeg synes disse eksemplene belyser er at praksis, verktøy, metoder og bakgrunn påvirker hvilken versjon av produktet vårt som kommer til syne. Eksempelvis kan det være en smidig MVP for teamet men for brukerne er det bare et “drittsystem”. Målene dine for suksess og verdiskapning, eksempelvis ved bruk av OKR, gir deg også én spesifikk versjon og ikke nødvendigvis hele bildet. Som illustrert i det foregående eksempelet, til tross for at kommunen oppnådde økonomiske besparelser og vant priser, var de “blinde” for den versjonen av produktet sitt som sykepleierne og pasientene måtte hanskes med.

Disse to eksemplene hinter til at det sosiomaterielle konsepter, slik som body multiple, kan gi noen nye perspektiver på materialet vårt (teknologi, adferd, opplevelser osv) som er interresante, og spørsmålet blir videre om hvilken praktisk nytte dette i så fall kan ha. Vil dette kunne føre til at vi utarbeider noen nye praktiske tilnærminger, metoder og verktøy i designhverdagen våres? (slik vi så med overgangen fra fossefall til smidig).

For min del, når jeg tok “Body-multiple” brillene på, så jeg verdien av metoder og verktøy som bygger broer mellom “ulike versjoner” på en fornuftig måte for å skape et mer helhetlig og forståelig bilde av produktet vårt. Ulike interessenter som jobber med strategi, økonomi, regelverk, utvikling og brukerne kan jobbe med ganske “ulike versjoner” av produktet, og vår rolle som designer kan være å forstå dem alle og sy dem sammen på en fornuftig måte.

For eksempel kan en smidig MVP først oppstå for saksbehandlerne når de har tilegnet seg den nødvendige forståelsen, verktøyene, etablerte praksiser og innflytelsen som muliggjør en smidig tilpasning av teknologien. Videre følger en liste med noen eksempler som teamet jeg jobbet med gjorde for å forene saksbehandlernes versjon med sin egen versjon av systemet:



Laget en veldig enkel nettside som presenterte personene i utviklingsteamet og forklarte om smidig metodikk, som ble delt bredt ut blant saksbehandlerne.

Holdt regelmessige demoer tilgjengelig for alle saksbehandlerne, der smidig metodikk også ble formidlet.

Brukte felles kommunikasjonskanaler på Teams. I et forsøk på å bygge opp tapet av tillit fikk flere saksbehandlere også en direkte inngang til teamet gjennom Slack i en begrenset periode.

Dro på en turné til flere av saksbehandlerne rundt omkring i Norge, for å samle innsikt og bygge relasjoner.

Opprettholdt regelmessig kontakt med brukerne gjennom intervjuer og observasjoner.

Viste tydelig at de tok tilbakemeldingene teamet mottok på alvor slik at de ulike kanalene for tilbakemeldinger faktisk ble et verktøy for smidig utvikling også for saksbehandlerne.

Så… har det noe for seg?

Når vi så vender tilbake til det opprinnelige spørsmålet om hvorvidt forskning kan tilby noe som virkelig er nyttig i vår designhverdag, blir det første som gjør seg gjeldende at forskningens verden kan være ganske utilgjengelig og krevende å skulle "oversette" til en praktisk hverdag. Hvis du følte at noe i denne artikkelen var krevende å lese, vil jeg på ingen måte anbefale å dykke inn i jungelen av forskningsartikler. Likevel har jeg identifisert to aspekter som jeg finner verdifulle.

For det første bidrar den forskningen som jeg forsøkte å sette meg inn i til å sette ulike perspektiver på teknologi og teknologisk utvikling i system. Personlig har dette bidratt til å utfordre og utvide min egen forståelse av hvorfor jeg kan oppleve frustrasjon over produktlederen min sitt overdrevne fokus på kvantitative målinger, som eneste indikator på om det vi har skapt er en suksess. Det har også kastet lys over hvorfor vi kan være uenige om bruken av personas  hvorfor en kollega mener at vi ikke lenger bør utføre brukertesting med prototyper eller at innsikt alltid må betraktes som ferskvare.

For det andre har forskningen tilført meg en alternativ tilnærming til å forstå teknologi og teknologisk utvikling. Dette har gjort meg mer bevisst på hvordan verktøyene og metodene vi bruker alltid fremhever én bestemt versjon, som skjuler og kan gjøre oss blinde for eksempelvis den utilgjengelige, miljøskadelige, personvernsitride eller lite brukervennlige versjonen av produktet som kommer til syne andre steder. Slike nye perspektiver på forholdet mellom teknologi og mennesker kan muligens bidra til å lede oss vekk fra en forenklet og tallbasert forståelse av virkeligheten, som dominerer mange deler av bransjen, og mot nye tilnærminger og verktøy som tar hensyn til den sosiomaterielle kompleksiteten i produktene våre.



Så ja, designforskning har noe for seg også for oss, forutsatt at man er villig til å ta på seg den betydelig utfordrende oppgaven det er å klare oversette det til noe praktisk nyttig!











Referanser:

Einar Duenger Bøhn. (2020, 16. juli) ontologi. https://snl.no/ontologi

Heine Alexander Holmen. (2022, 4. september) epistemologi.

https://snl.no/epistemologi

Law, J. (2004). After Method Mess in Social Science Research. Routledge.

Law, J. (2009). Actor Network Theory and Material Semiotics. In B. S. Turner (Ed.), The New Blackwell Companion to Social Theory (pp. 141–158).

Mol, A. (2002). The body multiple: ontology in medical practice. Durham: Duke University Press.

Norman, D. (2023). Design for a Better World. The MIT Press

Orlikowski, W. J., & Scott, S. V. (2008). 10 Sociomateriality: Challenging the Separation of Technology, Work and Organization. The Academy of Management Annals, 2(1), 433–474.

Designforskning - har det noe for seg?

Fra barndommens dager har jeg alltid vært drevet av nysgjerrighet og gleden ved å fikle og bygge ting. I denne bloggposten deler jeg min nostalgiske reise med å skape et laserprojektor-drevet Pong-spill. Og når du har en makerspace på Bekk som lekeplass, blir ingenting umulig. Bli med på en reise fra idé til ferdig produkt.

Jeg har alltid vært interessert i lyd og lys. Da jeg var 12 år brukte jeg sparepengene mine på å kjøpe røykmaskin, diskokule, strobelys og en laser spirograf. Jeg fikk miksebord til jul og rigget om kjellerstua hjemme til et diskotek. Jeg var et sånt barn som skrudde opp alt mulig for å undersøke hvordan det egentlig fungerte. Det gjør jeg fortsatt, også bygger jeg ting...

En ting som fasinerte meg spesielt, var laser spirografen. Den besto av en enkel mekanisme med en laser diode og to motorer med hvert sitt vinklede speil på enden. Laserstrålen var pekt slik at den gikk via de to snurrende speilene. Snurret et speil tegnet den en sirkel, og når begge speilene snurret ble resultatet mønstre likt det man får med en spirograf  på papir.


En spirograf er et geometrisk tegneverktøy bestående av en indre ring og tannhjul. Den brukes til å lage intrikate mønstre ved å føre en penn gjennom sporene mens man roterer tannhjulene.



Laserprosjektor sier du?

20 år senere snubler jeg over en bloggpost om hvordan man kan bygge sin egen laserprojektor.  Jeg tenker tilbake på diskoteket jeg bygde i kjelleren, og synes dette virker utrolig kult. Jeg bestemmer meg for at dette er noe jeg må prøve å lage selv.



Men hvordan fungerer det egentlig?

En laserprojektor kan tegne opp bilder og animasjoner ved hjelp av laserlys. Dette er mulig ved hjelp av to galvo-motorer som styrer hvert sitt lille speil. En Galvo-motor er en type motor som kan rotere svært raskt og nøyaktig til gitte posisjoner innenfor en begrenset vinkel. Motorene med speil står vinkelrett over hverandre, slik at det ene speilet vil flytte laserstrålen horisontalt langs x-aksen og det andre flytter strålen vertikalt langs y-aksen. 

Ved å bevege laserstrålen i x og y aksen i kombinasjon med å skru av og på laseren, er det mulig å tegne rette linjer mellom to punkter. En rimelig Galvo-motor er rangert i området rundt 20 Kilopulser per sekund. Det betyr at den i teorien skal kunne flytte laserstrålen til 20 000 forskjellige punkter i sekundet. Ved å tegne linjer mellom flere punkter, kan man lage strektegninger og animere disse.

Det trengs en del verktøy

I Bekk er vi så heldige at vi har vårt eget makerspace. På "Verkstedet" som det blir kalt, har vi flere forskjellige maskiner og verktøy. Det er 3D printer, laserkutter, CNC fres, utstyr for å lage elektronikk og mer. Dette passet perfekt nå som jeg skulle bygge min egen laserprojektor.



Hvordan bygger man egentlig en laserprosjektor?

Deler ble bestilt inn fra Aliexpress og satt sammen etter guiden jeg hadde funnet tidligere. Jeg brukte Fusion 360 til å teste og designe delene som trengtes til montering. Fusion 360 er et kraftig 3D CAD verktøy som gjør det mulig å modellere og analysere deler i 3D før produksjon. Når alt var ferdig designet produserte jeg de forskjellige komponentene ved hjelp av laserkutter og 3D-printer.



Noe for fagdagen?

Nå var laserprojektoren ferdig, men jeg følte at jeg måtte gjøre noe mer. Jeg bestemte meg for å melde inn en stand på den neste fagdagen i Bekk. Fagdagene arrangeres et par ganger i året, og er litt som en mini konferanse med talks, stands og sosialisering. Etter litt brainstorming landet jeg på at det hadde vært kult å lage dette som et laserspill som kunne stå fremme hele dagen.


Hva om jeg lagde et retro spill?  Laser Pong!!!!

Etter litt frem og tilbake bestemte jeg meg for å lage det ikoniske arkadespillet Pong. Atari som produserte spillet tidlig på 70-tallet laget det som et enkelt bordtennis simulering spill der to spillere styrer hver sin vertikale racket. En ball beveger seg frem og tilbake mellom spillerne, og hver spiller har en kontroll for å styre racketen sin opp og ned. Målet er å treffe ballen slik at den går forbi motstanderens racket og treffer bakveggen, når dette skjer får spilleren et poeng. Den som først når en forhåndsbestemt poengsum vinner spillet.







Spillkontroller var en utfordring

For å spille Pong trenger man en spillkontroller. Heldigvis hadde jeg flere deler liggende fra et tidligere havarert hobbyprosjekt. Første steg var å lage en prototype på papir. Det var viktig å finne et bra oppsett for knapper, lys og poengvisning. Jeg brukte et gratis online verktøy Boxes.py til å generere utkastet til kassen. Layouten til kontrolleren ble tegnet inn på lokket, og tilslutt laserkuttet jeg alt i sort mdf og plexiglass og monterte det sammen.

Både kontrollen og laserprojektoren er styrt av hver sin Arduino mikrokontroller. Kontrollen og projektoren kommuniserer ved å sende meldinger frem og tilbake via en vanlig hodetelefonkabel. Et problem når man lager elektronikk er at det ofte dukker opp feil, og gjerne i kombinasjon med bugs i koden. Hardwareproblemer har vist seg å være tidkrevende og vanskelig å finne ut av. Det ble mange sene kvelder med koding, feilsøking og hat, men til slutt hadde jeg endelig et fungerende Pong spill.

Jeg trenger vel et par spirografer?

Et par år tidligere hadde jeg startet på et prosjekt for å gjenskape laser spirograf fra barndommen. Dette passet veldig bra til Laser Pong spillet, og endelig fikk jeg det lille dyttet jeg trengte for å få denne ferdig.

Laser spirografen bygger på samme prinsipp som spirografen jeg hadde 20 år tidligere. Forskjellen er at min versjon også skulle ha et speilhode som lot den styre mønsteret rundt i rommet. Den er designet med samme fremgangsmåte som laser projektoren, men for å få alt til å fungere måtte jeg også lage et kretskort fra bunnen av. Jeg designet kretskortet i Eagle PCB og produserte det via DirtyPCB.

Jeg endte opp med å lage to laser spirografer. Spirografene er satt opp til å kommunisere med projektoren, og dette gjør at de kan reagere på hendelser i spillet. F.eks gjøre en spesiell lyseffekt når en spiller bommer.


Kommer det til å fungere?

Så var dagen kommet. Den siste ledningen ble loddet på plass kvelden før, og spillelisten med arkademusikk var klar. Jeg hadde fått et eget rom til å kjøre utstillingen, og mot alle odds fungerte alt som det skulle gjennom hele dagen. Det ble en stor suksess og Laser Pong var en realitet.



Lær deg noe nytt, bli selvbygger!

Jeg anbefaler alle som har en interesse for å bygge noe på egen hånd, om å bare kaste seg ut i det. Jeg kunne lite om elektronikk før jeg startet, men man lærer så utrolig mye av å bare prøve seg fram og løse problemene underveis. Det finnes enormt med bloggposter og guider på internett, og det er lett og billig å få tak i deler. Det finnes også flere tilgjengelige makerspace og biblioteker i de fletse større byer og her får du tilgang til maskiner som 3D printer og laserkutter. Følelsen av å lage noe fysisk som ender opp med å fungere sånn som man har tenkt. den er helt magisk.

Fra Laser- til mekanisk Pong!

Nå jobber jeg på et nytt hobbyprosjekt. Etter inspirasjon fra denne lager jeg en mekanisk versjon av Pong. Kanskje dukker det opp en artikkel om dette i neste års julekalender?









Laser PONG!

Designsystem har vært i vinden de siste fem årene. Omtrent samtidig med lanseringen av Googles Material Design 2, og flere andre selskapers tilgjengeliggjøring av deres egne designsystemer, så ble begrepet designsystem allment kjent i bransjen. I Norge har vi f.eks. NAV sitt designsystem Aksel.

Et designsystem består av:

Visuell profil - Blant annet dokumentasjon og eksempler på fargevalg, teksttyper, stil og fremtoning.

Verktøy - Det en bruker for å kunne bygge, vedlikeholde, dokumentere designsystemet, samt kommunikasjonsverktøy.

Komponentbibliotek - Forhåndsdesignede, gjenbrukbare byggesteiner som brukes til å designe brukergrensesnitt.

Retningslinjer - Viser do’s and dont’s, og for eksempel oppførselen til komponenter med animasjon og lignende.

Mennesker - Designere, utviklere og produktutviklere. Menneskene som sørger for at designsystemet holdes i live og videreutvikles.

Kort fortalt kan et designsystem beskrives som en kilde til sannhet som forteller hvordan en virksomhet skal oppleves på analoge og digitale plattformer. I denne artikkelen kommer jeg primært til å fokusere på retningslinjer og komponentbiblioteket til et designsystem.

Hvorfor skal man ha et designsystem?

Et designsystem kan ha sine fordeler for organisasjonen.

Én kilde til sannhet

Uten et designsystem kan det oppstå uklarhet i hva som er “siste versjon” av for eksempel komponenter og retningslinjer. Vet å ha det dokumentert i designsystemet, så kan en alltid referere til det. Med et designsystem som kontinuerlig videreutvikles, så trenger en også å bare gjøre endringer ett sted, og det blir enklere å oppdatere i fremtiden.

Ved å ha én kilde til sannhet, så vil det bli et mindre behov for å standardisere og organisere designet på tvers av team og flater, siden dette er noe designsystemet tar seg av. Dette skaper også visuell likhet på tvers av forskjellige typer enheter, skjermer og applikasjoner.

Effektivisering

Med et fungerende designsystem, så kan en spare tid med å bruke komponenter om igjen og en unngår dobbeltarbeid der en må designe den samme tingen flere ganger for å brukes flere steder. Dette frigir tid for både utviklere og designere, som da kan brukes til å skape gode brukergrensesnitt og gode brukeropplevelser, fremfor å bruke tid på valg av farger, fonter, utforming av komponenter, osv.

Hvis man i tillegg bruker design tokens for å bygge opp komponentene, så blir også skille mellom design og utvikling mindre, som også er tidsbesparende.

Universell utforming

Designsystemet kan bidra til at organisasjonen oppfyller diverse krav til universell utforming. Ved å tenke UU fra bunnen av når man bygger opp komponentbiblioteket til et designsystem, så sikrer man seg at alt som benytter seg av designsystemet også opprettholder et minimumsnivå av universell utforming.

Et par tips

Et kontinuerlig arbeid

Når man jobber med et designsystem, så bør man tenke på det som et hvilket som helst produkt et team utvikler. Eneste forskjellen er at dette produktet er ment for intern bruk. Som andre produkter, så kreves det kontinuerlige forbedring for at produktet skal skape verdi og ikke bli utdatert. De samme prinsippene gjelder for interne verktøy som for eksterne verktøy.

Tenk MVP

Det er lett å la seg rive med når en ser andre designsystemer som har et nærmest uendelig antall komponenter som dekker alle mulig behov, men når en skal starte på et designsystem, så er det beste å starte i det små. Tenk MVP og start med det minste, og der det dekker det “største” minste behovet, så bygger en videre derfra. Et komplett ferdig designsystem er ikke et mål i seg selv og som tidligere skrevet, så kreves det kontinuerlig arbeid for å ha et designsystem som gir verdi.

Du kan ikke dekke alt

Det er ikke nødvendigvis alt som skal inn i et designsystem. Hvert produktteam har egne behov, og designsystemet bør ikke oppleves som begrensende. For å unngå dette, så er det lov å gå utenfor malen hvis et team trenger en helt spesifikk komponent, som kan leve utenfor designsystemet. Dersom det over tid blir en komponent flere team også ønsker å benytte seg av, så kan den da bli implementert i designsystemet, slik at alle teamene benytter seg av den samme komponenten.

Det krever laginnsats

Et designsystem kan fort bli utdatert hvis det jobbes med en gang, og så vedlikeholdes det ikke av et dedikert time. En måte å unngå dette på kan være å sette sammen et eget team for designsystemet, som består av designere og utviklere fra forskjellige team. Da kan hvert teammedlem representere teamet de sitter i til vanlig og på den måten sørge for at designsystem-teamet kontinuerlig får innspill på behov og forbedringer fra de som tar designsystemet i bruk. På denne måten, så vil designsystemet reflektere organisasjonsen nåværende behov og holde seg oppdatert.

Og helt til slutt

Ikke kast bort tid på å bygge et fullstendig designsystem inspirert av en annen organisasjon sitt designsystem. Mest sannsynlig har dere egne behov, og dere trenger kanskje ikke 8 forskjellige knapper å velge mellom. Et designsystem er et levende produkt for organisasjonen, og bør reflektere de nåværende behovene organisasjonen har.

Designsystemer og hvordan de kan hjelpe din virksomhet

CSS Grids er nå godt støttet av alle moderne nettlesere. Hensikten med Grids er å designe layouts over to dimensjoner. Men uansett hvor mange dimensjoner, ender jeg nesten alltid opp med å ty til en Flexbox.

Faktisk lærte jeg Flexbox før jeg lærte meg CSS, som en del av pakken til React Native. Og når jeg begynte å jobbe med webutvikling, tok det tok ikke lang tid før du så meg Flexboxe alt.

Innføringen av Grids har endret spillereglene noe, i hvert fall på større skjermer. I følge lærebøker og bloggposter skal Grids skal løse mye av det Flexbox ikke fungerer så godt til – layouts over to dimensjoner. I praksis er det verre, og jeg opplever å fungere som en forutsigbar språkmodell. Putt meg foran et display:, og du kan vedde på at setningen sluttes med en flex.

Dette sitter dypt. Så i det siste har jeg prøvd å notere meg tilfeller der jeg først prøvde meg på en Flexbox, angret, refaktorerte koden og endte opp med en skikkelig solid Grid.

Her er tre Grids for generasjon Flexbox.

1) Kortkomponent

Her er en typisk komponent; du har et ikon, en tittel og en beskrivelse. Kall det gjerne et «kort»:

Jeg implementerte nylig et slikt kort, og valgte først å bruke Flexbox. Koden har du her:



Dette fungerte fint. Tilsynelatende! Kodeeksempelet over er redigerbart. Prøv å skrive en lengre tittel, og du kan se at ikonet blir bitte, bitte lite. Det viser seg nemlig at flexboxen flexer for mye! Heldigvis hadde jeg et triks på lager for å unngå ikonkrymping:

Voilà, ikonet krymper ikke lenger! Allikevel sitter jeg igjen med en bismak. For hvorfor i all verden bruker jeg Flexbox hvis jeg ender opp med å skru av selve fleksingen?

Refaktorert med Grids

Her er det samme kortet, bare skrevet med en Grid i stedet for Flexbox:

For det første, legg merke til at vi har kvittet oss med div-en som omringet tekstelementene. Færre HTML-elementer er alltid fint for lesbarheten. For det andre er ikke Griden fleksibel, så ikonet får alltid sin tildelte 1rem med bredde, uansett hvor mye tekst vi skriver inn i kortet.

Som en bonus har jeg også lagt til en gammel kjenner fra Flexbox, align-items: center, som sørger for at ikonet alltid er på linje med tittelen. Nydelig.

2) Søk og filter

Du har kanskje laget dette layoutet før. Du har en liste med ting, og trenger et søk og filtreringsmuligheter for å snevre inn treffene. Over listen ønsker du å vise antall treff.

På mobil er dette enkelt, for alt går i én kolonne. Men på større skjermer ønsker du filteret i en kolonne til venstre, og resultatlisten i midten:

Her er et eksempel på hvordan man kan løse dette med Flexbox. Vi legger kolonnene i hver sin div. På store skjermer plasserer vi dem ved siden av hverandre, og lar hver kolonne også være sin egen vertikale Flexbox. Endre gjerne på vindusstørrelsen for å se selv.

Legg merke til at de to kolonnene fungerer uavhengig av hverandre. Hvis vi ønsker å sørge for at filteret og listen starter på samme linje, måtte vi ha sørget for at søkefeltet og antall treff har akkurat samme høyde. Det blir fort vrient å vedlikeholde.

Refaktorert med Grids

Her er et alternativ til koden over, bare løst med Grids.

Med Grids slipper vi å opprette egne divs for hver kolonne – de er heller bygget inn i rutenettet som vi definerer med grid-template-columns.

Én utfordring med dette er at rekkefølgen på HTML-elementene blir feil, siden Grid-algoritmen fyller ut hver rad etter tur, fra venstre til høyre. For å fikse rekkefølgen bestemmer vi derfor noen grid-areas, og sier at filteret skal ligge under søkefeltet. Resten av elementene følger gridens naturlige algoritme og havner der vi forventer dem.

Som en bonus setter vi align-items: center slik at søkefeltet og «antall treff» alltid havner på samme linje. Da må vi også definere et unntak for filteret og listen, slik at de justeres til starten av raden sin.

I sum får vi omtrent like mye CSS som Flexbox-alternativet, men mindre og ryddigere HTML. Jeg begynner å like Grids!

3) Poengtavle

Idéen med denne komponenten er ganske enkel; du har en kolonne med navn til venstre, og en kolonne med poengsummer til høyre:

Listen bør være kodet med semantiske listeelementer (ol og li) for å bevare tilgjengeligheten for skjermlesere. Navnet og poengsummen på hver rad bør også stå ved siden av hverandre, slik at rekkefølgen gir mening for skjermlesere.

Dette er vanskelig å løse med Flexbox. Hvis vi legger listene i én kolonne og poengsummene i en annen, bryter vi opp HTML-strukturen. Hvis vi lager én Flexbox per rad, vil de være uavhengig av hverandre, og det blir vanskelig å justere poengsummene vertikalt. Vi kan hardkode lengden på navnene, men da blir løsningen lite dynamisk for navn med ulik lengde.

Grids, derimot, løser dette kjempefint:

Her definerer vi opp et rutenett med to kolonner, og fyller hver rad med navn og poengsum. I HTML-en er disse elementene omringet av et list item-element. For å la Grid-algoritmen hoppe over denne bruker vi display: contents.

Vi kunne satt en statisk bredde på navnekolonnen. Da ville løsningen blitt omtrent som Flexbox-alternativet vi diskuterte. Men vi kan gjøre det enda bedre. Med fit-content(25%) sørger vi for at kolonnen bare tar så mye plass som det lengste navnet, men aldri mer enn en fjerdedel av komponentens bredde.

Oppsummering

Alle disse eksemplene er faktiske komponenter jeg har laget den siste måneden. Først med Flexbox, deretter refaktorert med Grids.

Men alle eksemplene går også over to dimensjoner – og det er akkurat det Grids er laget for. Sånn sett er det kanskje ikke noen overraskelse at Grids produserer ryddigere HTML, enklere CSS og færre bugs enn tilsvarende løsninger med Flexbox.

Samtidig er det innmari vrient å endre vaner som har satt seg i muskelminne!

Kanskje du er som meg, som har brukt Flexbox til alt. I så fall håper jeg disse eksemplene har inspirert deg til å prøve en Grid neste gang du skal jobbe i to dimensjoner. Lykke til!



Obs! Det er foreløbig ikke anbefalt å ha en knapp inni et element med display: contents. Se CanIuse for mer informasjon om denne feilen.

Tre Grids for generasjon Flex

Design systems have been in the spotlight for the last couple of years. Approximately concurrent with the launch of Google's Material Design 2 and several other companies making their design systems available, the term "design system" became widely recognized in the industry. In Norway, for example, we have NAV's design system, Aksel.

A design system consists of:

Visual profile - Including documentation and examples of color choices, text types, style, and appearance.

Tools - What one uses to build, maintain, document the design system, and communication tools.

Component library - Pre-designed, reusable building blocks used to design user interfaces.

Guidelines - Showing do's and don'ts, and the behavior of components with animations, etc.

People - Designers, developers, and product developers. The people ensuring that the design system is kept alive and developed further.

In short, a design system can be described as a source of truth that dictates how a business should be experienced on analog and digital platforms. In this article, I will primarily focus on the guidelines and the component library of a design system.

Why have a design system?

A design system can have its advantages for the organization.

A single source of truth

Without a design system, there may be uncertainty about the "latest version" of, for example, components and guidelines. By having it documented in the design system, one can always refer to it. With a design system that is continuously evolving, you only need to make changes in one place, making it easier to update in the future.

With a single source of truth, there will be less need to standardize and organize the design across teams and surfaces, as the design system takes care of this. This also creates visual consistency across different types of devices, screens, and applications.

Efficiency

With a functional design system, you can save time by reusing components, avoiding duplication where you have to design the same thing several times for different uses. This frees up time for both developers and designers, which can be used to create good user interfaces and user experiences, rather than spending time on choosing colors, fonts, designing components, etc.

If you also use design tokens to build components, the distinction between design and development becomes less, which is also time-saving.

Universal design

The design system can contribute to the organization meeting various universal design requirements. By thinking about universal design from the ground up when building the component library of a design system, you ensure that everything using the design system also maintains a minimum level of universal design.

A couple of tips

Continuous work

When working with a design system, think of it as any product a team develops. The only difference is that this product is intended for internal use. Like other products, continuous improvement is required for the product to create value and not become outdated. The same principles apply to internal tools as external tools.

Think MVP

It's easy to get carried away when seeing other design systems with an almost infinite number of components covering every possible need. However, when starting a design system, it's best to start small. Think MVP and start with the smallest, where it covers the "largest" smallest need, and build from there. A complete design system is not a goal in itself, and as mentioned earlier, continuous work is required for a design system to provide value.

You can't cover everything

It's not necessarily everything that should be in a design system. Each product team has its own needs, and the design system should not be perceived as limiting. To avoid this, it's okay to go beyond the template if a team needs a very specific component that can live outside the design system. If over time, a component becomes something several teams also want to use, it can then be implemented in the design system so that all teams use the same component.

It requires team effort

A design system can quickly become outdated if it is worked on once and then not maintained by a dedicated team. One way to avoid this is to assemble a dedicated team for the design system, consisting of designers and developers from different teams. Each team member can represent the team they usually sit in and ensure that the design system team continuously receives input on needs and improvements from those using the design system. In this way, the design system will reflect the organization's current needs and stay updated.

And finally

Don't waste time building a complete design system inspired by another organization's design system. Most likely, you have your own needs, and you may not need 8 different buttons to choose from. A design system is a living product for the organization and should reflect the current needs of the organization.

21-Dec

Today's posts

Designforskning - har det noe for seg?

Laser PONG!

Designsystemer og hvordan de kan hjelpe din virksomhet

Tre Grids for generasjon Flex

Design systems and how they can benefit your organization