Learn how to input zalgo text from your keyboard instead of using those lame random zalgo generators.

If you don't know what zalgo text is, check out the previous article on zalgo text.

Activate hex-keyboard

To type fancy ź̑̓҃algo të̸̳̹́xt you must first activate hexadecimal input.

Windows

Windows is the most difficult one. 

From wikipedia: You need to add a string type REG_SZ value called EnableHexNumpad to the registry key HKEY_CURRENT_USER\Control Panel\Input Method and assigning the value data 1, then log in and off. Afterwards hold down Alt and type + and then any hexadecimal code on the numeric keypad.

Mac

On mac go to system preferences -> keyboard -> input sources -> others -> Unicode Hex Input. Change your input to this one after it is added, and just hold down Alt while typing any hexadecimal code such as u0339 finally letting go of Alt.

Linux / other unix variants

Already enabled, just hold ctrl + shift and type u followed by hex digits, then releasing the ctrl and shift.

Vim

While in insert mode -> holt  ctrl + v then let go of them both-> type the letter u followed by your hexadecimal of choice, and it will be converted into your desired unicode character.

Now what?

You are ready to cause chaos. I suggest that you stop writing meaningless commit messages, and instead write unreadable meaningless commit messages. In addition you can use zalgo input in every input field you see on the web. Witness the confusion in other web-users as your text escapes its pathetic html element boundaries. Become part of the zalgo hivemind and unleash havoc on the internet! Muhahau̷h̴a̵h̴a̸a̷̫̓h̵͓̉a̷͉̾h̵̗͒ǎ̴͕h̷̳̤͖̐̿̍̅͐̄͊̕ḁ̶̛̣́̃͋̒͋h̷̢̹͙̳́͐ą̷͍͎̲̙͔̾̆̈́̔͗͌̅̕͜ả̵̧͙̺̫̳̲͔̯̲̙̤̺͕̠͍̓̕ḧ̶̨̜̝̼̰̻͚̭͈̩͇̋̀̾͂̑̄̍̓̈͘͘͘͝͝͝a̴̡̠͉̱̟̓͑̽͌̃͝h̶̻͚̯̘͖̻̓̽̆̒̕ą̵̰̺̤̣͈͇̲͔̙̫̩͕̪͈̗̦͚̱̯̙̈̌͑͛̆̏̈́̌̌̔̚͘͠͝a̴̬̭̱͐͝h̶̡̠̬͔̹̟̺͓͈͕̩̭̥͉̪͎̼̩͙͎̓̍͛́͆̓̓̿̅̒͂̊̑͛͛̉̓̔̇̍̆̿̽̊͋̑͆̋́̋̇͜ͅą̷̨̢̛̣̼̯̥̗̯̪͍̰̣͍͖̘̥̤̰͔͎̘̈̽̒͂͐͌̃̒̿̔̿̋̀̅̓͛͂̔̈́̑̏̆͐̄̕̚͝͝͝ͅͅĥ̵̨̡̙͓̠͕̪̘̲̖͍͙̥͉̺̜̟̖̮̲̫͙͙̲͔̰̣̋̓͛̔͌͆̋̔̽͑͊̈́̉̊̇̾̇͒̀͂̔̀̾̐̓͆̕͘͝͠ą̸̨̧̛͈͈̗̲̬̜̫̼͕̹͔̮̥̮̰̲̦͉̞̩̣̐̑̏͊̎̅̉̓͑̕̚͝ͅͅ

How to type zalgo text using your keyboard

Det er mange tilfeller hvor vi som designere kan anta at brukeren egentlig ikke ønsker å gjøre det de er i ferd med å gjøre. I hvilken grad er det da vår oppgave å nudge dem, altså lede dem i en annen retning? På hvilken måte skal vi gjøre det? Og skal vi i det hele tatt gjøre det?

En liten juleskildring

Det er julegrantenning på Karl Johan og hyggelig stemning. Bak det grønne, glitrende treet får du øye på en bod hvor det står GLØGG med store bokstaver. Et par sekunders betenkningstid er nok, og du har tatt et valg. Du går rett til gløggbua og stiller deg i kø, mens tankene om den varme koppen med juledrikke opptar mer og mer hjernekapasitet. Gløgg. Du visualiserer deg selv med gløggen i hånden, etter å ha fullført stegene du vet du må gjennom for å oppnå målet du har satt deg fore. Det er som regel samme prosedyre hver gang.

Bekrefte og si "ja, takk" til mannen i bua. "Gjerne med alkohol og nøtter, men uten rosiner."

Betale. Håper de tar vipps, og at transaksjonen går fort...

Besvare med "takk og god jul til deg også", ta med deg koppen og gå.

Det blir endelig din tur i gløggbua, men idet du trekker pusten for å gi din bestilling spør mannen i boden om ikke du vil ha grønn te? Med hodet fullt av gløgg er du nær ved å svare "jatakkgjernemedalkoholognøttermenutenrosiner", men hjernen kobler om i siste sekund og du opplever en forfjamselse langt utover det vanlige. Grønn te?? Var det ikke gløgg det stod på denne bua? På disken får du øye på et lite skilt hvor det står "Grønn te er helsefremmende, og gløgg smaker høgg."

Det tar litt tid for deg å hente deg inn, og folk bak deg i køen blir utålmodige. Du kommer frem til at riktig svar på mannens spørsmål er nei takk, og slett ikke ja takk, for du skal på ingen måte ha grønn te, samme hvor helsefremmende det er. Du har tatt valget om gløgg, og ingenting kan få deg fra det. Lettere irritert stotrer du: "Jeg skal ha høgg! Nei, gløgg! Uten alkohol og med grønne rosiner."

Mannen i boden blir litt overrasket over irritasjonen til kunden sin og tenker at han tross alt bare prøver å opplyse folk om et sunnere og lett tilgjengelig alternativ når de først står der og skal kjøpe noe.

Fra skildring til virkelighet

Denne lille juleskildringen gjenspeiler situasjoner folk kan bli utsatt for ved bruk av ulike digitale tjenester. Jeg jobber for tiden med brukertesting i Utdanningsdirektoratet, og har sett eksempler på dette gjentatte ganger.

En bruker ønsker å få noe gjort, og scanner for å finne knappen som vil lede til målet. Etter å ha funnet knappen tar vaner og konvensjoner mer over i resten av flyten, og det er her det kan bli krøll hvis designere tenker det er lurt å bytte om på knapper for å nudge brukerne til å tenke seg om før de gjør et drastisk valg. Her er et generelt eksempel:

Tanken er jo god fra designernes side. Vi tenker at det blir mindre risiko ved at brukerne trykker på "Tilbake" en ekstra gang før de ser at de må trykke på sekundærknappen for å fullføre flyten. Men vi glemmer altså faren ved at brukerne tross alt har UI-konvensjonene godt innarbeidet, og er vante til at sekundærknappen er tilbake-knappen. Dermed har de fort for å trykke på denne uten å faktisk lese hva som står, og ende med å fullføre handlingen når de egentlig ville tilbake og endre noe først.

Eksempler fra hverdagen

I jobben min i Utdanningsdirektoratet har jeg sett et spesielt kritisk eksempel på dette, i sammenheng med at elever skal levere inn en prøve eller en eksamen i det nye digitale gjennomføringssystemet vi nå har fått i Norge. Hvis en elev ikke har svart på alle oppgavene i prøvesettet, men likevel trykker på "Lever" er systemet designet for å "hjelpe" brukeren til å trykke seg tilbake for å svare fullstendig på prøven før innlevering.

Jeg har flere ganger sett hvordan denne boksen skaper forvirring for elevene. Noen har faktisk klart å levere prøven sin før de har begynt fordi de har trykket på "Lever" helt i starten av prøvetiden av ren nysgjerrighet, og ønsker å komme seg raskt tilbake til prøven for å starte å svare. De trykker fort på sekundærknappen uten å lese, får levert tom besvarelse, og mister dermed muligheten til å gjennomføre prøven!

Et annet litt mindre kritisk eksempel er Spotify sin pop-up som kommer opp hvis du vil legge til en sang i spillelisten din, men visstnok har den lagret fra før. Har du fått opp denne boksen, og måttet tenke deg om grundig før du lander på hvilken knapp du vil trykke på?

Det er fordi målet for flyten er å legge til sangen, men neste steg leder deg til å snu tvert om, og dette bryter med det vi er vante med. Det blir litt som å reklamere for gløgg, men i neste øyeblikk prøve å selge inn grønn te som det mest naturlige alternativet.

Men hva bør man gjøre, da?

Jeg har diskutert dette en del med andre designere, og har landet på to særlig aktuelle alternativer.

Det første er å skrive en tydelig advarselstekst rett over knappene, men beholde primær- og sekundærknapp etter det som er naturlig for flyten.

Det andre er å likestille knappene for å tvinge brukeren til å lese alt som står, og ikke gjøre det mulig å handle etter konvensjoner.

Jeg kommer nok til å veksle mellom begge disse alternativene videre i jobben, litt ut fra hvor alvorlig det er for brukeren å bli ledet av konvensjoner i valget sitt.

Sånn. Takk, og god jul til deg også! Nå kan du ta med deg koppen og gå. Hvis du vil. Eller bli her og les gjennom en gang til. Det er opp til deg. Hyggelig om du blir, men her skal jeg ikke nudge deg i det hele tatt.

Nudging: til hjelp eller til forvirring?

Standupen din handler om så mye mer om deg og ditt - så la oss strukturere den deretter.

Av og til lærer man noe som gir øyeblikkelig mening. Så øyeblikkelig at man glemmer hvordan man tenkte frem til det punktet — at man før har gjort noe annet, og at andre ikke nødvendigvis har lært det samme.

At boardet handler om produktet vi lager, ikke om teammedlemmenes arbeid, er en sånn lærdom for meg. Første gang noen uttrykte det i ord for meg (da kontinuerlig leveranse-helt Espen Ekvang og jeg var på oppdrag sammen) var det som om jeg alltid hadde tenkt sånn. For hvordan kunne jeg egentlig ha tenkt noe annet? Da jeg for noen uker siden fikk høre en entusiastisk kollega (med-fagsjef Kristofer Selbekk) si

“I teamet mitt snakker vi om løsninga i stand-up, ikke hva vi hver skal gjøre i dag, og det ER. SÅ. DIGG!”

ble jeg minnet på — igjen — at det å jobbe _ekte_ smidig, og få til kontinuerlige leveranser er en reise. Som folk tar i eget tempo, og som på ingen måte er den samme reisen for alle. Selbekk er en mester i å motivere folk til å dele fra sine reiser, og pushe oss alle litt i samme retning, så da jeg (litt hovent) “ja, det har jeg ment lenge!” (aka to år, fra da Espen sa det til meg), sa han “skriv en bloggpost om det!”

Okei — her er den.

Å snakke om løsningen vi jobber med som team, heller enn hva hvert individ jobber med, har flere fordeler:

Det hjelper oss å fokusere på mål, og jobbe målrettet

Det hjelper oss å smelte sammen som team

Det hjelper oss å fjerne hindringer raskere

Men først: hva mener jeg egentlig med å ikke snakke om deg, men om løsningen?

Hvor mange har vel ikke vært i stand-ups om oppleves mer som en rapporteringsrunde enn en måte å synke opp? Jeg har vært i utallige stand-ups som passer den beskrivelsen, og er fortsatt innom mange sånne, når jeg besøker ulike team. Vi tar en runde, person for person, og kjører den vante runden (av og til litt forkortet, av og til litt est ut, men alltid individfokusert): hva gjorde jeg i går, hva skal jeg gjøre i dag, hva trenger jeg hjelp til. Alle står pent og venter på tur, alle har fordelt oppgaver seg i mellom, så hva de andre gjør er ikke så farlig, jeg står og forbereder hva jeg skal si i stedet for å nødvendigvis lytte så nøye. Som UX’er spisser jeg ørene litt når noen av utviklerne jobber med noe som tilfeldigvis berører meg… eller de sier at det de trenger hjelp til, er at jeg går gjennom noe i frontend som blir ferdig i løpet av dagen. Av og til ser vi på boardet underveis — og da peker hver person på “sine” lapper, og kanskje flytter vi på dem når den personen sier “ja, den kan vi flytte videre”.

Når vi bruker stand-upen til å snakke om løsningen, er det umulig å ikke forholde seg til boardet. Og da brukes også boardet til det det bør brukes til: beskrive løsningen — ikke arbeid. La meg forklare: når boardet skal beskrive løsningen, finnes det f.eks ikke egne “design-lapper”. Å skisse opp en brukerflyt beskriver ikke løsningen din, det beskriver arbeidet til UX’eren. Å ha sånne lapper i boardet er en god måte å skille ut et fag i teamet, og unngå tverrfaglighetlig på løsningen på. Når boardet skal beskrive løsningen, er alle lapper elementer i løsningen som det skal gjøres noe med (bygges på nytt, fikses på) — og stegene i boardet representerer de forskjellige tingene vi som team må gjøre med elementet for å få det ut i bruk. Analysere, definere, kode og utforme, teste, etc. Lappene bytter kanskje hender i løpet av gangen gjennom boardet, ettersom vi har ulike kompetanser og styrker, og ofte er vi flere hender på samme lapp — fordi det trengs flere hender og hoder for å få et element til å funke.

Når vi har stand-up og snakker om løsningen, kommer det dermed helt naturlig å se på lappene — for det er jo å se på løsningen vår. Vi ser på hvilke elementer vi jobber med akkurat nå, og hvordan vi ligger an. Med et helt eksplisitt trykk på vi. Stand-upen starter med å se på de lappene som ligger langt ut mot høyre — det som ligger nærmest prod og effektmåling — for det er de elementene vi har jobbet aller mest med i det siste, og dermed er mest kritiske og representerer høyest verdi. Alt som hindrer de elementene fra å bli ferdigstilt og komme ut i prod, eller å bli målt effekten av når de er ute, er det aller viktigste for teamet å prate om akkurat nå.* Jobben til teamet er å sørge for den effekten løsningen skal bidra til. Uten at vi får noe ut i prod, får vi heller ikke noen effekt. Så det gir mening da, at stand-upen vår tar tak i det, som første og fremste formål.

Dersom det er noe som blir hindret fra å gå i prod, kan den personen som har sitter nærmest den problemstillingen melde det — og teamet kan snakke om hvordan vi kommer oss forbi den hindringen.

Så går vi videre, fra høyre mot venstre. Er det få hindringer, og ting går som smurt, havner vi kanskje helt til venstre og ser på hvilke lapper fra backloggen vi kan sette i gang analyse på — og altså de elementene vi skal bygge ut løsningen med.

At jeg skal sitte og skisse på noe i dag, eller gå i et møte om designsystemet, eller at du skal i techleadforum klokken 14 — det har vi kanskje meldt på slack før stand-up (eller etter), for det handler jo bare om å være litt forutsigbar for teamet ditt på når du er tilgjengelig og når du er borte, eventuelt. Hvis det er viktig for deg og teamet ditt å melde sånne ting i stand-up, ville jeg tatt en retro asap. Da tyder det på at dere snakker for lite med hverandre gjennom dagen, og at stand-upen er hovedarenaen deres for å møtes. Varsko her! Da er dere ikke et team.

Okei — så over til fordelene med en løsningsorientert stand-up, heller enn en individorientert!

Fordel nr. 1: Det hjelper oss å fokusere på mål, og jobbe målrettet

Som et produktutviklingsteam, er jobben vår å realisere — ikke egentlig et produkt, men effekt. Vi skal oppnå mål som støtter den forretningen eller mandatet vi er tilknyttet. Det virker såre enkelt, men dæven så vanskelig det er å utøve i praksis. Hvor lett er det vel ikke å bare være seg selv nok, jobbe med en lapp, dykke ned i fag, og ta en ny lapp når du er ferdig. Eller bare se etter neste nye element som hadde vært fett å lage, og la effekten seile sin egen sjø.

Å jobbe etter effekt er sin egen bloggpost verdt (det er sitt eget store dyr) — men å ha blikk for helheten av produktet, og ikke bare lappen(e) du sitter med akkurat nå, det hjelper denne typen stand-up med. Fordi vi hver morgen jo nettopp starter med å se på “hva skjer med produktet vårt akkurat nå?”. Vi skrur fokuset vårt til å handle om løsningen hver morgen, med ekstra vekt på hva som er nærmest med å kunne bli tatt i bruk. Og dermed oppnå effekt. Vi snakker om hvordan vi kan få det vi har brukt mest tid på i det siste til å komme ut — og konsentrerer teamets innsats på å få det igjennom, og blir på den måten mer målrettet i arbeidet vårt.

Fordel nr. 2: Det hjelper oss å smelte sammen som team

Når vi slutter å melde hver morgen hva “jeg skal gjøre idag” og hva “jeg har gjort”, og heller snakker om hva “vi må gjøre for å få det elementet ferdig og ut i prod”, styrker vi teammentaliteten, nesten umerkelig. Ord er makt, og måten vi snakker om ting på, påvirker hvordan vi tenker om dem. Jo oftere vi snakker om “meg og mitt arbeid”, jo mer definerer vi det individuelle bidraget, og bygger ikke et team, men en samling personer som jobber tilstøtende på ett produkt. Et ekte team består av personer som deler samme mål. Å sammen se på lappene og hva vi må gjøre for å få elementene ut i prod, bygger opp under det.

Fordel nr. 3: Det hjelper oss å fjerne hindringer raskere

Å melde “hva trenger jeg hjelp til i dag” er egentlig et ganske heavy ansvar å gi til folk. Det krever at man selv ser sine svakheter og utfordringer, tør å melde dem, og også å forstå utfordringen godt nok til at man greier å verbalisere det til en konkret forespørsel om hjelp. Hvor ofte har du møtt en kollega som har sittet akkurat litt for lenge med en oppgave fordi det ikke ble bedt om hjelp tidligere? Eller hvor ofte har du selv sittet for lenge med en oppgave fordi du ikke ba om hjelp eller sparring tidligere? Jeg har gjort det altfor ofte selv, hvert fall. Og når det tar tid, sitter vi faktisk i en situasjon hvor vi lar hindringer bestå lenger enn de må — og vi blir et tregere team enn vi trenger å være. Når vi bruker stand-upen til å snakke om løsningen, og ikke oss selv, blir hindringer ikke et personlig spørsmål om hva jeg trenger hjelp til, men en felles diskusjon om hva som hindrer oss fra å få et element ut i prod og bli målt. Spørsmålet blir “kan denne gå ut i prod i dag, den har ligget i test siden i forigårs” — og vi som team kan ta tak i det som eventuelt hindrer den fra å gå i prod. Eller videre til peer review. Eller fra analyse til “klart for utvikling”, alt ettersom. Og fordi vi har stand-up hver dag, har vi også den praten hver dag, om de elementene som er tettest på å bli realisert.

“There’s no I in team”

…og vi trenger ikke å høre om alle møtene du skal i i dag i stand-up. Vi må snakke om løsningen, og hvordan det går med den — det er å snakke om formålet vårt som team, og hvorfor vi er her. Det høres kanskje litt høytsvevende ut, men… jeg motiveres av at arbeidet mitt har mening, og da er det ofte litt høytsvevende kontekster som driver nitty-gritty arbeid fremover. Stand-up er en del av hverdagens nitty-gritty. Du kan få den unna som kun et litt ubevisst, tradisjonelt “smidig”-rituale. Da kjører du på med vanlig “hva skal du gjøre i dag”-runde i teamet.

Eller! du kan bruke den til å bottom-up bygge en kultur i teamet ditt for å huske på hva vi er her for, samle folka til å være et ekte team, og jobbe enda mer effektivt med å komme seg forbi hindringer og skape effekt. Kjør stand-up som en runde på løsningen deres — ikke om dere.

*Denne måten å kjøre stand-up på har et navn (som en tredje kollega, mer akademisk anlagte enn meg Moquan Chen, bemerket i den samtalen mellom Selbekk og meg): Walk the board/walking the board. Sånt er ikke jeg så opptatt av, å definere en metodikk eller følge en bestemt “teori” (oppskrift) og gi ting navn — så lenge det håndverksmessig gir mening å gjøre noe på en viss måte. Men! Det betyr at du kan google det, og finne flere beskrivelser av det, om du vil lese mer om det. Mitt forslag er likevel: bare gjør det. Du er ikke avhengig av korrekte definisjoner og bransjebegrep. Bare begynn å ta frem boardet til stand-up, kikk på høyre side av boardet i starten, og spør dere selv, som team: “åkei, hvordan ser det ut her”. Mer trengs ikke, for å være i gang. Lykke til med produktutviklingen, folkens!

Hei, du! Stand-up’en din handler ikke om deg

Solenergi har stupt i pris mye raskere enn noen har spådd. Det internasjonale energibyrået (IEA) har konsekvent bommet på sine prognoser. I dagens luke ser vi på en artikkel av Ramez Naan som går grundig gjennom denne utviklingen, og hvilke konsekvenser det vil ha for energimarkedet framover.

Solenergi er en utømmelig og fornybar kraftkilde. Kostnadene for solstrøm har stupt over mange år, mye raskere enn de fleste har våget å håpe på. Spesielt er det interessant at det internasjonale energibyrået (IEA) konsekvent har bommet på sine prognoser.

I denne artikkelen gjør Ramez Naam en grundig analyse av den nåværende og fremtidige tilstanden til solenergi. Nye solparker er nå flere steder billigere enn å drifte eksisterende kull- og gasskraftverk! Kostnadene for solenergi vil sannsynligvis fortsette å synke raskt det neste tiåret, og vil bli den billigste strømkilden i mange deler av verden.

Her i Norge har solcellestrøm ikke fått skikkelig fotfeste ennå. De siste månedenes strømpriser har imidlertid ført til større utbyggingstakt, både i privatmarkedet og i industrien. Solstrøm er et veldig godt svar på framtidens økte energibehov også i Norge, ettersom vi har store mengder regulerbar kraft (vannkraft) å balansere variabel solkraft med. Mer om potensialet i Norge i en senere luke.

Solar’s Future is Insanely Cheap (2020)

Siste nytt: Etter at første versjon av denne luka ble skrevet, har IEA publisert sin rapport - Renewables 2022 - som peker på eksponensiell vekst på installasjon av fornybar energi:


Framtidens solstrøm er sinnsykt billig

During the last year or so, I've worked a more with event-driven systems. I had to learn a lot of new terms and architecture patterns, so I turned to the internet to help me out. Along the way I've found many articles that I found useful. In this blogpost I will share some of my favorites.

Intro to terms in the event-driven domain

Martin Fowler's article What do you mean by "Event-Driven"? is a nice intro to terms used when working with event-driven system. It defines "event notification", "event-carried state transfer", "event-sourcing" and "CQRS". This article also contains links to more in depth articles, and also a further reading section, so make sure to check those out!

Starting out with event sourcing

Event sourcing is not something you have to do when creating event-driven systems, but it is something that you should know about. It is an interesting architecture pattern that can have great benefits, but also be quite complex.

EventStoreDB's intro to Event Sourcing is an easy-to-read, high-level introduction to event sourcing. It also introduces other related concepts (such as domain-driven design) that are nice to know. Be aware that the article use some terminology specific to EventStoreDB and introduce the "EventStoreDB way" of doing event sourcing. It's still a very nice article if event sourcing is new to you, though.

Martin Fowler's Event Sourcing is a longer, very interesting read that goes in depth on event sourcing that I recommend reading. I've read this one many times over the last year, and I learn something new every time. Like the previous article from Martin Fowler, make sure to check out the links to related articles.

Event streaming is different from event sourcing

This article explains the differences between event sourcing and event streaming. It is a reply to the article Event sourcing is hard, which presents a mostly critical view of architectures using event sourcing. The latter article has some valid points, and even though it is conflating event sourcing and event streaming, it is worth a read.

Event streaming usually includes some form of message broker that systems can write to, and read from. Many message brokers exist and they do have different properties, different names for the same concepts. Gently down the stream is an introduction to Apache Kafka, styled as a children's book. It is general enough to be useful even if you're using another message broker.

Dealing with eventual consistency

From the CAP theorem we know that we can't have consistency, availability and partition-tolerance at the same time, but have to choose two. In many event-driven systems, that means accepting that systems are eventually consistent (because availability and partition-tolerance are usually more important). (Micro-)services benefits from being decoupled, but have to deal with these consistency issues when state changes are transmitted as events.

Cockroach Labs' blog explains how to work with duplicate events, idempotency and out-of-order events. event-driven.io has many good articles related to event-driven systems, but this article about outboxes, inboxes and delivery guarantees is especially interesting.

Getting started with event-driven systems

"Design Tip of the Day" (Dagens designtips) is a series of articles where designers from Bekk talk about the work they do, challenges they meet at work and maybe give a tip or two.

Who am I?

My name is Anders, I'm 26 years old, and have spent 1,5 of those working at Bekk. I did my Masters's degree at the University of Oslo, in a program called Informatics: Design, Use, Interaction.

I’ve always been drawn toward creating things. Growing up, I spent countless hours building complex things with Lego, taking them apart, and creating something different with the same pieces. As I grew older, I also developed an interest in technology and spent many hours staring at a screen. I wanted to work with something in the intersection of creativity and technology, in which interaction design fits beautifully.

My current client is OBOS. Since April 2021 my team and I have been developing a website for OBOS Living Lab, an apartment building built to experiment with new ways of building better housing. Right now we’re in the process of transitioning into redesigning the property listings at OBOS, to help people find new places to live.

What do I do, and how do I do it?

The fun bits

We have gotten the opportunity to build a solid interdisciplinary team, with me as a designer, developers, editors, content producers, and representatives from the business part of OBOS. Being able to gather all these great minds together has had an enormous impact on how fast and effectively we can deliver value in production. I’ve learned so much throughout the process of building the team. I also want to give a shout-out to Henning and Sindre, the developers on my team. Instead of having to spend hours in Figma, building complex wireframes and speccing spacing, they are happy to look at a rough sketch with a sharpie on a piece of paper.

The challenging bits

That being said, the process of building and putting together such a team has not been a cakewalk. As I imagine is common with most larger corporations, facilitating discussions and anchoring decisions across divisions takes a long time and can be frustrating. I have spent many hours staring at scheduling assistants in Outlook to try and find a time slot for a quick and simple discussion. For a while, I felt like I was working as a meeting manager rather than as an interaction designer. However, making people talk together is a big part of being a designer, isn't it?

What tip would you give yourself when you started at this client?

Not everything (in fact most of the things I design) has to be made in detail in Figma. Paper and a sharpie, or a rough drawing in FigJam are usually enough. And if there is a need for more details you can always do them when the need arises.

11-Dec

Today's posts

How to type zalgo text using your keyboard

Nudging: til hjelp eller til forvirring?

Hei, du! Stand-up’en din handler ikke om deg

Framtidens solstrøm er sinnsykt billig

Getting started with event-driven systems

Design tip of the day