Siri Corneliussen har sett seg lei på designere som bruker masse tid på å lage nye varianter av veletablerte komponenter, og spør: er det virkelig der vi tror vi skaper mest verdi?

Se for deg en vanlig dag: Du skal i gang med å lage for eksempel et nytt skjema og trenger innlogging, dropdowns, inputfelt og datovelger. Hva gjør du? Sjekker med designerne der du sitter? Ser i designsystemet hvis dere har et? Kanskje NAV har gjort noe lurt i sitt designsystem? Leser en bloggpost? Men, så liker du ikke helt det du finner. Komponentene i designsystemet dekker ikke heeelt ditt behov?

Vi designere tror altfor ofte at vi er så flinke og spesielle at bare vi har fasiten på hvordan noe kan løses. Det er altfor lett å kritisere det andre har gjort før deg. Finne innvendinger for hvorfor ikke dropdownen i designsystemet fungerer i akkurat ditt case. For dine brukere er så spesielle at de bare må ha en helt egen måte å gjøre ting på. Det er jo sååå lenge siden den bloggposten du leste ble skrevet at ting garantert har forandret seg! … Eller?

Hvor skaper vi mest verdi?

Jeg har jobbet med designere som har 20 varianter av én dropdown. Designere som bare må lage en ny måte å oppgi et tall på. Eller finne opp enda en måte å velge dato på. Hvordan har vi blitt så opptatt av at vår lille bit av en større helhet er viktigst? Hvordan kan vi bruke så mye tid på minimale ting i brukergrensesnittet - er det virkelig der vi tror vi skaper mest verdi? Hvorfor bruker vi så mye tid på noe som brukerne kanskje bare er innom én gang?

Internett har som kjent kommet for å bli, og nå har det også vært her en stund. Det betyr at vi har funnet på ganske mange smarte løsninger for digitale produkter. Det finnes konvensjoner for veldig mange av de interaksjonene som trengs.. Og folk har lært seg disse konvensjonene! Så hva er det vi holder på med når vi redesigner hvert eneste inputfelt?

Vi kaster bort tid!

Tid andre har brukt på å finne og lage konvensjoner, som de har testet og validert. Tid som vi kunne brukt til å gi verdi andre steder. Vi kaster bort tiden til brukerne våre. Tid de må bruke på å kognitivt tolke den lille forskjellen det er på din datovelger fra den de brukte i går hos Entur eller SpareBank 1.

Så, hva vil jeg du skal gjøre? Jeg vil at du skal bruke designsystemet til det det er ment til - byggesteiner som du kan sette sammen. Skap de gode opplevelsene rundt konvensjonene som brukerne våre kjenner så godt til. Da slipper du å bruke tid på å brukerteste og UU-teste hver minste lille bit av flyten din, og heller bruke tid på å løse andre problemer for brukerne.

Se til konvensjonene vi i bransjen har etablert, og ikke finn opp datovelgeren på nytt!

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

Hva følte du når du leste teksten? Flammet det opp noe i deg? Er du enig eller uenig? Bli med i diskusjonen på UX Norge-slacken. Husk at grunnen til at vi deler brannfakler er nettopp det å få i gang diskusjon!

Ikke finn opp datovelgeren på nytt!

Changing states is probably one of the most common things we do as javascript developers. This could be anything from checking a checkbox to closing a modal. And often we would like to show this transition between states to the end user in the form of animations. For example, you would probably want to fade the modal out before removing it from the DOM. But how does JavaScript know when the animation has ended to remove the component from the DOM?

Let's look at a simple example:

In this very simple example we have three lines of text. When the middle line is clicked, we apply a display: none to the element so that we can remove it from the DOM.

Now if we wanted to slowly fade out the text before we could instead use an animation

But now the element is never truly removed from the DOM, only invisible. So how do we solve this? We could set a timer when the text is clicked and then hide it after the duration of the animation has passed

This works, but is fragile. If we were to change the animation duration to anything else we'd either have to remember to change the timeout, or it would just disappear either too late or too early. So can we do this more robust?

Turns out we can! We can listen to the elements animationend event and hide the element only after the animation has ended.

This way, no matter what the animation duration is set to, the element will only become hidden after the animation has actually ended.

We can also listen to other animation events like animationstart, animationcancel and animationiteration. In React you can add these event-listeners with onAnimationEnd etc directly on the element.

If one element has multiple animations and you want to do different things based on which animation is running, you'd have to check in the animationend listener what state is running now, either through classes or some internal state in your javascript code.

How to time your CSS animations in JavaScript

Visste du at du kan sette opp et .NET API med bare fire linjer kode?

Jeg anser meg selv som en fullstackutvikler. Likevel har jeg de siste par årene jobbet aller mest med frontend, så jeg har mildt sagt ikke .NET i fingrene for tiden. For å være ærlig føler jeg aldri at jeg egentlig har hatt det. Men i høst kom en i teamet som jobber med markedsføring bort til meg og sa noe sånt som: «Jeg trenger regelmessig oppdatert data fra et åpent api, bare på et litt annet format, som datakilde til et annonseringsprogram jeg bruker. Jeg kan spesifisere datakilden som en url».

På grunn av diverse begrensninger kunne vi ikke lage dette som en enkel funksjon i skyen, som kanskje ville vært førstevalget (Lambda+API Gateway i AWS). Og organisasjonen bruker .NET. Så her luktet det å sette opp et enkelt .NET API. Men…«et enkelt .NET API? There’s no such thing», tenkte jeg. Masse boilerplate. Selv om vi bare trenger et enkelt endepunkt. Og som attpåtil kan ligge helt åpent, uten autentisering. Likevel, et .NET API med controllere virket i overkant overkill.

Men jeg lagde nå en lapp og la den nederst i backloggen med taggene “størrelse: medium” og “viktighet: medium-lav” og tenkte at den kan vi plukke opp Etterhvert™. Ikke et spesielt godt utgangspunkt for en ung og lovende tjeneste som drømmer om å reise til det forgjettede landet “Produksjon”.

«Har du hørt om “Minimal API"?»

Så en dag gikk jeg for å ta den rutinemessige etter-lunsj-kaffekoppen for å motvirke 14-knekken og kom i prat med en av infrastrukturlegendene i organisasjonen. Han kunne fortelle at det finnes en enklere måte å lage endepunkter på i .NET 7. Mindre boilerplate. Færre filer. Raskt å sette opp. Perfekt for mitt use case!

La det bli lys!

Det han snakket om var "Minimal API". Den aller enkleste veien for å teste ut dette er å huke av "Use controllers" når du oppretter et nytt .NET Core API i Visual Studio 2022, og ikke minst velge .NET 7.

Da får du et enkelt oppsett hvor med et GET-endepunkt, hvor alt skjer i Program.cs fila! 4 kodelinjer er alt som skal til - vel å merke for å sette opp det aller enkleste endepunktet man kan tenke seg, men likevel. Og med .NET 7 blir det meste abstrahert bort på magisk vis:

Er dette vanlig .NET Core?

Jepp! Med andre ord er det for eksempel relativt enkelt å skrive om til å bruke vanlig controllere hvis det viser seg at man trenger mer struktur, eller det er noen features man trenger som ikke er tilgjengelig med Minimal APIs.

Hva med dependency injection?

Mulig det også! Selv uten en konstruktør. Her er det mer .NET 7-magi som abstraherer bort det meste:

CRUD sa du?

Du gjettet riktig: i likhet med app.MapGet() finnes det støtte for resten av CRUD-metodene også. Under er et enkelt eksempel på hvordan man kan hente ut data fra body'en til en POST request mot /ønskeliste ruten:

Selve requesten og resultatet fra kallet ser da slik ut:

Hva med autentisering?

Autentisering i .NET Core gjelder også for Minimal APIs. Har man satt det opp er det bare å slenge på en [Authorize] attributt på endepunktet, på samme måte som man ville gjort på et endepunkt i en controller.

Blir det ikke fort rotete?

Joda, det kan fort bli uoversiktlig med alt i Program-fila. Men det er lett å organisere koden bedre! For eksempel ved å flytte ut selve logikken i endepunktene til egne service'er, som jeg så vidt var inne på ifm. dependency injection. 

Når bør man heller gå for vanlige controllere?

Godt spørsmål! Jeg aner ikke. For mitt use case var tjenesten så liten at dette føltes helt riktig. Da med alt stappet inn i Program.cs. Og for eksempel i en mikrotjenestearkitektur kan det godt hende at dette er et godt valg for noen av tjenestene hvis funksjonaliteten er begrenset nok.

Hva med (…)? Og (…)?

Les mer her! https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-7.0 



Ønsker du å lære mer om forskjellene mellom Minimal APIs og API med controllere kan du lese mer om det her: https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-web-api?view=aspnetcore-7.0&tabs=visual-studio#diff-v7

Minimalistisk API i .NET på 1-2-3-4

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på og runder av med  et godt tips 💡

Hvem er jeg?

Noen kjenner meg som tekstforfatteren. Andre som «han skribenten», UX-writeren, manusfyren eller bare en såkalt kreativ person. 

De fleste kjenner meg riktignok som Erik Mathisen, 37 år, fra Ulsrud i Oslo.

Jeg er utdannet merkekommunikatør fra det som en gang het Norges Kreative Fagskole, nå Høyskolen Kristiania.

Og jeg er inne i mitt femte år som tekstforfatter i Bekk.

Jeg ble tekstforfatter fordi jeg elsker gode formuleringer. På lik linje med en vakker matematisk formel, kan setninger romme så ufattelig mye informasjon.


Hva gjør jeg?

Kort fortalt; Jeg skriver bedre brukeropplevelser. 

Akkurat nå jobber jeg med å utvikle stil og tone for en ny app som skal hjelpe folk med å redusere karbonavtrykket sitt. Det innebærer en kontinuerlig vekting av ord, og deres utallige assosiasjoner, som også skal fungere godt sammen med visuelle komponenter. Litt etter litt finner vi ut av hva slags røst den nye tjenesten trenger. 

Å finne opp en helt ny stemme, det er en spennende oppgave. Hvor mange sider av personligheten har denne tjenesten? Kan den dra en vits, er den dønn seriøs døgnet rundt, er den støttende, sympatisk, statisk? Bruker den ord som «snerten» eller «sublimt»? Og når skal tjenesten prate mye og når burde den være helt stille? Gjort riktig er språk et viktig konkurransefortrinn. 

Litt etter litt blir den nye stemmen skrudd sammen fra kjernen av merkevarens og utover, helt fra pushvarsler og release notes i App Store til CTA-knappen i nyhetsbrevet. 


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

Ikke stress med å vise frem alt du kan med en gang, det får du mange sjanser til. Vær tilstede, still masse spørsmål og vis at du ønsker å bidra ⭐️

Dagens designtips

Hvor står vi med OKR, digital produktutvikling og produktledelse i 2022? Kommer OKR til å havne på buzzordenes kirkegård sammen med gamle venner som scrum, eller er vi i ferd med å stake ut kursen for det digitale produktteamets æra?

2022 ble, i hvert fall anekdotisk, året der "hele" Norge adopterte OKR. Fra oppstartsselskaper til store finansinstitusjoner og offentlige etater. Det er OKR du skal drive med.

Den lite rause tolkningen av hvorfor så mange selskaper starter med OKR akkurat nå, er at det er en typisk populæreffekt, eller bandwagon effect om du vil, der vi mer eller mindre bevisst hiver oss på den samme trenden samtidig alle sammen. Det ville ikke vært første, og sannsynligvis heller ikke siste gang som bransje. Men, det finnes også en annen og minst like sannsynlig forklaring.

OKR er den naturlige konsekvensen av bransjebevegelsene med smidig, kontinuerlige leveranser og autonome team.

Smidigbølgen skylte over oss for 20 år siden. Konsekvensen av å lykkes med smidig er at du beveger deg over til kontinuerlige leveranse. Har du en organisasjon med flere titalls team som alle leverer kontinuerlig, begynner det å bli blytungt å koordinerte dette toppstyrt. Autonome team tvinger seg fram både som noe bra i sin egen rett, men også som en konsekvens av at det ikke fungerer å styre så mange team når de beveger seg fort.

Så da står du der, da. Med fem, ti, tyve eller kanskje femtitalls autonome team, med sine egne prioriteringer, egne variasjoner på prosess og sin egen historie om hva de prøver å oppnå.

Som så mange ganger før sitter Big Tech på svaret! Spunnet ut av Intel på syttitallet, og senere omfavnet av selskap som Google og Twitter, har OKR nå endelig funnet plassen sin i IT-bransjens hall of fame som en av de store bølgene som fra tid til annen skyller innover oss. Og ikke ulikt tidligere bølger: når alle vi andre skal ta i bruk gode idéer fra Big Tech får vi kjenne på at det er forskjell på amerikanske teknologigiganter og de aller fleste norske organisasjoner.

Tilnærmingen til OKR varierer stort mellom de forskjellige selskapene i Norge som nå prøver det ut, og så langt ser det ut som de fleste kjenner på at dette ikke er så lett.

OKR er vanskelig. Det er ikke en detalj i den daglige arbeidsflyten, det er dypt inngripende i hvordan du prioriterer, hvordan du måler og hvordan du jobber fra uke til uke, på alle nivåer fra toppen og ned i hvert enkelt team.

OKR er et veldig enkelt rammeverk som prøver å løse et veldig komplekst problem. Det er slett ikke noe feil med det, men det gjør det også lett å tenke at dette er enkelt. I for mange organisasjoner ser OKR til å være innført som en ettertanke, men varierende grad av dedikasjon og forståelse hva som skal til for å lykkes med innføringen.

OKR & Teamene

Det skjer noe med forventningene til et team når organisasjonen innfører OKR. Teamet som i går var et vanlig utviklingsteam med teamleder og produkteier (gjerne i samme person), én designer og en håndfull utviklere, skal plutselig bli et digitalt produktutviklingsteam, som evner å jobbe effektstyrt, basert på kontinuerlig kvantitativ måling og med et dokumentert bidrag til de overordnede målene til virksomheten.

Bestillingen til teamene er ikke dårlig; for team som klarer å komme dit, er det åpenbart en god plass å være. Det er vel ingen som ikke ønsker å jobbe basert på innsikt, og vise at de bidrar til overordnede mål? Utfordringen er at det ikke er så lett å komme dit!

Det meste av OKR-litteraturen sklir lett over at måling og kvantifisering av effekt i den virkelig verden er skikkelig vanskelig. Og dermed gjør mange organisasjoner det samme.

OKR endrer produktlederrollen fundamentalt. Der produktledelse ofte har dreid seg om å forstå forretningen og bestemme hvilke initiativer som skal gjøres nå, handler den nå om måling, innsikt, kundereiser, verdiskapning og effekt.

De beste produkteierne har allerede vært der en stund, men de fleste vil streve med å nå opp til den lista. Og det er ikke så rart, for det er store krav å stille til én person. I praksis, og i de beste teamene, er produktledelse ikke lenger noe som utøves av én person. Det er oppgaven til det digitale produktutviklingsteamet.

I et digitalt produktutviklingsteam er det mindre plass til utviklere som bare vil sitte med øreklokkene på og hamre ut kode, mindre plass til designere som bare vil sitte alene i Figma og tegne ut fine løsninger som noen andre kan implementere, mindre plass til produkteiere som vil skrive inn oppgaver i Jira, og mindre plass til teamledere som tenker jobben deres er å lede stand-ups og fasiltere retrospektiver. Digitale produktutviklingsteam stiller større krav til at folk på tvers av fag samarbeider om tjenestereiser, hypotesedesign, effektmåling, adferdspsykologi og konverteringsanalyse – for å nevne noe. Og sannsynligvis krever det kompetanse vi sjelden har i teamene i dag.

Digital produktutvikling i 2022

Så hvor står vi egentlig med digital produktutvikling i 2022? Jeg tror vi står ved et veiskille. Ned den ene veien ender OKR med et rykte som minner om der Scrum har vært de siste årene. Noe mange har prøvd, og få egentlig har trua på - selv om det åpenbart har noen kvaliteter i bunn. Ned den andre tar flere innover seg at OKR er vanskelig, og at det krever mye fra organisasjonene som innfører det. På selskapsnivå, på prosessnivå og på teamnivå.

OKR åpner for at 2023 kan bli starten på det digitale produktutiklingsteamets æra. Året der det blir vanlig at team forstår målene de bidrar til og jobber basert på innsikt og formulerte hypoteser, og kan måle og dokumentere effekt av initiativer.

Det er fortsatt grunn til å håpe at OKR blir en suksess, og at det baner vei for det digitale produktutviklingsteamets æra. For det er verdt å jobbe for. Jeg har hatt privilegiet av å jobbe i ulike team som har vandret langs hele skalaen på i hvilken grad de lykkes med å jobbe med digital produktutvikling. Og det er ingen tvil om at det er verdt å jobbe for. Det skaper ekte autonomi, det skaper eierskap og det skaper mengder engasjement og eierskap for det teamet prøver å oppnå.

Skal vi komme dit, krever det at flere av oss bretter opp ermene, og anerkjenner at vi prøver å bruke et enkelt rammeverk til å løse et komplisert problem. Det stiller krav til at vi endrer både hvordan vi jobber og hvordan vi tenker, i team, når vi samhandler på tvers av team, inn i prioriteringsprosesser og som ledere.

OKR er ikke en sølvkule. Men det har potensiale til å kombinere autonomi og retning i organisasjoner på en måte vi ikke har sett før. Og det er verdt å jobbe for.

OKR, digital Produktutvikling og produktledelse i 2022

Looking for some neat looking imagery for your next blog post, but feel like Unsplash is played out? Then this article is for you!

There are so many cool new toys out there, based on artificial intelligence tools like OpenAI. Where you previously had to train your own models and understand pretty advanced concepts, you can now write simple prompts in well-designed UIs, and get astonishing results out on the other side.

In today's quick tip, I'm going to show you how I use some of these tools create a bit of visual flair for my articles and web sites.

Step 1: Use ChatGPT to create a text prompt

ChatGPT is a new language model from OpenAI, that lets you talk to a chat bot of sorts. Well, a chat bot that actually give you valuable answers that are factually correct! 

Lots of people have had a bunch of fun having it write raps about their loved ones or favorite technologies, but today we're going to use it to help us write great prompts for another AI tool - the image generating tool MidJourney.

Let's use the image in this article as an example. Here's what I wrote:

Create a prompt for an image where a woman is sitting in front of a computer, looking at a website with lots of boring images. she looks really bored and is not finding what she wants.

This is what I got in return:

The woman sits in front of her computer, scrolling through a website filled with dull, uninteresting images. She looks bored and frustrated, unable to find what she is looking for. Her face is illuminated by the blue light of the screen, and she seems to be searching for something to break the monotony of the dull images. Despite her efforts, she is unable to find anything that catches her interest, and she leans back in her chair with a sigh. She looks around the room, as if seeking something else to do, but her eyes eventually return to the screen, and she continues to scroll through the website, looking for something, anything, that will capture her attention.

Now, that's pretty neat – and it got generated in about a second! Let's try to use it for some image generation!

Step 2: Use MidJourney to generate an image based on that prompt

Now that we have a pretty nice prompt, let's try to jam it into another AI tool - this time we'll use MidJourney, but you can use any image generation tool you like. We pass in the prompt, and add what kind of style we want at the end. For this prompt, I added "Realistic render, bright colors". I'm not really great at writing prompts, you see, but turns out it doesn't matter too much.

After a couple of iterations, variations and upscales, this is what I ended up with:

I think that's pretty neat for a couple of words of input! Now, you could feed this back into more tools, but for me, it gives me just the right vibe.

Step 3: Profit

And by the end of writing this blog post, I've gotten what I came here for - an AI generated hero image for my blog posts about AI generated hero images. Pretty cool!

Using artificial intelligence in new ways is a really new arena, where lots of cool use cases will pop up. The power of the Chat GPT model is definitely amazing, and combining it with tools for image creation is just one of hopefully many ways we can take advantage of it.

5-Dec

Today's posts

Ikke finn opp datovelgeren på nytt!

How to time your CSS animations in JavaScript

Minimalistisk API i .NET på 1-2-3-4

Dagens designtips

OKR, digital Produktutvikling og produktledelse i 2022

Creating exciting stock photos with ChatGPT and MidJourney