Riktlinje 1

Lär känna användaren

Varje digitalt projekt måste baseras på behov och insikter från riktiga användare. Vilket problem vill användaren få löst och hur ska vår lösning passa in i hennes vardag? Oavsett målgrupp för projektet så måste riktiga användare vara med från starten. Varje teknik- och designval som görs bör baseras på hennes behov. Alltefter projektet fortlider så bör insikter från användarna samlas in.

Nyckelfrågor

  • Vem är den primära användaren?
  • Varför vill användaren använda produkten?
  • Vilka användarbehov skall produkten lösa?
  • Var/när/hur kommer produkten användas?
  • Hur har vi validerat att behovet verkligen finns?

Checklista

  • Har ni träffat era användare?
  • Är det tydligt för alla parter i projektet vem användaren är?
  • Har ni validerat att användarnas upplevda behov stämmer överens med verkligheten?
  • Har tydliga mål och/eller effekter skapats för projektet? Hur ska ni mäta framgång?
  • Har ni testat prototyper m.m. med faktiska användare?
Riktlinje 2

Basera beslut på data

Vi skall vara duktiga på att mäta hur väl våra tjänster fungerar för invånarna. Genom att redan från starten i ett projekt identifiera relevanta mätpunkter så kan vi samla in statistik som leder till välgrundade beslut. I existerande verksamhet skall insamlad data såsom besökarstatistik, CR, upptid m.m. ligga till grund för prioritering av buggar och kommande funktioner.

Nyckelfrågor

  • Vilka är tjänstens primära mättal?
  • Har alla inblandade i projektet möjlighet att ta del av den data som samlas in?
  • Hur samlar vi in kundinsikter?
  • Hur sammanställs historiska data för tjänsten? Hur väl levererar vi på mättalen?
  • Vilka forum/arbetssätt/processer finns för att analysera och agera på insamlad data?

Checklista

  • Har verktyg för att mäta besöksstatistik implementeras?
  • Hur mäter vi våra mål? Har t.ex. mål definerats i Google Analytics
  • Hur kan användarna lämna feedback på tjänsten?
  • Hur kan vi mäta och analysera vilka delar av tjänsten som inte används? T.ex. via hög bounce-rate? låga besökstal, antal klick osv?
  • Hur kan vi mäta flöden mellan kanaler? T.ex. mellan regionhalland.se och halland.se?
Riktlinje 3

Lös hela kundresan

För att skapa en så bra produkt som möjligt för användaren så behöver vi förstå hela resan som användaren gör från uppkomsten av ett behov tills att det har tillfredställts. Vi ser idag hur användare sömnlöst rör sig mellan flera olika enheter och blandar on- och offline aktiviteter. Varje steg användaren tar, oavsett kanal, skall föra henne närmare en lösning!

Nyckelfrågor

  • Vilka är produktens primära mättal?
  • När har användaren behov av att nyttja tjänsten? I vilka sammanhang? Var befinner hon sig?
  • Vart finns de största kruxen för användaren i dagens sätt att lösa de problem vår tjänst skall hantera?

Checklista

  • Skapa kundresan för era primära use case
  • Identifiera de störta kruxen med hur användarna löser sitt problem idag
  • Ta fram mättal för hur väl tjänsten löser användarens problem i varje skede av kundresan
  • Designa tjänsten så att online och offline touchpoints är integrerade och genererar mervärde
Riktlinje 4

Gör det enkelt & intuitivt

Att använda våra tjänster skall vara enkelt, intuitivt och gärna roligt. Användarna skall, utan hjälp, klara av att lösa sitt problem första gången de använder tjänsten.

Nyckelfrågor

  • Vad är tjänstens primära användarmål?
  • Vilka funktioner kan tas bort utan att det primära användarmålet påverkas?
  • Är designen av tjänsten enhetlig med övriga tjänster vi erbjuder?
  • Är språket så enkelt och tydligt som möjligt?
  • Om användaren behöver hjälp med tjänsten, hur får den det?

Checklista

  • Använd en design som användaren känner igen
  • Använda etablerade designmönster
  • Var tydlig med att förklara vart i processen användaren befinner sig
  • Följ givna standarder för tillgänglighet, säkerställ att alla kan använda tjänsten
  • Automatisera så mycket som möjligt för användaren, t.ex. vid inmatning i formulär
  • Fokusera alltid på att låta användaren komma vidare med tjänstens primära användarmål
  • Använd ett enkelt och enhetligt språk
Riktlinje 5

Var öppen

Genom att samarbeta öppet och publicera våra data offentligt kan vi förbättra verksamheten tillsammans. Genom att förenkla allmänhetens tillgång och insyn i våra projekt så ökar vi chansen att vi bygger rätt och satsar på rätt funktioner. När vi blir duktiga på att dela med oss av vår kunskap, vår kod och våra insikter så skapar vi möjligheter för nya sammarbeten där privatpersoner, företag eller andra myndigheter kan återanvända det vi tagit fram.

Nyckelfrågor

  • Hur snabbt kan vi få ut en beta version av vår tjänst?
  • Hur samlar vi in kundinsikter?
  • Vilka komponenter(javascript plugins, HTML-mallar m.m.) kan vi släppa som öppen källkod?
  • Vilka API:er skall tjänsten erbjuda?
  • Vilka dataset skall tjänsten erbjuda?
  • Varför kan vi inte publicera källkoden?

Checklista

  • Erbjud användarna ett sätt att lämna feedback på tjänsten
  • Erbjud kompletta dataset och API:er till invånarna
  • Säkerställ att vi äger den källkod som produceras för tjänste, t.ex. av tredje part.
  • Om möjligt; var publik med framtagningen av tjänsten, t.ex. genom en utvecklingsblogg.
  • Säkerställ att den data som vi släpper publikt är fri att använda, t.ex. genom CC0 1.0 Universal (CC0 1.0)
Riktlinje 6

Arbeta iterativt

Vi skall släppa nya funktionalitet till användaren så ofta som möjligt. Genom att arbeta iterativt med små förbättringar minimerar vi risken att missa våra mål. Nya funktioner skall nå användaren så snabbt som möjligt så att våra team kan värdera utfallet och anpassa efter verkligheten.

Nyckelfrågor

  • Hur lång tid tog det innan ni lanserade en MVP av tjänsten? om det inte hänt än, varför?
  • Hur många gånger i månaden kan ni släppa ny funktionalitet?
  • Hur samlar ni in buggar och nya önskemål på funktioner o.d.?
  • Hur hanterar ni backloggen? Vilket verktyg använder ni?
  • Hur ofta diskuteras backloggen med stakeholders?

Checklista

  • Skapa en backlogg för tjänsten och prioritera den tillsammans med dina stakeholders efter varje sprint/release
  • Släpp en MVP-version av tjänsten till användaren så snabbt som möjligt och analysera reaktionen
  • Genomför återkommande användartester
  • Skapa en så liten organisation kring tjänsten som möjligt.
  • Automatisera testning och releaseprocess i möjligaste mån
  • Använd versionshantering
  • Automatisera kodgranskning så mycket som möjligt
Riktlinje 7

Tillsätt en produktägare och gör den ansvarig

Varje tjänst vi producerar skall ha en tydlig ägare. Denna personen skall vara den självklara kontakten för alla stakeholders och leda utvecklingsteamen i deras arbete. Produktägaren äger backloggen och prioriterar den baserat på givet nuläge.

Nyckelfrågor

  • Vem är produktägare?
  • Vilka organisatoriska förändringar har genomförts för att möjliggöra produktägarens arbete? Vilken auktoritet och vilken support har produktägaren?

Checklista

  • Har en produktägare tillsatts?
  • Har alla typer av styrgrupper, referensgrupper, ledningsgrupper o.d. avskaffats inom ramen för projektet?
  • Är alla i projektet (utvecklingsteam, stakeholders m.fl.) medvetna om att produktägaren är den som prioriterar arbetet och bestämmer vad som skall göras
  • Har produktägare erfarenhet av tjänsteutveckling? av digital design? av teknisk utveckling?
  • Har produktägare erfarenhet av
  • Har produktägaren tillräckligt med erfarenhet för att kunna göra konsekvensanalyser av omprioriteringar av backloggen?
  • Har produktägaren varit med och tillsatt teamet?
Riktlinje 8

Skapa en organisation fokuserad på leverans

Vilken kompetens behövs för att leverera på de mättal som tjänsten har? Två av de viktigaste nycklarna för att skapa en god digital upplevese ligger i att dels ha ett team som kan ta varje problem från ax till limpa och dels i att ge teamet och dess objektägare tillräckligt med frihet/mandat i organisationen att göra just detta.

Nyckelfrågor

  • Kan teamet hantera alla aspekter av utveckling (design, ux, utveckling, innehåll osv.) av tjänsten?
  • Vilka stakeholders finns för tjänsten? Hur förs dialogen med dem?
  • Förstår alla inblandade hur deras roll bidrar till ökad leveranstakt?

Checklista

  • Utvecklingsteamet har medlemmar med erfarenhet av mobila gränssnitt
  • Utvecklingsteamet har medlemmar med erfarenhet av att utveckla säkra digitala tjänster
  • Utvecklingsteamet har medlemmar med erfarenhet av IT-säkerhet
Riktlinje 9

Använd moderna tekniklösningar

De val vi gör gällande teknik måste i första hand främja våra utvecklingsteam så att de kan arbeta effektivt och så snabbt som möjligt leverera bästa tänkbara lösning för våra användare. Våra val av databaser, ramverk, servrar m.m. skall kunna hantera skalbarhet och motvärka inlåsningseffekter till en viss teknik eller leverantör. Vi bör alltid sträva efter att nyttja tekniker med standardiserade lösningar, gärna som bygger på öppen källkod.

Nyckelfrågor

  • Finns det risk för att vi valt en teknik som låser oss till en viss leverantör eller arkitektur?
  • Hur ser vår teknikstack ut, mao. vilka ramverk, databaser, servar osv. använder vi? Fungerar våra olika tekniker optimalt tillsammas? Kan vi skala bort något?
  • Hur lång tid tar det för en ny medarbetare att förstå vår teknikstack?
  • Har vi utvärderat vilka öppen källod alternativ som finns?
  • Är utveckling av tjänsten bunden till ett visst operativsystem? Om ja, varför?

Checklista

  • Utifrån vilka premisser har vi utvärderat vårt teknikval? Har t.ex. en redaktör testat admingränssnittet?
  • Har vi skapat enkla prototyper för att testa av den teknik vi valt?
  • Finns det tydliga instruktioner för hur du kommer igång, t.ex. hur du sätter upp en lokal utvecklingsmiljö?