18 nov. 2025·3 min
Så bygger du en portal för offentlig service
En praktisk guide för att planera, designa och lansera en offentlig informationsportal: tillgänglighet, innehåll, säkerhet, drift och underhåll.
En praktisk guide för att planera, designa och lansera en offentlig informationsportal: tillgänglighet, innehåll, säkerhet, drift och underhåll.
En portal för offentlig service kan inte vara "allt för alla" på dag ett. Börja med att skriva en tydlig syftesbeskrivning som får plats på en sida och som kan läsas av upphandling, ledning och personal i frontlinjen.
Bestäm om portalen främst är:
Detta beslut påverkar allt som följer—från innehållsstruktur till identitetskontroller och support.
Lista dina nyckelgrupper och de viktigaste uppgifter de måste genomföra:
Håll det praktiskt: målgrupper definieras av vad de försöker göra, inte av demografi.
Kom överens om en liten uppsättning mätbara utfall, till exempel:
Planera hur ni mäter detta (analys, korta feedbackpromptar, samtalsmärkning).
Skriv ner verkligheter som formar omfattningen:
Ett enkelt mål- och mätbrief blir referenspunkten när prioriteringar konkurrerar senare—och håller projektet fokuserat på offentlig nytta.
Bra offentliga portaler börjar med tydlighet: vad försöker människor egentligen åstadkomma när de kommer hit? Om du designar utifrån interna avdelningar tvingar du invånare att översätta byråkrati till klar avsikt. Forskning hjälper dig att vända på det.
Börja med att samla "toppuppgifter" från källor ni redan har:
Sök efter mönster som “förnya”, “ansök”, “betala”, “rapportera” och “kontrollera status”. Dessa verb kommer senare forma navigationsetiketter, landningssidor och formulärflöden.
Välj ett par prioriterade tjänster (t.ex. tillstånd, bidrag, betalningar) och kartlägg resan ur användarens perspektiv. Inkludera:
Detta förhindrar en portal som förklarar policyer men inte hjälper människor att bli färdiga.
Håll personas enkla och praktiska: “Någon som söker hjälp första gången”, “En småföretagare som betalar en avgift”, “En invånare med begränsad svenska”. Fokusera på begränsningar (tid, stress, enhet, läsförmåga, tillgänglighetsbehov) snarare än demografi.
Gör korta intervjuer eller lätta användbarhetstester med prototyper eller skisser. Be deltagare göra nyckeluppgifter och berätta vad de förväntar sig. Ni hittar förvirrande termer, saknade steg och förtroendeproblem tidigt—innan innehåll och byggarbete blivit dyrt att ändra.
En portal för offentlig service lyckas när folk kan hitta vad de behöver snabbt—even om de inte vet vilken myndighet som ansvarar. Informationsarkitektur (IA) är ”kartan” över din sajt: vilket innehåll som finns, hur det grupperas och hur användare rör sig genom det.
Innan du ritar menyer, samla vad ni redan har:
Tagga varje objekt med grundläggande metadata (ämne, målgrupp, tjänstetyp, senaste uppdatering, ägarteam). Detta förhindrar att ni bygger om sidor som redan finns—och visar var innehåll är inaktuellt eller duplicerat.
De flesta invånare kommer med en avsikt: “förnya ett körkort”, “ansöka om bidrag”, “rapportera ett fel.” Strukturera kategorier runt dessa uppgifter istället för myndighetsnamn. Ett enkelt test: om någon inte kan gissa rätt menyalternativ utan att känna till myndighetsstrukturen behöver grupperingarna förbättras.
Där flera myndigheter bidrar till en resa, behandla det som en tjänst med tydliga steg. Länka till stödjande sidor (krav, dokument, kontakt) från en enda tjänstehub.
Sträva efter att nyckeltjänster nås på 2–3 klick från startsidan. Använd ett litet antal toppkategorier och framträdande genvägar för högefterfrågade uppgifter. Undvik “mega-menyer” fulla av interna termer; använd enkla etiketter som folk skulle säga högt.
Sök blir ofta primär navigation. Planera den avsiktligt:
Gör IA och navigationen väl så minskar ni samtal, klagomål och avhopp—samt gör portalen lugn och trovärdig.
Tillgänglighet är inte ett “trevligt att ha” för en offentlig webbplats—det är en del av att ge lika tillgång till tjänster. Sikta på att uppfylla WCAG (vanligtvis WCAG 2.2 AA) och behandla tillgänglighet som ett designkrav, inte en slutgranskning.
Använd klar sidstruktur: en huvudrubrik (H1), logiska underrubriker (H2/H3) och beskrivande länktext (undvik “klicka här”). Konsekvent navigation och förutsägbara sidlayouter hjälper alla, inklusive användare med kognitiva svårigheter och personer som använder skärmläsare.
Gör läsbarheten enkel: välj kontraststarka färger, behåll rimliga radlängder och undvik liten text. Interaktiva element ska ha tydliga fokusindikatorer så tangentbordsanvändare alltid ser var de är.
Automatiska kontroller är användbara, men fångar inte allt. Inkludera manuella tester som en del av definitionen för färd:
Inkluderande design handlar också om ord. Använd lätt språk, förklara nödvändiga steg och undvik jargong och obegripliga akronymer. Om ett begrepp måste användas (t.ex. ett juridiskt uttryck), definiera det där det förekommer.
Formulär är ofta stället där användare fastnar. Se till att varje fält har en synlig etikett, tydlig hjälpinformation där förvirring kan uppstå, och felmeddelanden som är specifika och annonserade till hjälpmedelsteknik (t.ex. “Ange ditt personnummer” snarare än “Ogiltig inmatning”). Lita inte enbart på färg för att indikera fel.
Lägg upp en tillgänglighetsdeklaration som förklarar efterlevnadsstatus, kända problem och kontaktvägar för att rapportera problem. Placera den i footern (t.ex. /accessibility) och säkerställ att feedbackkanaler övervakas och besvaras.
Börja med att bestämma om portalen främst ska vara information, transaktioner eller både med ett begränsat antal tjänster vid lansering. Skriv sedan en en-sidig syftesbeskrivning och kom överens om några mätbara resultat (t.ex. uppgiftsfullföljande, färre samtal, tid till publicering av uppdateringar).
Detta håller omfattningen realistisk och ger en referens när prioriteringar kolliderar.
Namnge målgrupper utifrån uppgifterna de behöver utföra, inte demografi. Typiska grupper är invånare, besökare, företag och intern personal.
För varje grupp, lista toppuppgifter som “ansöka”, “förnya”, “betala”, “rapportera” eller “kontrollera status” och använd dessa uppgifter för att styra navigation och innehållsprioriteringar.
Använd mätvärden som speglar verkliga serviceutfall och som är lätta att följa:
Bestäm i förväg hur ni ska mäta dem (analysverktyg, feedbackpromptar, samtalsmärkning).
Börja med efterfrågesignaler ni redan har:
Letar efter återkommande verb som “ansök”, “förnya”, “betala” och validera sedan med snabba intervjuer eller användbarhetstester innan ni bygger fullt ut.
Kartlägg resan för ett fåtal högprioriterade tjänster ur användarens perspektiv:
Detta förhindrar en portal som bara förklarar regelverk utan att hjälpa människor att faktiskt slutföra sina ärenden.
Gör först en ärlig innehållsinventering (sidor, PDF:er, formulär, mikrosajter) och tagga objekt med grundläggande metadata som ämne, ägare och senaste uppdatering.
Organisera sedan navigation kring användaruppgifter (t.ex. “Ansök”, “Betala”, “Rapportera”) istället för myndighetsstruktur, med målet att nyckeltjänster ligger 2–3 klick från startsidan.
Behandla tillgänglighet som ett designkrav och som en del av definitionen för färdigt. Viktiga åtgärder:
Publicera en tillgänglighetsdeklaration på en konsekvent väg som /accessibility och ge en bevakad feedbackkanal.
Definiera ett enkelt system för vem som skriver, granskar, godkänner, publicerar och uppdaterar innehåll—använd namngivna roller, inte “avdelningen”.
Lägg till livscykelregler (granskningsdatum, arkivering) och en stilguide som standardiserar terminologi, format (datum/tid/adresser) och länkskrivning. Detta håller informationen korrekt och konsekvent över tid.
Prioritera översättning för sidor som påverkar någons förmåga att slutföra toppuppgifter:
Undvik maskinöversättning för kritiska juridiska/säkerhets-/ekonomiska instruktioner. Se till att språkbytaren behåller användarens plats och bygg in översättningsstatus och granskningsscheman i publiceringsflödet.
Välj ett CMS som stödjer rollbaserade behörigheter, godkännandeflöden, revisionsspår och versionshistorik med enkel återställning. Strukturera innehåll i fält (behörighet, avgifter, handläggningstid, dokument) så att det kan återanvändas i sökresultat och relaterade block.
Planera integrationer tidigt (formulär, betalningar, ärendehantering, bokning) och sätt icke-förhandlingsbara krav som HTTPS, MFA för personal, dataminimering, CDN/caching för publika sidor och övervakning från dag ett.