Ahh, React. Min gode venn gjennom mange år. Jeg skal være ærlig: forholdet vårt starta litt turbulent. Jeg var usikker på om det å blande HTML inn i Javascripten egentlig var noen god idé. Det tok faktisk et par år før du klarte å overbevise meg! Men du var heldigvis tålmodig. For det som starta som en skepsis viste seg å etter hvert til å bli til en aldri så liten forelskelse! Ohh boy!

Vi har nå vært close i mange år. Du har vært stødig og stabil, og enkel å forstå. Det har liksom aldri vært noe fuzz eller tull med deg! Jeg gir deg noe input, og du gir meg et ferdig view tilbake. Og når jeg endrer inputen, så gir du meg et nytt view. Et forutsigbart forhold tuftet på gjensidig respekt og forståelse!

Men de siste årene har du endret deg. En dag du kom sent hjem fra jobb var du helt i ekstase: du hadde møtt en ny venn ved navn Hooks, og følte deg helt hekta! Jeg var selvfølgelig nysgjerrig, interessert, og glad på dine vegne – noe annet skulle jo bare mangle. For en en god venn av deg måtte jo også være en like fornuftig type? … eller?

Hadde det bare vært så vel.. Du er liksom fortsatt React, men.. små, subtile, ting har endret seg. Reglene er ikke lengre de samme. Det som på overflaten ser ut som små, enkle, funksjoner viser seg å være komplekse beist som endrer oppførselen din fullstendig. Av og til til det helt uforståelige. Jeg kan ikke lengre stole på forutsigbarheten din, som er det jeg virkelig har verdsatt over alt ved deg. Det begynner også bli vanskelig å introdusere deg til nye venner. Det som tidligere var “Hei, hils på React! Gi ham noe input og få et view tilbake – gang på gang!” må nå etterfølges av masse hvis, men og husk på at. Det er plutselig en hel masse ekstra regler å forholde seg til. Regler som skiller seg veldig fra de andre reglene vi er vante med. Regler som ikke kan forklares uten dyp, dyp, kjennskap til hvordan React fungerer på innsiden. Regler som er vanskelige å forstå og huske på for ferske React-venner. Og det som kanskje er verst av alt: selv om Hooks er noen helt andre beist enn vanlige funksjoner, så prøver de så hardt de kan å framstå som akkurat det.

Ting er rett og slett ikke hva det en gang var. Jeg savner de glade og enkle dagene vi hadde sammen før 2018 – dagene før du hadde møtt denne nye vennen din som lever etter sine helt egne spilleregler.

React – et hjertesukk

Dear developer. Have you ever felt that you never get assigned time to work on important upgrades in your code base? Perhaps you during the long nights dream of safer rollout pipelines, major refactorings or prolonged security patches? Look no further. In this article, you will be provided with three concrete tips on how to get the geeky stuff prioritized by people like your product owner! 

As developers, we are the only ones that actually see the current state of our applications. Sometimes, we deem important upgrades to the codebase as needed in order to continue on expanding the codebase with brand new smashing features. However, these important upgrades are not always easy to get prioritized by product owners and other near leaders. In order to find our way into their hearts, we need to speak a language that they may understand.

NO. 1 - Timing

One of the languages that product owners and leaders in general will understand, is that of urgency. In other words, in order to get stuff prioritized, we need to provide them with a sense of urgency. Make them see that your applications' vulnerabilities are important to patch right away. The timing of these messages is crucial. For example, if a competitor's app has been hacked and the leaders see the seriousness of the attack, seize the moment by stating that "this may very well happen to us too at any time, and this is why we need to prioritize the security patches right away!". 

NO. 2 - Break down barriers!

Make sure to always break down the barriers between the business people and the developers. Make it easy for the product owner to ask you questions to better understand how your work flow is. Transparency is of paramount importance! Make sure to get to know each other better, so the leaders will better understand you when you need to prioritize in refactorings. 

Show your leaders how creating new features will slow down overall progress if you don't set aside time to refactor the code within or in between sessions. Try to offer your leaders good analogies. For example, if your product owner likes cross country skiing, try the refactoring-analogy that it will be beneficial to sometimes wait for the slopemaking-machine so you can go skiing faster afterwards. 


NO. 3 - Beware of the recipients personality

Product owners and leaders may seem like they're way different than you, the developer. Business people like Excel, you like JavaScript. You wear different black hoodies and drink Monster energy drinks, they wear different Patagonia vests and drink refreshingly carbonated water. However, you will be surprised of how similar you often are at many other areas in life. Never focus on how you are different, but rather focus on all your similarities. 

We all respond differently to requests coming our way. Some of us follow facts (logos), some of us follow feelings (patos), and some of us follow credibility (etos). These are rhetorical appeal types. You should be aware that these three appeals functions differently, and that people place different emphasis on the three.


Fact-minded leaders

For the fact-minded person, you should offer good and thorough decision material. Maybe you can point to other known successful applications and their refactoring strategies?

Feeling-oriented leaders

For the feeling-oriented, make sure to fire up and engage the individual into your programming joy, and create the great feeling of a high-achieving team!

Leaders looking for credability in your character

Some leaders only want to listen to you if you offer them your credibility first. Make sure to show these leaders your good results before you try to influence them!

The mix

Most people are a complex mix, and respond differently on a scale on the three appeal types. Therefore, make sure that you cater for multiple of the appeal forms.


Good luck, fellow developer!

And now. It's up to you. Take with you one key takeaway from this blog post - remember that behind every prioritiziation there is a human being that you need to convince!



Developers, assemble! Influence your managers in three different ways.

Designer du digitale løsninger? Disse vitenskapelige knepene sparer deg for kostbare regelbrudd.

Evolusjonen har innrettet mennesket slik at øyet gjør én del, synssenteret i hjernen en annen, det førbevisste (pre-attentive processing 📺) enda litt til, og så til slutt er det du og din oppmerksomhet som må danne deg et mentalt bilde av hva du ser på, og hva det betyr.

Hvordan legger synet vårt merke til ting?

Grovt overforenklet skjer følgende når du stirrer på en skjerm:

Først må stavene og tappene i øyet ditt klare å fange opp at det er noe å se på innenfor det lille feltet som er i fokus

Så må det skilles mellom de mange forskjellige tingene en ser.

Deretter må disse grupperes til forskjellige elementer.

Først da setter hjernen vår i gang og spør «Er det en sjekkboks? Eller bare en firkant?», og til slutt vurderer du «Er sjekkboksen aktiv? Kan den brukes? Kan jeg sette kryss i den?».

Og så må du jo mentalt koble hva å huke av i en firkant på en skjerm, faktisk gjør for deg.

Sjekk denne videoen for en overordnet forklaring på hvordan sansene våre gjør om inntrykk til opplevelse.

Nysgjerrig? Les mer her:

Om  visuell persepsjon hos Interaction Design Foundation

Om sansing og persepsjon hos WSU

Det er altså mye arbeid som gjøres fra øyet ditt tar inn lys, til hjernen din viser bevisstheten din det som står foran deg. Det er ikke rett frem å legge merke til ting! 

Kontrast er et effektivt virkemiddel

I visuell design er nøye uttenkte kontrastforhold ett av flere virkemidler 📺 vi har for å henlede brukernes oppmerksomhet dit vi vil. 

Når vi lager ting på skjerm er vi opptatt av at folk skal finne ting kjapt og greit. Dette er spesielt viktig når vi lager selvbetjeningsløsninger. Ofte skal folk bruke dem til noe viktig, uten å gjøre feil, og uten at det tar for lang tid.

Når jeg designer, tenker jeg på hva som er viktigst å se først, og hva en kan se etter hvert. Her bruker jeg kontrast, visuelt hierarki, gruppering og mange andre grep for å gi brukerne noe de raskt finner frem i og får brukt.

Kontrast er kanskje den enkleste tingen å teste blant disse. Det er forsket mye på hvilke kontrastforhold som fungerer best for folk. Når jeg setter opp skjermskisser sjekker jeg løpende kontrastforholdene med verktøy som Stark. I tillegg vurderer jeg hvordan ting ser ut for forskjellige typer fargeblindhet med Sim Daltonism. Og så tester vi selvfølgelig med brukere i målgruppen vår. Ved å gjøre dette starten av, sparer vi oss for problemer senere.

Det finnes regler for kontrast!

Fornuftige kontrastforhold i skjermdesign hjelper brukerne med å oppfatte det viktigste først. WCAG-reglene stiller minstekrav til kontrastforhold i apper og nettsider. Disse reglene er underlagt lov og forskrift og alle som lager nettløsninger må rette seg etter dem. (Ta det opp med Stortinget om du ikke er enig.)

I dag gjelder WCAG 2.0-reglene. Der star det at:

Tekst (og bilder av tekst) skal ha et kontrastforhold på minst 4,5:1 mot det som ligger rundt dem

Stor tekst (og bilder som inneholder tekst i stor skriftstørrelse) skal ha et kontrastforhold på minst 3:1

Fra 1. februar gjelder WCAG 2.1-reglene. Der står det ikke-tekstlig innhold også skal ha et kontrastforhold på minst 3:1. Kravet heter 1.4.11 Kontrast for ikke-tekstlig innhold.

Kravene gjelder for blant annet:

komponenter i et brukergrensesnitt, som lenker, skjemaelementer og knapper

visuelle elementer som ikoner, hvis disse trengs for å forstå innholdet

grafer, og elementer i grafer (som stolper i et stolpediagram), med mer

Sett deg godt inn i disse reglene — de blir viktige i tiden fremover!

Men, kontrastberegningen i WCAG 2 har mangler

Men! WCAG 2.0 og 2.1 beregner kontrast på en mangelfull måte. I WCAG 3, som er under utvikling jobbes det med en ny algoritme for å teste kontrastforhold kontrast, kalt APCA (Advanced Perception of Color Algorithm). Du kan teste det selv i Contrast.tools.

Det er mange år til WCAG 3 trår i kraft. Altså vil vi måtte forholde oss til den ikke helt korrekte beregningsmåten i WCAG 2-serien i lang tid fremover.

Nuvel, hva gjør vi når reglene som gjelder har svakheter? Da tester vi med begge! Slik gjør jeg:

Først sjekker jeg kontrastforhold i Stark (finnes bl.a. som en Figma plugin)

Så tar jeg en ekstra sjekk i APCA

Deretter fjerner jeg WCAG 2-godkjente forslag som feiler i APCA.

Det vi sitter igjen med, tester vi med brukerne så godt vi kan. En grundig test ville kreve en lab med eyetrackingutstyr, utført av eksperter. Sånt er relevant om du jobber med Human Factors Engineering og skal optimere av kognitivt krevende oppgaver i sikkerhetskritiske eller taktiske kontekster. Jovisst, vi kunne ha gjort dette i selvbetjening òg, men den investeringen bruker vi som regel heller på forenkling av selve systemet.

Knep du kan bruke i tillegg

Hva mer kan vi gjøre? Bruke plate-på-flate trikset. Det gir oss både Closure og Figure-Ground på én gang. Iveren etter visuell minimalisme har ribbet de aller fleste nettsteder for persepsjonsgrepene de tidligere dro nytte av. Heldigvis er det kanskje en viss bedring å spore der ute, hvor bruk av bakgrunnsfarger og kanteffekter har gjort det litt lettere å finne frem, lese, og bruke skjermsaker.

Design med blikk for kravene

Kravene i WCAG 2.1 er ikke vanskelige å følge. Men de er viktige å kunne i praksis. Sett deg inn i dem nå, og lag gjerne maler for deg selv i Figma som du tester med Stark og APCA, så du vet hvordan ting skal se ut fremover. Lykke til!

Tenk på 👁 når du designer!

We must become more aware of how we potentially pollute the data we collect from users.



I love conducting user interviews and user tests! But I don't really know what I'm doing. Through our education, designers learn how to collect user data. The methods we learn are mainly based on interviews, testing, workshops etc. But we are not trained well enough in how the data we receive must be obtained as cleanly as possible. We need to be more aware of how we potentially "contaminate" the data we collect. We ask leading questions, we suggest what they should do, and we interpret their actions in the best sense.

More than once I have caught myself saying something like "Yes, you probably knew that was where you were supposed to press". And I have probably more than once set up an user interview where I actually already know what I want the user to answer. Give me a UX researcher who can set up good moderated interviews and tests. Or a data analyst who knows how to handle data and how it should come in straight from a production environment, without me having had the opportunity to pollute that data. Because the data I bring in through interviews and tests is tainted by my own biases.



Original illustration made by DeeKay Kwon


It gets messy

I am not asking that anyone else retrieve that data for my own sake, but for everyone else's. I really enjoy conducting user tests, while getting to confirm or disprove my own assumptions. But the data is and remains dirty. It will be like bringing a child to bake buns. It gets messy, and there is always a bit of snot in the dough. It may taste quite good, but there is still a bugger in that bun.

Before an interview or a test, the team should have made themselves aware of which biases they potentially bring with them and how we can be as neutral as possible. Perhaps you can even retrieve the data you are looking for right from a production environment? Then you can rather use interviews and tests to obtain data on things that cannot be obtained directly from prod. The result of a good user interview or a good user test should be a set of data that we have jointly reviewed and checked that we have not mixed our own biases or interpretations with what the user actually said or did.


So let someone else obtain that data

Include me in the interview and the user test, and include me in the process, but there are others who are more qualified to guide the user through. Include me in the work of setting up measurements for production data, but let someone who knows which biases can affect the data take the lead.

I may not be the best at obtaining clean, untainted data, but what we designers are actually good at is analyzing that data and processing it into insights that are understandable to others, and that can be used as a knowledge base for further decisions in the team. Together let's boil it all down to insights that we can use. I think we often get a truer picture of reality by getting good data straight from prod, rather than conducting interviews and user tests all the time. Let someone else obtain that data.

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

What did you feel while reading? Did it spark something in you? Do you agree or disagree? Join the discussion on UX Norge's slack (Norwegian) or share this article with your colleagues and start a debate! Remember that the goal of Brannfakler is to start discussion!

Someone else can obtain that data

Nettsider med animasjon får litt personlighet, og det skal lite til for å oppnå det. Her er en guide til bruk av CSS-transitions.

Hvilke følelser får du når du ser en nettside med animasjoner? Jeg blir litt nysgjerrig. Nettsiden blir livlig og får personlighet. Animasjoner kan også gjøre nettsiden mer profesjonell, ved at innholdet blir mer sammenhengende. Istedenfor plutselige endringer, kan det vises smarte overganger, som ikke overrasker brukeren. Animasjoner trenger ikke å være spektakulære for å vekke positive følelser eller å gjøre nettsiden mer brukervennlig. I denne teksten ønsker jeg å vise hvor enkelt animasjon kan implementeres.


Hva skal vi lage?

Vi skal lage en animasjon hvor innholdet på nettsiden dukker opp gradvis idet vi scroller.

Kodeeksempelet er skrevet i React, men mye av koden vil være overførbar til annen kode, så lenge du bruker CSS og JavaScript. Nettsiden består av en velkomsttekst, etterfulgt av to rader med tre bokser i hver rad. Det er disse boksene vi skal animere til å først være skjult, så dukke opp.



Hva er egentlig animasjon?

Greia med animasjon er at et element går fra én tilstand til en annen. I vårt tilfelle, har vi én tilstand hvor innholdet først er skjult, så en annen tilstand hvor innhold vises.

I vårt eksempel skal vi først skjule innholdet ved å ha en CSS-klasse reveal som har egenskapen opacity satt til en verdi av 0. Vi endrer til tilstanden “vist” ved å også legge til klassen active, som gir opacity verdien 1.

Greia med animasjon er en gradvis endring. Vi ønsker ikke at innholdet plutselig dukker opp fra ingensteds. Det er nettopp overgang, eller transition, som brukes for animasjoner. Nettleseren vil sømløst forandres fra skjult til synlig.

transition: 1s opacity; betyr at endring i egenskapen opacity skal endres i løpet av ett sekund.



Hvordan aktiverer vi animasjonen?

I vårt tilfelle har vi lagd to mulige tilstander ved å lage to klasser med ulike tilstander. Vi ønsker at innholdet er skjult som standard, så innholdet kan alltids ha reveal-klassen. Spørsmålet blir dermed:

Hvordan kan vi legge til eller fjerne klassen active på element?

Det finnes veldig mange måter å legge til eller å fjerne en klasse. En måte er å ha en eventlistener som trigger en funksjon. Avhengig av en betingelse, vil funksjonen så enten legge til eller fjerne en klasse.


Denne funksjonen blir så kalt av en eventlistener som lytter på scrolling.


Hvordan lage en eventlistener for scrolling?

Vi legger til lytteren på vinduet.

Vi ønsker å sjekke for scrolling idet brukeren besøker siden. Siden vi bruker React, legger vi derfor denne kodesnutten til i en useEffect. Jeg ønsker å kunne gjenbruke logikken vi lager, så jeg putter det i en custom hook useAddRevealListener. Når vi bruker eventlisteners, ønsker vi også å fjerne lytteren når komponentet demounter, så ubrukte lyttere ikke bruker unødvendig ytelse.

Vi har nå en lytter som kaller funksjonen revealOrHideElement ved scrolling. Men hva skal denne funksjonen egentlig gjøre?



Hvordan vet vi om innholdet bør vises eller ikke?

Vi ønsker å ha en animasjon som viser innhold idet vi scroller ned på innholdet. Hvordan vet vi om brukeren har innholdet i synsfeltet av skjermen?

For brukerens skjerminnhold kan vi bruke window.innerHeight , som forteller oss skjermens høyde. Vi kan så bruke getBoundingClientRect().top som henter ut et element sitt høyde-verdi, som er toppen av elementet. Om toppen av elementet er mindre enn skjermens høydeposisjon, vet vi at den synes. For å sikre oss at vi ser en viss del av elementet, kan vi legge til en terskelverdi for antall piksler av elementet vi ser før animasjonen skjer.

Vi har løst hvordan vi vet om et element er i syne, men hvordan vet vi hvilke elementer vi skal gjøre denne sjekken på? Det kan vi gjøre ved å hente ut alle elementene som har klassenavnet reveal via en querySelector.

Dermed har vi det vi trenger for funksjonen scroll-lytteren skal kalle. For hvert element som har klassenavnet reveal, vil vi sjekke om elementet er i syne. Om brukeren kan se den, legger vi til en klasse. Hvis ikke, fjerner vi klassen.



Hvordan bruker vi animasjonsfunksjonen?

Ettersom vi har puttet all logikken vi trenger i en custom hook, kan vi enkelt kalle denne fra et topp-nivå, for eksempel App. Om du nå legger til reveal på et element under App, vil du se en animasjon idet du scroller over boksene.


Bonus: Flere animasjoner!

Vi har nå lagd en animasjon for opacity. Den observante så kanskje i demoen at elementene beveger seg også oppover idet de kommer til synet. En måte å flytte elementer på er å bruke transform. Vi kan først holde skjulte elementer 100px nedenfor sin vanlige posisjon, så nullstille denne verdien idet de kommer til syne. Legg også merke til i transition-verdien at vi spesifiserer hvilke animasjoner som overgangen skal gjelde.



Vi har nå en mer levende animasjon!


Avsluttende ord

En animasjon kan forklares med at et element endrer fra én tilstand til en annen med en gradvis overgang. Her har vi sett på to overganger: synlighet og bevegelse, men det finnes mange flere å utforske. Vi har brukt transition uten å spesifisere type animasjon, og har dermed brukt standard-animasjonen ease. Det finnes flere!

Koden for demoen finner du på denne codepenen: https://codepen.io/haalmarc/pen/LYrmqwW



Videre lesing

Er du mer nysgjerrig på animasjon, kan jeg anbefale denne interaktive guiden: https://www.joshwcomeau.com/animation/css-transitions/

Ønsker du inspirasjon til hvor du kan bruke animasjon, ta en titt på denne: https://yalantis.com/blog/web-animation-technologies-and-tools/

Utgangspunktet for koden min er fra en animasjonsguide for HTML og CSS som du kan finne her: https://alvarotrigo.com/blog/css-animations-scroll/










Gjør nettsiden din levende med CSS-transitions

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

Hvem er jeg?

Magnus heter jeg

36 år

Fra sørlandsperlen Grimstad

Studert interaksjonsdesign på UiO

Jobbet som designer i 5 år

Jeg har alltid hatt en naturlig nysgjerrighet og vært glad i å løse problemer. Jeg har også så lenge jeg kan huske irritert meg over dårlig – eller manglende – design i tjenester og produkter jeg bruker. På tross av dette er det mest tilfeldigheter som førte til at jeg ble designer; jeg visste egentlig ikke helt hva jeg gikk til før jeg hadde studert design en stund. Etter hvert oppdaget jeg at interaksjonsdesign er som skreddersydd for meg, ved at jeg kan kombinere mine interesser for teknologi, problemløsning, skaperglede og å jobbe med mennesker.

Hva gjør jeg (og hvordan)?

Jeg jobber hos Kartverket i et team som lager tjenester knyttet til tinglysing av eiendom i Grunnboken – registeret som inneholder den faktiske bekreftelsen på at du er rettmessig eier av leiligheten eller boligen din til millioner av kroner, og som det derfor er svært viktig at vi som befolkning har full tillit til. Akkurat nå jobber teamet med digital tilgjengeliggjøring av tinglyste dokumenter. Disse er i dag kun mulig å få tak i ved å få dem tilsendt som brevpost, selv om de er helt nødvendige for at en eiendomsmegler skal kunne legge ut boligen din for salg.

Da jeg begynte å jobbe for Kartverket i midten av august var det ikke bare en ny kunde for meg, men også for Bekk. Det har vært meget lærerikt og interessant å være med helt fra starten hos en ny kunde. De første dagene, da det virket som det dukket opp ti nye begrep hver dag, var på samme tid både frustrerende og svært givende, og hodet føltes ofte helt kokt ved slutten av hver dag. Det ble en tid med bratt læringskurve, men samtidig er det en erfaring som jeg er glad for å ha fått.

Gjennom høsten har oppdraget hos Kartverket gått fra å kun bestå av et lite knippe personer, til å bli en betydelig gruppe med flinke folk. Samtidig har vi blitt en liten gjeng med designere på oppdraget, og selv om vi er fordelt ut på ulike produktteam, så sitter vi samlet og jobber mye sammen. Jeg er veldig takknemlig for at jeg kan sparre, diskutere og lære sammen med andre dyktige designere, og selv om vi ikke har jobbet sammen så lenge føler jeg at jeg kan ta opp hva som helst med dem.

Det at Kartverket er en helt ny kunde innebærer også at det har vært et helt nytt domene å sette seg inn i, uten at det finnes noen erfarne kolleger fra Bekk å spørre for å oppklare en usikkerhet eller et begrep. En ting er at det er et utall nye konsepter og begrep å lære seg, men kanskje det vanskeligste er alt jeg ikke vet at jeg ikke vet. De fleste fagekspertene vi jobber med i Kartverket har jobbet med sitt fagområde i mange år, og jeg opplever det nærmest som en naturlov at noe av det vanskeligste for en ekspert å forstå, er hvilke deler av faget som er vanskeligst for en nybegynner. Det fører til at de som er ansatt i Kartverket ofte ikke skjønner hva som er selvfølgelig for dem, men nærmest uforståelig for oss som er nye til domenet.

For å gjøre dette enda mer utfordrende har jeg flere ganger opplevd at et begrep brukes og forstås ulikt i ulike avdelinger hos Kartverket! Sannsynligheten for at misforståelser oppstår blir dermed stor, og det er lett å snakke rett «forbi hverandre». I slike situasjoner har jeg erfart at det er til ekstremt stor hjelp enten å tegne opp noen enkle figurer, eller å støtte seg på eksisterende figurer eller modeller av det vi diskuterer.

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

«Når du tror at du har forstått et begrep/konsept, er det fortsatt mye igjen å forstå…» 😅


Dagens designtips

Tidligere i mai mistet Norkart masse personinformasjon, inkludert fødselsnummer, om over halve Norges befolkning. Norkart gikk selv ut og anbefalte alle som var berørt om å sperre seg for kredittsjekk. Det er mange problemer med denne anbefalingen, men det største er at måten kredittsjekk fungerer på er utdatert, og det virker ikke som noen har planer om å gjøre noe med det.

Hva er en kredittsjekk?

En kredittsjekk foretas ved at et kredittopplysningsselskap gjør en analyse av ulike sider av økonomien din. Inntekt, gjeld, betalingsanmerkninger osv. spiller inn, og til slutt gir dette selskapet deg en form for vurdering. Denne er ment å hjelpe den som skal gi deg kreditt med å forstå hvor høy risiko det vil være ved å ha deg som kunde.

Det er ikke fritt frem å gjennomføre en kredittsjekk av noen, det må foreligge en saklig grunn. Når et selskap mener å ha saklig grunn må de identifisere deg til kredittopplysningsselskapet, og dette gjøres som oftest med fødselsnummer for å sikre at man har en unik identifikator på den man ønsker kredittsjekket.

Når du blir kredittsjekket har du krav på et gjenpartsbrev. Dette er et brev som forteller deg hvem som har kredittsjekket deg og hvilke økonomiske opplysninger som ligger til grunn for kredittvurderingen som er gjort. Dette brevet er ment å gi deg et varsel om at en kredittsjekk har skjedd, samt gi deg innsyn i hvilke opplysninger som har blitt utlevert.

Hva er galt med kredittsjekk sånn det fungerer i dag?

Den største utfordringen er at systemet virker å være laget for en tid der kommunikasjon mellom ulike parter gikk tregt. Enhver som påstår å ha saklig grunn får utlevert dine opplysninger, uten at du selv kan gi samtykke til dette fra gang til gang. I dagens moderne samfunn virker det helt bakvendt at man først i etterkant av kredittsjekken skal få tilsendt et varsel om at den har skjedd. Det ville vært en smal sak å ha et system der man godkjente hver kredittsjekk med BankID. Det ville ha fjernet utfordringen med at enkelte aktører tillater kjøp på kreditt bare på bakgrunn av adresse og fødselsnummer.

Når systemet da dessverre er så gammeldags som i dag, er det enda mer hårreisende hvor vanskelig det er å sperre seg for kredittsjekk. Da Norkart anbefalte nordmenn å sperre seg for kredittsjekk brukte jeg det som en anledning til å teste ut hvordan det fungerte.

Du må først finne ut at det er 4 selskaper som kredittsjekker privatpersoner. Så må du finne tjenestene deres for å sperre deg for kredittsjekk. Her hjelper det ikke at Bisnode har valgt å legge sin nettside for privatpersoner på www.soliditet.no. (Og prøver du å gå til bisnode.no blir du sendt til dnb.com, ikke akkurat enkelt å forholde seg til.) Experian var på sin side nede i 3 dager etter Norkart-saken, og da de kom opp igjen viste det seg at de hadde den absolutt dårligste brukeropplevelsen. Her må du registrere en konto, og oppgi både e-post og telefonnummer før du kan sperre deg for kredittsjekk. Du må altså øke risikoen din for lekkasje av persondata enda mer. Og hvis du ikke passer deg, takker du ja til å få alle gjenpartsbrev sendt til Experian sin egen portal - du vet, den som var nede i 3 dager da det virkelig var viktig å kunne sjekke om man fikk noen gjenpartsbrev.

Alt i alt en katastrofe av en brukeropplevelse. Og verre skal det bli. Når den nye kredittopplysningsloven som Stortinget vedtok i 2019 trer i kraft blir det ikke lenger slik at Datatilsynet har oversikt over hvem som driver kredittopplysningsvirksomhet. Da kan det hende du må sperre deg for kredittsjekk hos et selskap du ikke vet at finnes 🙃 Datatilsynet har påpekt dette i høringsutkastet sitt, og bedt om at det opprettes et felles sperreregister. Vi må alle håpe at det skjer, hvis ikke vil det i praksis ikke være mulig å sperre seg for kredittsjekk i fremtiden.

Hva burde gjøres?

Dette virker som en av de sakene der løsningene er åpenbare!

Kredittsjekk må utføres basert på eksplisitt samtykke. Dersom jeg forsøker å handle på kreditt, eller søke lån, burde kredittopplysningsselskapet pålegges å innhente mitt samtykke. Det burde ha samme krav til sikkerhet som en betaling i nettbanken, som tross alt krever BankID for at jeg skal kunne betale en regning på 50 kroner.

Det må opprettes et felles sperreregister. Selv med punkt 1 gjennomført vil det for noen være behov for å kunne sperre seg helt for kredittsjekk. Et felles register i Brønnøysundregistrene på lik linje med registeret for reservasjon mot reklame burde fungere helt fint.

Gjenpartsbrev burde ikke kunne låses inn på systemet til kredittopplysningsselskapene selv, men burde sendes deg på lik linje med annen viktig post, enten i digital postkasse, eller i fysisk post.

Om ikke annet har Norkart-saken gjort det tydelig at det er store mangler i måten vi gjennomfører kredittsjekk i Norge, og at det er på høy tid å modernisere denne prosessen.

19-Dec