Sidjämförelse

...

Planeringsfasen

•  User Stories, detta är en enkel och bra metod för att beskriva kraven där syftet och behovet framgår tydligt.
  Som en …
  Vill jag …
  För att …

...

•  Informationsarkitektur, det är viktigt att saker hänger ihop inte bara i flöden när man skall göra något utan också hur man hittar till det man skall göra. Bra verktyg för att skapa och testa informationsarkitektur tar vi upp på sidan: Verktyg som underlättar UX
•  Språket, på Inera har respektive redaktion olika språkliga riktlinjer det är viktigt att du stämmer av med redaktionen (när sådan finns) så att också språket i UI följer dessa riktlinjer.
•  Tillgänglighet, på Inera följer vi de lagar som finns. Då det gäller digital tillgänglighet som säkerställer att alla i samhället har möjlighet att ta del av information så är lagkravet om att uppnå WCAG 2.1 AA vår miniminivå. Läs mer på sidan: Tillgänglighet Digital tillgänglighet
  Vi redogör för tillgänglighet så som på: Tillgänglighetsredogörelse 1177 och Tillgänglighetsredogörelse VHB. Läs också mer om Lagen om tillgänglighet till digital offentlig service hos Digitaliseringsmyndigheten.
•  Hållbarhet, med digitala verktyg möjliggör vi en hållbarare värld. Exempel på hur vi bör tänka är att vi inte bygger särskilda funktioner för att skriva ut saker, vi uppmuntrar att mötas digitalt istället för att resa till osv. Vilka funktioner i ditt projekt bidrar till en mer hållbar värld och hur?
•  Etik, många av de områden vi arbetar inom kommer i kontakt med Etik-begreppet. Det är särskilt viktigt då det gäller t ex användartester med användare som har särskilda behov, hur hantera vi dem och ev register. Ibland under tester kan känsliga data bli synliga på skärmen och detta bör vi undvika (läs gärna Test med känsliga data ). Vi bör också fundera på etiska aspekter då vi skapa åtkomst till data som användarna kanske inte tänker på blir åtkomlig. Ett exempel för att förtydliga, genom ombudstjänst kan en förälder se in i journalanteckningar för sin dotter som har sökt hjälp för en abort.
•  Inkludering, våra tjänster är och skall alltid vara inkluderande. Vi designar enligt konceptet Design for All. Genom god tillgänglighet, hållbarhet och ett etiskt tänkande når vi fler i samhället och det sparar samhällsresurser.

...

•  Grafisk design ska följa riktlinjerna för varumärket och tas fram till alla vyer som behövs för att utvecklare skall kunna slutföra koden. Säkerställ att grafisk design tar höjd för tillgänglighet och regelverket WCAG. Verifiera med ansvarig för det aktuella varumärket att skisserna är OK.
•  Bilder och Ikoner, olika varumärken har olika regler för användning av bilder och ikoner. Kolla vad som gäller för det varumärke du arbetar med. Verifiera att bilder märks upp korrekt i kod och att de som behöver ALT-attribut får detta och de som inte skall ha (element som enbart används för layout) inte får det.
•  Typsnitt som vi använder skall i grunden inte ha licenskostnader. Det är enbart när det på grund av att varumärket kräver det som vi väljer typsnitt som medför extra kostnader. Det är alltid viktigast att typsnittet skapar god läsbarhet i det medium som skall användas. Det är därför OK att ha olika typsnitt för samma tjänst på olika plattformar, t ex print och digitalt. Sträva efter att behålla känslan mellan plattformarna dock. I samband med val av typsnitt tänk också noggrant igenom typsnittshierarkier, H1, H2, H3, Brödtext så väl som radlängd och radavstånd.
•  Färger och dess hierarki. På samma sätt som typsnittsstorlekar skapar hierarkier gör också färger och färgval detta. Säkerställ att du har koll på eventuellt varumärke och att de färgval som du gör följer kraven som ställs på kontraster gällande tillgänglighet.

Finess och glädje

•  Micro Copy, dvs de korta ord och meddelanden som tjänsten använder för att kommunicera med sina användare skall skapa en känsla av dialog med Du-tilltal i alla Ineras tjänster. Därefter kan tilltal variera något mellan olika tjänster men gemensamt är också att det skall skapa förtroende för tjänsten. Ställ samman en lista med vanliga meddelanden och skapa en enhetlighet i tilltal.
•  Micro Ineractions, på samma sätt som med ord och ordval kan små enkla animeringar skapa en känsla av glädje, förankring och återkoppling som i sig inte är informationsbärarna men som gör det trevligare att använda UI. ExempelAndra exempel.
•  Övergångar, idag är övergångarna mellan olika system otroligt viktiga. Vilka övergånger skall ni ha? Flyttas inloggningar, data eller annat i övergångarna ska detta tydliggöras. Övergångar finns också inom systemet och dessa får gärna förstärkas genom grafisk form eller animering.

...

•  Nu är det dags att verifiera de KPIer som tidigare togs fram. Gör om nollmätningarna på nya tjänsterna och utvärdera och analysera resultatet.
•  A/B-testning är något som vi tyvärr ofta bara kan/hinner göra på prototypstadiet och då är det såklart inte ett äkta A/B text. I den mån det går försök att möjliggöra för A/B-testning i systemet så att det är mindre svårt att göra framöver.
•  Användningstester gör vi på prototypstadiet och i samband med acceptanstest som minimum. Har vi möjlighet är det bra att också lägga till några enklare användningstester under systemtest, dels för att lära oss hur vårt system uppfattas och fungerar men också för att snabbt rätta till eventuella fel och brister. Läs mer under: Användartester

Avslut

•  Spara ner material på angiven plats.
  Normalt på Inera så sparar vi ner:
  - prototyper på GitHub, instruktion.
  - manualer på Confluence (om ditt projekt använder det)
  - arbetsmaterial i Teams (om ditt projekt använder det)
•  Gå igenom materialet som finns och fundera över vad som kan återanvändas och dela med dig till denna plats på Confluence.
•  Kontrollera att allt på sidan Process för exit ur projekt är utfört.