likeperson.md

# Tverrgående workshopsammendrag

## Behovskartlegging – Likepersonsapp

**Norse Digital Products | NHF, Blindeforbundet, HLF (+ Barnekreftforeningen)**
**Februar 2025**

Dette dokumentet oppsummerer fellestrekkene og de unike behovene på tvers av workshoppene med Norges Handikapforbund (NHF), Norges Blindeforbund og Hørselsforbundet (HLF). Barnekreftforeningen inngikk i forprosjektet og er ikke inkludert som egen workshopdeltaker her. Formålet er å gi teamet et prioriteringsgrunnlag for videre utvikling.

## 1. Felles behov – går igjen i alle tre organisasjoner

Følgende behov ble løftet frem – ofte ord for ord – i alle tre workshops. Dette er kjernen i hva appen MÅ løse.

### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle)

Alle tre organisasjoner peker på dette som den aller viktigste funksjonen, og beskriver dagens situasjon som uholdbar. Fellesnevneren er at rapporteringen er så tungvint at det fører til massiv underrapportering – enten fordi folk ikke orker, eller fordi de ikke engang skjønner at det de gjør teller.

- **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk.
- **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst.
- **HLF:** En likeperson hadde 380 enkeltregistreringer på ett år. Standardverdier (dagens dato, 30 min) som kan overstyres. 60–70 % av registreringene er uten refusjon og skal være ekstremt enkle.

> **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg.

### 1.2 Universell utforming (WCAG 2.2 AA)

Alle tre organisasjoner har brukere med svært ulike forutsetninger – motoriske, kognitive og sensoriske. Appen SKAL oppfylle **WCAG 2.2 nivå AA** som minimumskrav for alle skjermer og interaksjoner.

- **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå.
- **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle.
- **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning.
- **Kontrast og typografi:** Minimum 4.5:1 kontrast for tekst, 3:1 for store tekstelementer og UI-komponenter. Skalerbar skrift opp til 200%. Unngå tynne/kursive fonter.
- **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size).
- **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator.
- Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen.
- Varsling ved opplesning av sensitive felt (NHF).
- **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements).

### 1.3 BankID / Vipps innlogging

Alle tre organisasjoner peker på BankID eller Vipps som foretrukket autentisering ved førstegangs innlogging, med biometrisk innlogging (Face ID / fingeravtrykk) etterpå. En viktig bieffekt: Vipps-innlogging kan returnere personnummer tilbake til medlemssystemene, som i dag mangler dette for mange brukere.

### 1.4 Sømløs Bufdir-rapportering

Alle tre organisasjoner mottar Bufdir-tilskudd og bruker mye tid på rapportering. Ønsket er det samme: trykk på én knapp og få ut det Bufdir trenger. Norse Digital Products tar initiativ til dialog med Bufdir på vegne av alle organisasjonene.

### 1.5 Inkrementell utrulling – parallelle systemer

Sterk enighet på tvers: Eksisterende løsninger må fungere parallelt til appen er godt etablert. Ingen av organisasjonene tåler et hard-cut. Appen skal introduseres som et til-bud, ikke et pålegg.

- **NHF:** «Ikke steng det gamle før folk er klare.»
- **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side.
- **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling.

### 1.6 Testoppsett: TestFlight, 5–8 personer, én kontaktperson

Alle tre organisasjoner er enige om samme testmetode: iOS-distribusjon via TestFlight, 5–8 testpersoner med spenn i kjønn, alder og digitale ferdigheter, og én dedikert kontaktperson per organisasjon som filtrerer og samler tilbakemeldinger. Første testversjon er målsatt til våren.

## 2. Delte behov – nevnt av to av tre organisasjoner

Disse behovene er ikke universelle, men er sterke nok til å vurderes som del av kjerneprodukt.

### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet)

Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav:

- Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett).
- Kvitteringsbilde for utlegg over 100 kr (HLF).
- Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF).
- Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet).
- API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF).

### 2.2 Gamification og synliggjøring av innsats (NHF + HLF)

Begge organisasjoner er inspirert av Spotify Wrapped og ønsker en funksjon som viser likepersonens bidrag over tid – «Din likepersonsårek». Målet er å gi frivillige stolthet og motivasjon, og gjøre usynlig innsats synlig. Også nevnt: «Årets koordinator», statusbadges og halvårsoppsummeringer.

### 2.3 Pausefunksjon for likepersoner (NHF + HLF)

Likepersoner skal kunne sette seg på pause (midlertidig deaktivering) uten å melde seg ut. Koordinator må varsles. HLF kobler dette til sertifisering: ved utgått sertifikat forsvinner likepersonen fra lokallagets nettsider automatisk.

### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF)

Ikke alle likepersoner vil eller kan bruke appen. Koordinatorer må ha mulighet til å registrere aktivitet på vegne av sine likepersoner, enten enkeltvis eller samlet for faste aktiviteter (f.eks. ukentlig trening med mange deltakere).

### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF)

Begge organisasjoner ønsker mulighet for å snakke inn rapporter fremfor å skrive. Blindeforbundet understreker at opptak under selve samtalen er uønsket – tale-til-tekst er for etterpå, ved rapportskriving.

## 3. Unike behov per organisasjon

### 3.1 Norges Blindeforbund – unike behov

- **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag.
- Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet.
- **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15.
- **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren.
- Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale.
- **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker).
- **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager.
- Gradvis digitalisering av fullmakter og epikriser med manuelt fallback.

### 3.2 Norges Handikapforbund – unike behov

- **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne.
- **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering.
- **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer.
- **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving.
- Samisk språkstøtte vurdert på sikt (NHF har samisk tilknytning).
- **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes.

### 3.3 Hørselsforbundet – unike behov

- **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel.
- **Kursadministrasjon og sertifisering:** Påmelding til kurs i appen, automatisk påminnelse ved utløp, digitale sertifikater. Det fysiske kortet er et «adelsmerke» og skal leve parallelt.
- **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre.
- **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering.
- **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel).

## 4. Behovsoversikt – prioriteringsmatrise

| Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Prioritet | Fase |
|-|-|-|-|-|-|-|
| Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
| Universell utforming / tilgjengelighet | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 (2 Blind.) |
| BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 |
| Bufdir-rapportering (automatisert) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 3 |
| Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | MUST HAVE | - |
| TestFlight-oppsett (iOS) / Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
| Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | SHOULD HAVE | 2 |
| Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | NICE TO HAVE | 4 |
| Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 |
| Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 |
| Tale-til-tekst | – | – | ✓ | ✓ | SHOULD HAVE | 2 |
| Kryptert informasjon | ✓ | ✓ | ✓ | ✓ | MUST | 1 |
| Formalisert rapportstruktur | ✓ | – | ✓ | – | NICE (Blindeforbundet) | 4 |
| Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | SHOULD (HLF) | 4 |
| Koordinering med ekstern portal | – | – | – | ✓ | MUST (HLF) | 3 |
| Dokumentvedlegg til aktiviteter | – | ✓ | – | – | NICE TO HAVE | 3 |
| Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
| Snakkekort | ✓ | ✓ | ✓ | ✓ | NICE | 3 |
| Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | NICE | 2 |
| Pårørende database | ✓ | – | – | – | NEED | 1 |
| Basic search (contact and notater) | ✓ | ✓ | ✓ | ✓ | MUST | 1 |
| Notater | ✓ | ✓ | ✓ | ✓ | NICE | 2 |

### Product Landscape — Meander Platform

Meander is the platform. It ships as three distinct products, each serving different users and purposes. All three products share the same PostgreSQL database and authentication system.

**Product 1: Meander Mobile App** (Flutter)
- Purpose: Day-to-day operational tool for peer mentors and coordinators
- Users: Peer Mentors (Likepersoner), Coordinators
- Core capabilities:
  - Activity registration (quick logging, wizards, bulk/proxy)
  - Contact and peer mentor management
  - Travel expense registration
  - Personal statistics and impact summaries
  - Push notifications and assignment tracking
  - Speech-to-text input, document attachments
  - Gamification (wrapped summaries, badges)
- Tech: Flutter, BLoC/Riverpod, WCAG 2.2 AA

**Product 2: Admin Web Portal** (Next.js)
- Purpose: Organization management, reporting, and oversight
- Users: Organization Admins, Coordinators, Global Admins
- Core capabilities:
  - User management (invite, deactivate, role assignment)
  - Organization settings and terminology/labels configuration
  - Bufdir report generation and one-click export
  - Activity oversight, approval workflows, and corrections
  - Reimbursement approval and expense oversight
  - Coordinator and organization-level dashboards and KPIs
  - Multi-organization hierarchy management
  - Course and certification administration
- Tech: Next.js on Vercel, server-side rendering, same auth system

**Product 3: Product Sales Website** (Next.js or static)
- Purpose: Commercial website to sell Meander to other organizations
- Users: Prospective organizations, buyers, decision-makers
- Core capabilities:
  - Product listing and feature showcase
  - Potential benefit calculator (ROI for organizations)
  - Demo booking flow
  - Privacy, Terms & Conditions, Data Processing Agreement, and SLA pages
  - Generate leads and drive sales conversions
- Tech: Next.js or static site, public-facing, no auth required

### Core Roles & Access Boundaries

Each organization has its own roles and users. Norse (the platform owner) manages global admins separately.

**4 defined user roles:**

- **Peer Mentor (Likeperson):** Creates and tracks activities and follow-ups. Mobile app only. Cannot access admin portal. Beginner-level digital skills assumed.
- **Coordinator:** Oversees peer mentors within their local association, dispatches assignments, approves expenses, registers on behalf of others. Mobile app + admin portal.
- **Organization Administrator (Org Admin):** Manages one organization's users, roles, reports, and statistics. Primarily admin portal. Can access mobile app.
- **Global Administrator:** Norse Digital Products staff. Cross-organization system management and support. Admin portal only. No default access to org user data/content. Critical principle: tenant separation — each org's data is isolated; global admins manage the system, not the org's operational data.

### Core Operational Flow

1. Peer mentor performs activity or event
2. Activity is registered and tracked in Meander Mobile App
3. Coordinator oversees follow-up, quality, and approval
4. Org Admin gets overview in Admin Web Portal
5. Structured data supports Bufdir reporting and analytics

### Shared Backend

- **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`)
- **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR)
- **PostgreSQL database** (standard, managed) — no vendor-specific extensions, pure SQL with migrations
- **Authentication:** JWT-based via REST API. BankID/Vipps for initial login, email/password as fallback. Mobile stores tokens securely (Keychain/Keystore). Admin portal uses HTTP-only cookies. Global admins authenticate separately (no org context).

### Mobile App Architecture

**Auth & Access**
- **No organization selection screen** — organization context is determined by the user's account (set during onboarding/invitation by admin). Users do NOT choose their organization at login.
- Email/password login
- BankID / Vipps login (Phase 2)
- Biometric session authentication (Face ID / fingerprint)
- Role-based access control — Peer Mentor and Coordinator roles
- No-access screen for Global Admin (redirected to admin portal)

**Navigation**
- Bottom nav with 5 tabs: Home, Contacts, Add, Work, Notifications
- Settings accessible from hamburger menu

**Screens**
- Role-specific home content (peer mentor vs coordinator variants)
- Contacts list with role-specific views
- Contact detail, edit, and peer mentor profile screens
- Activity wizard (multi-step: contact → date → time → duration → summary)
- Event wizard (multi-step: title → date → time → duration → location → summary)
- Settings and preferences
- Notification inbox

**Core/Shared**
- REST API client for all backend communication
- Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant
- Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table
- Organization labels system (dynamic terminology per org)

## 5. Anbefalt prioriteringsrekkefølge for teamet

### Fase 1 – MVP (alle organisasjoner, vår)

**Meander Mobile App (MVP scope):**
- Aktivitetsregistrering med lavest mulig antall klikk og standardverdier
- WCAG 2.2 AA compliance fra dag én
- E-post/passord innlogging (BankID/Vipps i fase 2)
- Enkel statistikkvisning per likeperson og per koordinator
- Kontaktliste og likepersonsoversikt
- 2 brukerroller i mobilapp: Peer Mentor, Koordinator

**Admin Web Portal (MVP scope):**
- Brukeradministrasjon (invitere, deaktivere, rolletildeling)
- Organisasjonsinnstillinger og terminologikonfigurasjon
- Aktivitetsoversikt og grunnleggende statistikk
- 2 brukerroller i admin: Organisasjonsadministrator, Global Administrator

**Shared Backend (MVP scope):**
- REST API (Next.js på Vercel) med PostgreSQL database
- JWT-basert autentisering
- Flerorganisasjonsstøtte (multi-tenancy)

**Product Sales Website (MVP scope):**
- Landingsside med produktbeskrivelse og fordeler
- Kontaktskjema / demo-booking
- Privacy policy og vilkår

### Fase 2 – Kjerneprodukt

- Bufdir-rapportering automatisert / eksport med ett klikk
- Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning)
- Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk)
- Pausefunksjon og bulkregistrering for koordinatorer
- Tale-til-tekst i rapportskriving

### Fase 3 – Vekst og engasjement

- Gamification / «Ditt likepersonsår»
- Kursadministrasjon og sertifisering (HLF)
- Dokumentvedlegg til aktiviteter
- Integrasjoner: Cornerstone, Consio, Dynamics, Xledger
- Mentorordning og karriereverksted (Blindeforbundet)

## 6. Fellesåpne punkter

- Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner.
- Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering.
- Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon.
- Barnekreftforeningen: Avklare behov som skiller seg fra de tre workshoporganisasjonene basert på forprosjektmaterialet.
- Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell.

## 7. Neste aksjonspunkter

### Mobiliseringsfase - Fase 0 frem til 13. mars

- Strategisk: Playing to win → Value prop (Alle)
- Oppdatere pengecase (Daniel & Lasse)
  - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler.
- Kontakte Bufdir (Daniel)
- Panorama
- Få opp nettside (Aleksander)
- Oversikt over hva vi har allerede utviklet (Marius og Aleksander)
- Plan for pilotering/testing (Marius, Aleksander og Gellert)
  - Featureoversikt
  - Raskt ut og iterere basert på læring
- Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert)

### Fase 1 MLP

- Scope to be decided
- Hva har vi allerede
- Hva må på plass
- Enkel admin

### Fase 2

- Bufdirrapportering
- Reiserefusjon
- Pause

### Fase 3

- Signering
- Snakkekort/toolbox
- Lenker til kurs
- Digitalt likepersonsbevis
- Validere value prop

### Fase 4

- Gamification
- Wrapped
- Spill
- Stikk motsatt av likepersonlogg
- Fordelskalkulator

# Tverrgående workshopsammendrag ## Behovskartlegging – Likepersonsapp **Norse Digital Products | NHF, Blindeforbundet, HLF (+ Barnekreftforeningen)** **Februar 2025** Dette dokumentet oppsummerer fellestrekkene og de unike behovene på tvers av workshoppene med Norges Handikapforbund (NHF), Norges Blindeforbund og Hørselsforbundet (HLF). Barnekreftforeningen inngikk i forprosjektet og er ikke inkludert som egen workshopdeltaker her. Formålet er å gi teamet et prioriteringsgrunnlag for videre utvikling. ## 1. Felles behov – går igjen i alle tre organisasjoner Følgende behov ble løftet frem – ofte ord for ord – i alle tre workshops. Dette er kjernen i hva appen MÅ løse. ### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle) Alle tre organisasjoner peker på dette som den aller viktigste funksjonen, og beskriver dagens situasjon som uholdbar. Fellesnevneren er at rapporteringen er så tungvint at det fører til massiv underrapportering – enten fordi folk ikke orker, eller fordi de ikke engang skjønner at det de gjør teller. - **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk. - **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst. - **HLF:** En likeperson hadde 380 enkeltregistreringer på ett år. Standardverdier (dagens dato, 30 min) som kan overstyres. 60–70 % av registreringene er uten refusjon og skal være ekstremt enkle. > **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg. ### 1.2 Universell utforming (WCAG 2.2 AA) Alle tre organisasjoner har brukere med svært ulike forutsetninger – motoriske, kognitive og sensoriske. Appen SKAL oppfylle **WCAG 2.2 nivå AA** som minimumskrav for alle skjermer og interaksjoner. - **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå. - **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle. - **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning. - **Kontrast og typografi:** Minimum 4.5:1 kontrast for tekst, 3:1 for store tekstelementer og UI-komponenter. Skalerbar skrift opp til 200%. Unngå tynne/kursive fonter. - **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size). - **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator. - Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen. - Varsling ved opplesning av sensitive felt (NHF). - **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements). ### 1.3 BankID / Vipps innlogging Alle tre organisasjoner peker på BankID eller Vipps som foretrukket autentisering ved førstegangs innlogging, med biometrisk innlogging (Face ID / fingeravtrykk) etterpå. En viktig bieffekt: Vipps-innlogging kan returnere personnummer tilbake til medlemssystemene, som i dag mangler dette for mange brukere. ### 1.4 Sømløs Bufdir-rapportering Alle tre organisasjoner mottar Bufdir-tilskudd og bruker mye tid på rapportering. Ønsket er det samme: trykk på én knapp og få ut det Bufdir trenger. Norse Digital Products tar initiativ til dialog med Bufdir på vegne av alle organisasjonene. ### 1.5 Inkrementell utrulling – parallelle systemer Sterk enighet på tvers: Eksisterende løsninger må fungere parallelt til appen er godt etablert. Ingen av organisasjonene tåler et hard-cut. Appen skal introduseres som et til-bud, ikke et pålegg. - **NHF:** «Ikke steng det gamle før folk er klare.» - **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side. - **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling. ### 1.6 Testoppsett: TestFlight, 5–8 personer, én kontaktperson Alle tre organisasjoner er enige om samme testmetode: iOS-distribusjon via TestFlight, 5–8 testpersoner med spenn i kjønn, alder og digitale ferdigheter, og én dedikert kontaktperson per organisasjon som filtrerer og samler tilbakemeldinger. Første testversjon er målsatt til våren. ## 2. Delte behov – nevnt av to av tre organisasjoner Disse behovene er ikke universelle, men er sterke nok til å vurderes som del av kjerneprodukt. ### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet) Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav: - Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett). - Kvitteringsbilde for utlegg over 100 kr (HLF). - Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF). - Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet). - API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF). ### 2.2 Gamification og synliggjøring av innsats (NHF + HLF) Begge organisasjoner er inspirert av Spotify Wrapped og ønsker en funksjon som viser likepersonens bidrag over tid – «Din likepersonsårek». Målet er å gi frivillige stolthet og motivasjon, og gjøre usynlig innsats synlig. Også nevnt: «Årets koordinator», statusbadges og halvårsoppsummeringer. ### 2.3 Pausefunksjon for likepersoner (NHF + HLF) Likepersoner skal kunne sette seg på pause (midlertidig deaktivering) uten å melde seg ut. Koordinator må varsles. HLF kobler dette til sertifisering: ved utgått sertifikat forsvinner likepersonen fra lokallagets nettsider automatisk. ### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF) Ikke alle likepersoner vil eller kan bruke appen. Koordinatorer må ha mulighet til å registrere aktivitet på vegne av sine likepersoner, enten enkeltvis eller samlet for faste aktiviteter (f.eks. ukentlig trening med mange deltakere). ### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF) Begge organisasjoner ønsker mulighet for å snakke inn rapporter fremfor å skrive. Blindeforbundet understreker at opptak under selve samtalen er uønsket – tale-til-tekst er for etterpå, ved rapportskriving. ## 3. Unike behov per organisasjon ### 3.1 Norges Blindeforbund – unike behov - **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag. - Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet. - **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15. - **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren. - Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale. - **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker). - **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager. - Gradvis digitalisering av fullmakter og epikriser med manuelt fallback. ### 3.2 Norges Handikapforbund – unike behov - **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne. - **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering. - **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer. - **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving. - Samisk språkstøtte vurdert på sikt (NHF har samisk tilknytning). - **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes. ### 3.3 Hørselsforbundet – unike behov - **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel. - **Kursadministrasjon og sertifisering:** Påmelding til kurs i appen, automatisk påminnelse ved utløp, digitale sertifikater. Det fysiske kortet er et «adelsmerke» og skal leve parallelt. - **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre. - **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering. - **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel). ## 4. Behovsoversikt – prioriteringsmatrise | Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Prioritet | Fase | |-|-|-|-|-|-|-| | Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Universell utforming / tilgjengelighet | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 (2 Blind.) | | BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 | | Bufdir-rapportering (automatisert) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 3 | | Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | MUST HAVE | - | | TestFlight-oppsett (iOS) / Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | SHOULD HAVE | 2 | | Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | NICE TO HAVE | 4 | | Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 | | Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 | | Tale-til-tekst | – | – | ✓ | ✓ | SHOULD HAVE | 2 | | Kryptert informasjon | ✓ | ✓ | ✓ | ✓ | MUST | 1 | | Formalisert rapportstruktur | ✓ | – | ✓ | – | NICE (Blindeforbundet) | 4 | | Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | SHOULD (HLF) | 4 | | Koordinering med ekstern portal | – | – | – | ✓ | MUST (HLF) | 3 | | Dokumentvedlegg til aktiviteter | – | ✓ | – | – | NICE TO HAVE | 3 | | Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Snakkekort | ✓ | ✓ | ✓ | ✓ | NICE | 3 | | Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | NICE | 2 | | Pårørende database | ✓ | – | – | – | NEED | 1 | | Basic search (contact and notater) | ✓ | ✓ | ✓ | ✓ | MUST | 1 | | Notater | ✓ | ✓ | ✓ | ✓ | NICE | 2 | ### Product Landscape — Meander Platform Meander is the platform. It ships as three distinct products, each serving different users and purposes. All three products share the same PostgreSQL database and authentication system. **Product 1: Meander Mobile App** (Flutter) - Purpose: Day-to-day operational tool for peer mentors and coordinators - Users: Peer Mentors (Likepersoner), Coordinators - Core capabilities: - Activity registration (quick logging, wizards, bulk/proxy) - Contact and peer mentor management - Travel expense registration - Personal statistics and impact summaries - Push notifications and assignment tracking - Speech-to-text input, document attachments - Gamification (wrapped summaries, badges) - Tech: Flutter, BLoC/Riverpod, WCAG 2.2 AA **Product 2: Admin Web Portal** (Next.js) - Purpose: Organization management, reporting, and oversight - Users: Organization Admins, Coordinators, Global Admins - Core capabilities: - User management (invite, deactivate, role assignment) - Organization settings and terminology/labels configuration - Bufdir report generation and one-click export - Activity oversight, approval workflows, and corrections - Reimbursement approval and expense oversight - Coordinator and organization-level dashboards and KPIs - Multi-organization hierarchy management - Course and certification administration - Tech: Next.js on Vercel, server-side rendering, same auth system **Product 3: Product Sales Website** (Next.js or static) - Purpose: Commercial website to sell Meander to other organizations - Users: Prospective organizations, buyers, decision-makers - Core capabilities: - Product listing and feature showcase - Potential benefit calculator (ROI for organizations) - Demo booking flow - Privacy, Terms & Conditions, Data Processing Agreement, and SLA pages - Generate leads and drive sales conversions - Tech: Next.js or static site, public-facing, no auth required ### Core Roles & Access Boundaries Each organization has its own roles and users. Norse (the platform owner) manages global admins separately. **4 defined user roles:** - **Peer Mentor (Likeperson):** Creates and tracks activities and follow-ups. Mobile app only. Cannot access admin portal. Beginner-level digital skills assumed. - **Coordinator:** Oversees peer mentors within their local association, dispatches assignments, approves expenses, registers on behalf of others. Mobile app + admin portal. - **Organization Administrator (Org Admin):** Manages one organization's users, roles, reports, and statistics. Primarily admin portal. Can access mobile app. - **Global Administrator:** Norse Digital Products staff. Cross-organization system management and support. Admin portal only. No default access to org user data/content. Critical principle: tenant separation — each org's data is isolated; global admins manage the system, not the org's operational data. ### Core Operational Flow 1. Peer mentor performs activity or event 2. Activity is registered and tracked in Meander Mobile App 3. Coordinator oversees follow-up, quality, and approval 4. Org Admin gets overview in Admin Web Portal 5. Structured data supports Bufdir reporting and analytics ### Shared Backend - **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`) - **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR) - **PostgreSQL database** (standard, managed) — no vendor-specific extensions, pure SQL with migrations - **Authentication:** JWT-based via REST API. BankID/Vipps for initial login, email/password as fallback. Mobile stores tokens securely (Keychain/Keystore). Admin portal uses HTTP-only cookies. Global admins authenticate separately (no org context). ### Mobile App Architecture **Auth & Access** - **No organization selection screen** — organization context is determined by the user's account (set during onboarding/invitation by admin). Users do NOT choose their organization at login. - Email/password login - BankID / Vipps login (Phase 2) - Biometric session authentication (Face ID / fingerprint) - Role-based access control — Peer Mentor and Coordinator roles - No-access screen for Global Admin (redirected to admin portal) **Navigation** - Bottom nav with 5 tabs: Home, Contacts, Add, Work, Notifications - Settings accessible from hamburger menu **Screens** - Role-specific home content (peer mentor vs coordinator variants) - Contacts list with role-specific views - Contact detail, edit, and peer mentor profile screens - Activity wizard (multi-step: contact → date → time → duration → summary) - Event wizard (multi-step: title → date → time → duration → location → summary) - Settings and preferences - Notification inbox **Core/Shared** - REST API client for all backend communication - Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant - Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table - Organization labels system (dynamic terminology per org) ## 5. Anbefalt prioriteringsrekkefølge for teamet ### Fase 1 – MVP (alle organisasjoner, vår) **Meander Mobile App (MVP scope):** - Aktivitetsregistrering med lavest mulig antall klikk og standardverdier - WCAG 2.2 AA compliance fra dag én - E-post/passord innlogging (BankID/Vipps i fase 2) - Enkel statistikkvisning per likeperson og per koordinator - Kontaktliste og likepersonsoversikt - 2 brukerroller i mobilapp: Peer Mentor, Koordinator **Admin Web Portal (MVP scope):** - Brukeradministrasjon (invitere, deaktivere, rolletildeling) - Organisasjonsinnstillinger og terminologikonfigurasjon - Aktivitetsoversikt og grunnleggende statistikk - 2 brukerroller i admin: Organisasjonsadministrator, Global Administrator **Shared Backend (MVP scope):** - REST API (Next.js på Vercel) med PostgreSQL database - JWT-basert autentisering - Flerorganisasjonsstøtte (multi-tenancy) **Product Sales Website (MVP scope):** - Landingsside med produktbeskrivelse og fordeler - Kontaktskjema / demo-booking - Privacy policy og vilkår ### Fase 2 – Kjerneprodukt - Bufdir-rapportering automatisert / eksport med ett klikk - Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning) - Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk) - Pausefunksjon og bulkregistrering for koordinatorer - Tale-til-tekst i rapportskriving ### Fase 3 – Vekst og engasjement - Gamification / «Ditt likepersonsår» - Kursadministrasjon og sertifisering (HLF) - Dokumentvedlegg til aktiviteter - Integrasjoner: Cornerstone, Consio, Dynamics, Xledger - Mentorordning og karriereverksted (Blindeforbundet) ## 6. Fellesåpne punkter - Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner. - Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering. - Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon. - Barnekreftforeningen: Avklare behov som skiller seg fra de tre workshoporganisasjonene basert på forprosjektmaterialet. - Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell. ## 7. Neste aksjonspunkter ### Mobiliseringsfase - Fase 0 frem til 13. mars - Strategisk: Playing to win → Value prop (Alle) - Oppdatere pengecase (Daniel & Lasse) - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler. - Kontakte Bufdir (Daniel) - Panorama - Få opp nettside (Aleksander) - Oversikt over hva vi har allerede utviklet (Marius og Aleksander) - Plan for pilotering/testing (Marius, Aleksander og Gellert) - Featureoversikt - Raskt ut og iterere basert på læring - Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert) ### Fase 1 MLP - Scope to be decided - Hva har vi allerede - Hva må på plass - Enkel admin ### Fase 2 - Bufdirrapportering - Reiserefusjon - Pause ### Fase 3 - Signering - Snakkekort/toolbox - Lenker til kurs - Digitalt likepersonsbevis - Validere value prop ### Fase 4 - Gamification - Wrapped - Spill - Stikk motsatt av likepersonlogg - Fordelskalkulator