Design

Personvern og innsiktsarbeid

Simen Strøm Braaten
Variant
Published in
10 min readDec 7, 2022

--

Før jeg går for dypt inn i det her vil jeg bare stille deg et kjapt spørsmål:

Hva er det egentlig som er relevant å vite om en testdeltager når du ser tilbake på utført innsiktsarbeid?

Når vi gjør innsiktsarbeid så kommer vi til å inkludere folk. Det er uunngåelig når vi hente inn meninger, tilbakemeldinger og tanker om tjenesten vi lager. Men hva slags informasjon trenger du egentlig lagre til seinere?

Av gammel vane er det kanskje lett å tenke at “Å, men det er kjekt å spare på, sånn i tilfelle vi trenger det”. Men hva er egentlig det tilfellet? Og hvordan kan du løse det på en måte som ivaretar personvernet?

Disclaimer

Jeg er såklart ingen advokat, og jeg skal ikke late som heller. Det her er kun ment for at vi skal kunne lære av hverandre og forbedre arbeidsprosessene våres. Ta det her med en klype salt og sjekk heller med en jurist om du vil være på den trygge sida.

Kort og greit, hva telles som personopplysninger?

I grunn alt som kan identifiseres eller knyttes til en person skal behandles som sensitivt. Det kan være alt fra personnummer, epost, øyenfarge, bilder, film- og lydopptak, allergier, helseinformasjon (fra vekt til sykdommer, og alt midt i mellom), til epost, navn, telefonnummer, og post-adresse.

En mulig løsning

Heldigvis har jeg en kollega i Oslo — Nikolai — som kan langt mer om GDPR-temaet enn meg. Og da jeg diskuterte det her med han, sa han at et tiltak for å bedre personvernet kan være å separere personinformasjonen og selve innsiktsarbeidet.

Det vil si at du kan ha et referansedokument f. Eks på Sharepoint eller et lignende sted hvor man kan beskytte det bak et passord eller en gruppetilgang (med folk som har oppriktig bruk for informasjonen). Mens selve bearbeidinga av informasjonen som kom opp kan abstraheres, og samles i et innsiktsbibliotek (Miro, Dovetail osv).

Referansedokument

Du er sikkert nysgjerrig på hvordan et sånt referansedokument kan se ut, så vi lagde et eksempel her:

Eksempel på referansedokument for å lagre personinfo til innsiktsarbeid

Hva et referansedokument hjelper deg med

Gjennom dette skjemaet så tilrettelegger vi for gode vaner.

  1. Du gjør det lettere å finne tilbake til prosjektfilene, eller arbeidsområdene, som inneholder informasjonen til akkurat denne personen.
  2. Du planlegger fram i tid når informasjonen skal slettes (som alle skal ha rutiner for, men som de færreste faktisk har)
  3. Du får en påminnelse om at samtykkeskjema er nødvendig dersom du tar opptak av brukertesten

Der du bearbeider informasjonen

Hvordan ser altså selve arbeidet ut? Uavhengig av hvilket verktøy du bruker så

Si du gjennomfører en brukertest, under selve gjennomføringa skriver du noe sånt som det her: “Personen forstår intensjonen bak ikonet, og finner løsningen uten problemer, men påpeker at ikonet/knappen kunne vært større”.

Når du seinere skriver en rapport for å oppsummere funnene, eller du skal beskrive testen/eksperimentet som er gjort, så kan du beskrive brukergruppen i grove trekk, uten å nevne navn.

Som for eksempel: “Alt i alt var det 8 deltagere, hvor det både var kvinner og menn som tilhørte ulike aldersgrupper — fra 15 til 65 år gamle. Tre av deltagerne brukte appen 0–2 ganger i uka, fire av dem brukte den 3–4 ganger, og én brukte den 5–10 ganger. Halvparten så på seg selv som teknisk kyndige, og helt komfortabel med “apper og sånt”, mens resten anerkjente at de ikke var så gode på den slags ting.”

Det vi gjør her da er å pseudonymifisere personopplysningene, som i følge Datatilsynet betyr å:

Å avidentifisere personopplysninger slik at de ikke kan knyttes til en bestemt person uten bruk av tilleggsopplysninger (for eksempel en koblingsnøkkel) som lagres adskilt og tilstrekkelig sikkert.

De legger også til at pseudonymiserte personopplysninger ikke er anonyme, og skal behandles som persondata.

Her kan det være lett å gå i surr, så her er et kjapt eksempel:

Pseudonymisering: “Deltager 1 brukte appen 0–2 dager i uka.”
Deltager 1 peker på en spesifikk person du kan identifisere sammen med din kilde.

Anonymisering: “Deltagere mellom 16–36 år bruke appen 0–2 dager i uka.”
Gitt at det var mer enn én person mellom 16–36 år riktignok.

Refleksjoner om personinfo

Men la vårs ta et par steg tilbake. For når du leser det her så er du sikkert ute etter en slags “løsning”, så jeg håper referansedokumentet ovenfor, i sammenheng med formuleringene på selve innsiktsarbeidet kan være til inspirasjon. Med det sagt, så er det en viktigere ting du kan ta med deg ut fra den bloggposten her, og det ers spørsmålet:

Hva trenger du egentlig å ta vare på?

Om du ikke har reflektert noe over det tidligere så kan du heller bli med på tankeutforskingen min. For svaret på det spørsmålet er nok “mindre enn du tror”. For det blir jo sjeldent brukt, og da sitter du egentlig med en unødvendig risiko.

Det viktigste med dette spørsmålet er nettopp å reflektere over det. Og det var Nikolai veldig tydelig på og, at dersom folk bare reflekterte på hva slags personinfo du faktisk trenger, så hadde ikke dette vært en like stor utfordring. I tillegg til å tydelig forklare hva personopplysningene deres skal brukes til i et samtykkeskjema, som jeg forklarer mer i dybden lenger ned.

For min del trenger jeg sjeldent noe mer enn “person 3, i 50-årene, teknologivant”. Kanskje det er noen spesifikke kriterier som kan være verdt å nevne, som at personen har et visst bruksmønster, eller tilhører en persona dere har lagd, men det er i grunn alt.

Navnet

Navnet til en person er forsåvidt ikke viktig å spare på. Med mindre du vil plukke opp kontakten for videre testing seinere.

Kjønn

Utgjør det egentlig en forskjell på testresultatene? Det som er viktig å vite er alle brukergrupper er ivaretatt. Dersom vi lager en tjeneste for å hjelpe dyslektiske barn med å lese så burde vi ikke utelukkende test på hvite menn i 30-åra med høy utdanning. Kjønn kan dermed være relevant i form av å bekrefte at innsiktsarbeidet har inkludert ulike brukergrupper.

Alder

Det samme gjelder også alder, men her trenger du ikke være helt spesifikk. Om en person er 68 eller 64 har lite å si, men om du har snakka med tenåringer eller barn kan det være relevant å skille mellom en som er 10 og 15. Det her kan riktignok abstraheres bak begrep som barn, tenåring, ung voksen, voksen, pensjonist, for å nevne noen. Personlig pleier jeg som regel å skrive f. eks “50-åra”, for å indikere omtrentlig alder. Så lenge personen er over 20 år gammel vil det være detaljert nok å fokusere på tiåret.

Metadata

Når man har vært i kontakt, og hvor mange ganger, kan være relevant dersom det er en person som har testa tjenesten gjentatte ganger.

Teknisk kyndighet

Om du lager en digital tjeneste er det relevant å vite hvor erfaren, eller hvor vant deltageren er med teknologi på generell basis. For eksempel da jeg jobba med AtB så var det relevant å vite om noen utelukkende kjøpte billett på kundesenteret, og møtte opp i person, fordi de syns det var enklere, eller om de alltid kjøpte periodebillett 3 måneder om gangen. Eller om noen søkte opp reisa si på hjemmesida til atb(.no) i stedet for å bruke reiseplanleggeren. Årsaken for de valgene trenger ikke utelukkende være at man er “dårlig” med teknologi, eller syns det er vanskelig, men om du ser tilbake på innsiktsarbeidet vil det altså bli lettere å stille mer relevante oppfølgingsspørsmål, til videre arbeid.

Universell utforming, eller tilgjengelighet

Dersom du har testa spesifikt mot universell utforming er det bare ett enkelt tilfellet jeg kan komme på hvor det vil være relevant å nevne det. Og det er for å oppsummere hvordan testen blei gjennomført, og hvilke brukergrupper du testa med. Altså at du beskriver testen eller eksperimentet i overordna trekk.

For å være sikker på at UU har blitt ivaretatt i innsiktsarbeidet kan det nemlig være relevant å se hva man har lært tidligere.

For å sette det på spissen; Si du kommer inn i et nytt prosjekt hvor det lages en løsning som også har brukere utenfor organisasjonen. Når du ser gjennom innsiktsarbeidet som er gjort fram til det punktet da så vil det være relevant å vite om det er testa på utelukkende internt ansatte, av typen “hvit mann i 40-årene med IT-jobb”, eller om det også inkluderer eksterne brukere i ulike livssituasjoner, aldersgrupper og kjønn.

Du trenger ikke vite hvem som sa hva, men om det er brukergrupper som har blitt oversett så kan det si noe om hvem du burde teste med.

Når trenger du faktisk personopplysninger?

Før testing

Det blir kanskje feil å si “bruke personopplysninger”, men i rekrutteringsfasen er vi ofte avhengig av både navn, epost-adresser, telefon-nummer, og kanskje post-adresser for å sende gavekort som takk for deltagelsen.

Her benytter vi kontaktinformasjonen, og sammen med selve epostene og tekstmeldingene som sendes, utgjør det da en del av den helhetlige personopplysningene vi har lagra.

Den samme informasjonen som du har brukt gjennom rekrutteringa er egentlig ikke relevant igjen før du skal rekruttere på nytt.

I løpet av testingen

Når du først er i gang med f. eks brukertesting så er det kun meningene, erfaringene og tankene relatert til testområdet som dokumenteres. I tillegg vil det være relevant å notere relevant oppførsel, som f. eks om personen begynner å virke frustrert, eller oppgitt, fordi oppgaven er vanskelig å løse. I tillegg til om det tar kort eller lang tid å løse oppgavene.

De notatene der trenger overhodet ikke være tilknytta til et navn.

Bearbeiding av innsikt

For når du kommer til selve bearbeidinga. Når du skal “kna dataen” og sette fingeren på hva du har lært. Da er det rivende likegyldig hva personen heter. Gitt at du har tilstrekkelig med abstrahert metadata å lene deg på, som f. eks “Mann, 40-årene, mindre teknologivant, sånn type bruksmønster”. I de fleste tilfeller vil det være mer enn nok. Noen ganger vil det riktignok være spesifikke kriterier som gjør det mer relevant å lage flere emneknagger, om det er noe stedsrelevant, bransjen man jobber i, eller hvor ofte man bruker en tjeneste osv.

Etter innsikten er levert

Når du har skrevet anbefalingene dine basert på det du lærte må du ha en rutine for å rydde opp i personopplysningene du har lagra. Derfor burde det nok eksistere en slags innholdsfortegnelse over arbeid som er tilknyttet til hver enkelt person (som linker til prosjektfiler eller filnavn).

Dette høres mer omfattende ut enn det trenger å være, men det trenger nok ikke være det. For så lenge det ikke er noe som kan direkte eller indirekte identifisere enkeltpersoner i notatene dine så regnes det som anonymt. Det vil si at notatene dine, og innsikten som har kommet ut fra det vil være “trygt”, dersom du har tatt de nødvendige forhåndsreglene.

Videopptak, bilder, kontaktopplysninger osv. må derimot slettes, både innen et avtalt tidsrom, eller hvis deltageren trekker samtykke sitt, eller sier opp kundeforholdet.

Samtykkeskjema

I de fleste tilfeller vil det være tilstrekkelig å dokumentere en brukertest med kun notater, uten behov for lyd- eller filmopptak. I så fall trenger du sannsynligvis ikke et samtykkeskjema. Gitt at du ikke skriver ned navn eller noe annen form for “personidentifiserende bakgrunnsopplysninger”.

Opptak kan derimot være gull verdt for å formidle brukerens utfordringer videre til andre på teamet, eller i organisasjonen, og da er et samtykkeskjema nødvendig. Her er det riktignok gode og dårlige måter å gå fram på.

“Best practice”

Før en brukertest f. eks kan du sende ut et samtykkeskjema slik at personen får mulighet til å forstå hva slags personopplysninger som samles inn, og kan fordøye det i ro og mak.

Dersom du klinker til med et advokatspråklig dokument på 10 sider før du en gang har sagt “Hei” i en brukertest, så vil det såklart virke skremmende. I stedet kan du oppsummere intensjonene og bruksområdene på en ryddig måte, inkludere noen enkle sjekkbokser, og si noe sånt som:

“Vi rydder opp etter vårs, og sletter opptak etter ..så og så lang tid.., så det ikke lagres for alltid. Vi liker også å nevne hvordan den informasjonen her blir brukt, og ser for vårs at følgende situasjoner vil være relevante. Siden det er din stemme, og ditt ansikt på video, så vil vi vise at vi tar ordentlig vare på det.

Det skal nemlig være lett å forstå. Faktisk så kan et samtykkeskjema vurderes til å være ugyldig dersom budskapet er for vanskelig å forstå. Tenk litt på den du!

Som Norsk Senter for Forskningsdata (NSD) sier:

Når du ber om samtykke, må du bruke klart, enkelt og forståelig språk som målgruppen forstår og fatte deg i korthet.

I tillegg skal det være like lett å trekke samtykket sitt på, som det var å gi det. Enten om det da trekkes helt, og innsikten tilhørende til den personen da blir fullstendig anonymisert, eller sletta, hvis det ikke er mulig å anonymisere.

Her kan du se et eksempel på et omfattende, men personlig og lettlest samtykkeskjema, som er laget av forskere ved OsloMet (linken går til en word-fil). NSD lister også opp hva slags informasjonen som burde inngå i et samtykkeskjema.

Avslutning

Det her er ikke ment som noen fasit akkurat, men heller et lite pirk i sida for å få deg til å tenke over hva slags info du faktisk trenger å ta vare på under innsiktsarbeid.

Om du er uenig i det jeg skriver så er det kjempeflott! Send meg en epost på ssb@variant.no, for jeg vil veldig gjerne vite hvorfor, og hva som kan forbedres.

Og du, hvis du likte det her så er det en god sjanse for at du også vil like serien min om det å jobbe med innsiktsarbeid.

Stor takk til Nikolai, Kristoffer, Anders Njøs, og Truls Henrik for at dere arresterer meg når jeg sier noe feil, om et fagområde jeg ikke har heeelt stålkontroll på, og påpeker helt konkret at “det der kan du ikke si.” Og til Lotta-Linn som tipsa meg om Norsk Senter for Forskningsdata.

--

--

Designer at Variant. Co-founded Hyggelaget back in the days, and I’ve been known to talk to old people in this podcast right here: www.folkomfortida.no.