Alerts - Designmönster

Alerts - Designmönster

Användare behöver kontextuell och tydlig återkoppling när något i gränssnittet kräver deras uppmärksamhet – oavsett om det rör sig om information, en varning, ett fel eller en bekräftelse. Utan tydliga och konsekventa alerts riskerar viktig information att missas, feltolkas eller skapa onödig oro. Alerts ska stödja användaren i att förstå situationen och agera rätt – utan att störa eller hindra det primära flödet.

 

Användning

Mål 

Säkerställa att användaren:

  • Uppfattar viktig information vid rätt tidpunkt

  • Förstår allvarlighetsgraden och vad som förväntas av dem

  • Kan agera eller gå vidare utan onödig friktion

  • Inte störs av alerts som saknar relevans för det de håller på med

Använd när

  • Systemet behöver kommunicera ett tillstånd som påverkar användaren eller deras uppgift

  • En handling har resulterat i ett fel, en varning eller en bekräftelse

  • Användaren behöver information innan, under eller efter en åtgärd

  • Viktigt innehåll behöver lyftas fram utan att kräva en separat vy

 

Använd inte när

  • Informationen kan infogas som löpande text i gränssnittet

  • Feedback är tillfällig och kortvarig – överväg då Ribbon-varianten eller en toast-liknande lösning

  • Allvarlighetsgraden inte motiverar en alert (t.ex. generell hjälptext)

  • Alerts staplas upprepat i samma vy utan tydlig prioritering

 


Varianter

Default

Den primära alert-varianten. Har en tydlig rubrik och tar mer visuellt utrymme, vilket gör den lämplig när informationen är central för en hel vy eller ett större sammanhang.

Passar för: Systemmeddelanden som berör hela sidan, felhantering vid sidinläsning, viktig information inför ett kritiskt flöde.

image-20260521-092117.png
Varianten Default (wireframe-tema) i mobil- och desktop-storlek

 

 Collapsed / Expanded

Samma visuella grund som Default, men med möjlighet att fälla ut och in innehållet. Passar när en alert innehåller mycket information som annars tar för mycket plats i gränssnittet.

Passar för: Detaljerade felmeddelanden med flera underpunkter, teknisk information som inte alla användare behöver ta del av, listor med åtgärder eller förklaringar.

image-20260521-092216.png
Varianten Collapsed/Expanded (wireframe-tema) i mobil- och desktop-storlek

 

Compact

Saknar rubrik och tar mindre plats. Lämplig för kortfattad information som är kopplad till en specifik funktion eller ett avgränsat steg i ett flöde – snarare än till hela vyn.

Passar för: Inline-feedback i formulär, kontextuell information nära en enskild komponent, korta statusmeddelanden i ett pågående flöde.

image-20260521-092312.png
Varianten Compact (wireframe-tema) i mobil- och desktop-storlek

 

Ribbon

Tar minst visuellt utrymme av varianterna. Fungerar som substitut till toast i Inera Design System, och passar för kortfattade meddelanden som inte kräver användarens aktiva handling.

Passar för: Bekräftelser efter genomförd åtgärd, icke-kritiska statusuppdateringar, tidsbegränsad information som inte blockerar flödet.

image-20260521-092432.png
Varianten Ribbon (wireframe-tema) i mobil- och desktop-storlek

 


Statusar

Blå — Information

Används för att ge neutral information utan koppling till ett problem eller ett krav på åtgärd.

Riktlinjer för innehåll:

  • Låt användaren veta vad som händer eller kommer att hända

  • Inkludera en länk till mer information om den finns tillgänglig

  • Håll meddelandet kort och inkludera endast relevant information

  • Kom till saken direkt – undvik utfyllnad

Exempel på användning: Planerat underhåll, ny funktionalitet som påverkar flödet, kontextuell bakgrundsinformation.

image-20260521-095729.png
Information-status i mobil- och desktop-storlek

 

Gul — Uppmärksamma (Attention)

Används för att visa information som användaren bör vara uppmärksam på, men som inte nödvändigtvis kräver en omedelbar åtgärd.

Riktlinjer för innehåll:

  • Ha empati för användaren – informera utan att skapa onödig oro

  • Om varningen föregår en handling: kommunicera tydligt vad som händer om användaren fortsätter

  • Se till att meddelandet handlar om något som kan hända – inte något som redan har inträffat (det är då ett felmeddelande)

  • Sätt dig i användarens perspektiv: vad behöver de egentligen veta?

  • Håll meddelandet kort och inkludera endast relevant information

Exempel på användning: Ej sparade ändringar, session som löper ut, irreversibel åtgärd som användaren är på väg att utföra.

image-20260521-095914.png
Attention-status i mobil- och desktop-storlek

 

Grön — Bekräfta (Success)

Används för att bekräfta resultatet av en genomförd åtgärd.

Riktlinjer för innehåll:

  • Bekräfta resultatet och håll dig sedan ur användarens väg

  • Meddelanden som visas ofta bör vara kortfattade och ta lite fokus

  • Meddelanden efter en större eller mer sällsynt handling kan vara mer utförliga

  • Om användaren just har skapat något: ge tydlig visuell bekräftelse på det

Exempel på användning: Formulär skickat, inställningar sparade, fil uppladdad, objekt skapat eller borttaget.

image-20260521-095952.png
Success-status i mobil- och desktop-storlek

 

Röd — Fel (Error)

Används för att meddela användaren att något har gått fel.

Riktlinjer för innehåll:

  • Förklara vad som gick fel och ge användaren ett konkret nästa steg eller alternativ

  • Undvik skuld – ta ansvar om felet är på vår sida: "Vi har problem med att ansluta" snarare än "Du har anslutningsproblem"

  • Specificera felet – undvik generella meddelanden som kan gälla ett flertal situationer

  • Var tydlig och samtalande: förklara tekniska fel på ett sätt som även icke-tekniska användare förstår

  • Håll meddelandet enkelt och direkt – undvik att förvirra användaren med tekniska detaljer

Exempel på användning: Misslyckad inloggning, nätverksfel, valideringsfel vid formulärinskick, otillräcklig behörighet.

image-20260521-111718.png
Error-status i mobil- och desktop-storlek

 


Riktlinjer

Beteende

  • Alerts tonar in med en fade in-animation på 300 ms

  • En alert ligger på samma nivå som övriga komponenter i layouten och skjuter undan underliggande innehåll – den flyter inte ovanpå gränssnittet

  • Välj variant utifrån hur mycket visuellt utrymme informationen motiverar och hur centralt den är för användarens nuvarande uppgift

 

Visuell utformning

  • Allvarlighetsgrad kommuniceras alltid med färg och ikon – aldrig enbart färg (WCAG 1.4.1)

  • Rubriken (i Default och Collapsed/Expanded) ska vara kort och beskrivande

  • Brödtexten ska vara handlingsbar – användaren ska veta vad som förväntas av dem

  • Håll alerts kortfattade; använd Collapsed/Expanded-varianten om innehållet är omfattande

 

Innehåll och språk

  • Skriv i aktiv form och tilltala användaren direkt

  • Undvik teknisk jargong – formulera dig som om du förklarar för en icke-teknisk kollega

  • Felmeddelanden: förklara orsak och lösning

  • Varningar: beskriv konsekvens, inte bara tillstånd

  • Bekräftelser: svara på "vad hände?" och "vad händer nu?"

 


Gör / Gör inte 

Gör

  • Välj allvarlighetsgrad utifrån situationens faktiska karaktär

  • Håll innehållet kortfattat och relevant

  • Ge användaren ett konkret nästa steg i fel- och varningsmeddelanden

  • Använd Ribbon eller Compact när informationen inte motiverar mer visuellt utrymme

  • Säkerställ att meddelandet är synligt utan att användaren behöver leta

Gör inte

  • Blanda ihop allvarlighetsgrader – använd inte gul för att bekräfta, eller grön för att varna

  • Visa alerts i onödan eller utan tydlig koppling till användarens aktuella uppgift

  • Använda enbart färg för att kommunicera allvarlighetsgrad

  • Stapla flera alerts av samma typ i samma vy utan prioritering

  • Skriva generella felmeddelanden som gäller "allt möjligt"


Tillgänglighet

WCAG-relevanta kriterier

Kriterium

Beskrivning

1.3.1 Info and Relationships

Allvarlighetsgrad och status ska kommuniceras semantiskt, inte enbart visuellt

1.4.1 Use of Color

Färg får inte vara det enda sättet att förmedla information – ikon och text krävs alltid

1.4.3 Contrast

Text i alerts ska uppfylla kontrastkraven mot bakgrundsfärgen

4.1.3 Status Messages

Alerts som dyker upp dynamiskt ska kommuniceras till hjälpmedel utan att fokus flyttas

 

Riktlinjer

  • Dynamiska alerts som läggs till i DOM:en ska använda role="alert" (assertive) för fel, och role="status" (polite) för information och bekräftelser

  • Ikonen är dekorativ och ska ha aria-hidden="true" – statusen kommuniceras via texten och rollen

  • Om en alert innehåller interaktiva element (t.ex. en länk eller en stäng-knapp) ska dessa vara nåbara med tangentbord

  • Stäng-knappar ska ha ett tydligt tillgängligt namn, t.ex. aria-label="Stäng meddelande"

  • Collapsed/Expanded-varianten följer samma tillgänglighetskrav som accordion: aria-expanded och aria-controls på utlösarknappen

 


Sammanfattning

Alerts ska kommunicera rätt information, med rätt allvarlighetsgrad, vid rätt tidpunkt.

Välj variant utifrån hur centralt meddelandet är för användarens uppgift. Välj allvarlighetsgrad utifrån situationens faktiska karaktär – inte för att det "ser viktigt ut". Skriv alltid handlingsbart och konkret, och säkerställ att meddelandet är tillgängligt för alla användare oavsett hjälpmedel.