Det den innloggede brukeren gjør med sine egne data — se sin oversikt, endre opplysningene sine, sende inn noe og følge en sak. Modulen som avgjør om systemet oppleves som nyttig eller som enda et skjema.
Hvem modulen er for
For den innloggede brukeren utenfor virksomheten: medlemmet, kunden, leverandøren, søkeren, beboeren — hva de nå kalles i akkurat dette systemet. Fellesnevneren er ikke hvem de er, men hva de får se: sine egne data, og bare sine egne.
Tilsvarende tilgangsrolle i spesifikasjonen: Innlogget bruker — en av de to tilgangsrollene enhver spec bør starte med. En tilgangsrolle er samlingen av rettigheter en bruker får — hva vedkommende har lov til å se og gjøre.
Typisk innhold
En forside etter innlogging som viser status og det som krever handling. «Min profil» med endring av egne opplysninger. Innsending av noe — en søknad, en bestilling, en melding, en timeregistrering. Historikk over egne saker eller kjøp. Dokumenter til nedlasting, som fakturaer eller vedtak. Varsler og innstillinger for hvilke varsler brukeren vil ha. Ofte også samtykker og et sted å be om innsyn i eller sletting av egne data.
Hvorfor den undervurderes
Modulen glemmes ikke — den er som regel det virksomheten mente med «systemet» i utgangspunktet. Det som undervurderes er at hver eneste visning her må filtreres på hvem som er innlogget, og at den filtreringen må være riktig hver gang. Én liste som glemmer filteret er en personvernhendelse, ikke en feil. I estimatet ser en liste for brukeren og en liste for administratoren like store ut; i praksis krever den første en beslutning om eierskap til hver rad, og den må testes for seg.
Når det bør være en egen modul
Egen modul så snart det finnes brukere med egne data. Har systemet flere tydelig forskjellige eksterne grupper — for eksempel både bestillere og utførere, med hver sin arbeidsflyt — er det ofte riktigere med to moduler enn én med mye betinget innhold. Lakmustesten er den samme som for moduler ellers: kan den ene tas ut av leveransen uten at den andre slutter å virke? Da er de to.
Fallgruver
Å anta at brukeren har samme forståelse av dataene som virksomheten. Interne betegnelser og statuskoder som gir mening i saksbehandlingen, er uforståelige utenfra og genererer telefoner til kundeservice — som var det systemet skulle redusere. Å tillate for lite: kan ikke brukeren rette en enkel opplysning selv, havner den jobben hos en ansatt. Å tillate for mye: noe skal ikke kunne endres uten godkjenning, og det skillet må avgjøres per felt, ikke per skjermbilde. Og å teste bare med sin egen testbruker — feil av typen «jeg ser noen andres data» dukker først opp når to brukere er logget inn samtidig.
AI-perspektiv
Her ligger den mest håndfaste AI-gevinsten for brukeren selv, ikke bare for utviklingen: et søk som forstår vanlig språk, et forslag til hvordan et skjema skal fylles ut, eller et sammendrag av en lang saksgang. Alt sammen forutsetter at avgrensningen mot egne data holder også når AI-en henter kontekst. En språkmodell som får se mer enn brukeren har lov til å se, lekker det videre i klartekst. Avgrens datagrunnlaget på samme bruker som resten av modulen.
Skal dere sette omfanget på et system? Modulene avgjør hvor stort prosjektet blir, og den største av dem er ofte den ingen har snakket om. DOPS har spesifisert og bygget systemer for norske virksomheter i over 20 år.
Be om et estimat