Ett behovsdrivet projekt startar inte med en lösning – utan med en verifierad förståelse för användarnas behov, kontext och mål. Internationella standarder (ISO 9241-210) och etablerade offentliga vägledningar (DIGG/Digitaliseringsguiden, GOV.UK Service Manual) ger en trygg grund för hur du organiserar, bemannar och styr arbetet från första dag. Den här checklistan samlar de praktiska punkterna du behöver för en säker, laglydig och effektfokuserad start.
A. Mandat, mål och omfattning
- Utse sponsor och serviceägare med mandat över budget, prioriteringar och vägval.
- Formulera effektmål som beskriver vilken nytta som ska uppnås för användare och verksamhet (inte bara leveranser).
- Avgränsa problembilden med en kort “problem statement” och definiera vilka målgrupper och livssituationer som ingår.
- Fasindela enligt beprövat upplägg (discovery → alpha → beta → live), så att ni sätter evidens före omfattande bygg.
B. Sätt rätt team från start
- Kärnroller: produkt-/serviceägare, user researcher, tjänste-/interaktionsdesigner, innehåll/klarspråk, utveckling, data/analys, tillgänglighet, jurist/dataskydd.
- Arbeta tvärfunktionellt och involvera verksamhetens frontlinje redan i upptäcktsfasen. Detta ligger i linje med ISO 9241-210:s krav på användarinvolvering och tvärfunktionellt arbete.
C. Efterlevnad och etik (måste-punkter innan insamling)
- Rättslig grund (GDPR): dokumentera vilken grund ni använder – i offentlig sektor ofta uppgift av allmänt intresse eller myndighetsutövning.
- DPIA/konsekvensbedömning om behandlingen sannolikt innebär hög risk för individers rättigheter och friheter.
- Informerat samtycke till medverkan i research (se myndighetsriktlinjer för hur man utformar information och tillvägagångssätt).
- Tillgänglighet som krav från dag 1: DOS-lagen gäller offentliga aktörer; planera för WCAG 2.2-efterlevnad i prototyper, test och drift.
D. Gör en enkel men skarp forskningsplan (discovery)
- Frågor och antaganden: vad behöver vi veta om användare, uppgifter och kontext för att fatta nästa beslut?
- Metodmix och rekrytering: planera intervjuer/observationer, enkäter och prototyptester; rekrytera representativt och inkluderande.
- Praktiknära riktlinjer: följ GOV.UK:s Service Manual för planering, genomförande och delning av user research.
E. Prototyp och test: gör rätt saker i rätt ordning
- Välj fidelitet efter frågan: börja lågt (skisser/wireframes) och öka till klickbar/kodad prototyp när ni behöver svar på uppgifts- och tillgänglighetsfrågor.
- Säkra testupplägg: modererade tester för djup och kontext; omodererade för snabb kvantifiering. GOV.UK beskriver båda uppläggen och hur de anpassas för distans.
- Använd gemensamma byggblock där möjligt (t.ex. DIGG/Ena för identitet och auktorisation) – minska komplexitet och risk tidigt.
F. Tillgänglighet i prototyp och test
- Automatiserad kontroll: kör t.ex. WCAG-kontroller som del i arbetssättet (komplettera alltid med manuell granskning).
- Manuell granskning och hjälpmedel: tangentbordsnavigering, skärmläsartest, tydligt fokus, kontrast och begripligt språk.
- Plan för tillgänglighetsredogörelse och felrapportering i linje med DOS-lagens tillsynspraxis.
G. Mätning: baslinjer och KPI:er
- Sätt baslinjer innan förändring (uppgiftsframgång, tid, felgrad, SUS eller liknande).
- Definiera tjänste-KPI:er i drift:
- Completion rate
- Cost per transaction
- Digital take-up
- User satisfaction
Dessa fyra är etablerad praxis i offentlig tjänsteutveckling och beskrivs operativt i Service Manual.
- Ägarskap för nyttor: koppla varje mått till ansvarig och uppföljning (nyttorealisering).
H. Styrning och beslutspunkter
- Tydliga “exit-criteria” per fas: enligt GOV.UK är discovery klar när ni vet om problemet är värt att lösa och varför samt har beslutsunderlag för att gå till alpha.
- Beslutslogg: dokumentera antaganden, evidens, risker och beslut – gör det spårbart för revision och lärande.
- Portföljstyrning: prioritera initiativ efter nytta, tidskritik och riskreduktion; skala upp det som fungerar.
I. Upphandling och återanvändning
- Undvik tidig lösningslåsning i kravställning. Beskriv behov och effekter i stället för färdig lösning.
- Inventera återanvändbart (komponenter, byggblock, befintliga avtal) för att minska ledtid och öka kvalitet. DIGG:s byggblocksprinciper stödjer just återanvändning.
J. Startpaket: dokument du bör ha klara
- Projekt-/tjänstekort (mål, målgrupper, omfattning, fas, risker).
- Forskningsplan (frågor, metod, urval, etik, GDPR/DPIA).
- Tillgänglighetsplan (WCAG 2.2, DOS-lagen, testmetod, redogörelse).
- Mätplan (KPI:er, baslinjer, datakällor, ansvar).
- Beslutslogg och kommunikationsplan (transparent styrning).
Vanliga fallgropar – och motdrag
- Ni börjar bygga innan ni förstått behovet. Tvinga fram en discovery med dokumenterade insikter och mätbara mål innan utveckling.
- Tillgänglighet ses som “sista steg”. Integrera WCAG-krav i prototyp/test och planera för DOS-tillsyn.
- Oklara juridiska förutsättningar. Lås rättslig grund och DPIA innan insamling – IMY:s vägledning klargör ramarna.
- Ingen koppling till nytta i drift. Sätt och publicera tjänste-KPI:er (completion, cost per transaction, digital take-up, satisfaction) och följ upp.
Snabbcheck (skriv ut och bocka av)
- Sponsor/serviceägare utsedd med mandat.
- Effektmål formulerade och fasindelning vald (discovery → alpha → beta → live).
- Team på plats (research, design, dev, innehåll, tillgänglighet, juridik).
- Rättslig grund och ev. DPIA dokumenterad; samtyckestexter klara.
- Tillgänglighetsplan enligt WCAG 2.2 och DOS-lagen.
- Forskningsplan + rekrytering planerad, inkl. inkluderande urval.
- Prototypstrategi och testupplägg valda; gemensamma byggblock inventerade.
- Mätplan med baslinjer och fyra tjänste-KPI:er.
- Beslutslogg och kommunikationsplan etablerade.