Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

...

  •  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. Läs också det vi tar up under rubriken Copy
  •  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: 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 DigitaliseringsmyndighetenMyndigheten för Digital Förvaltning (DIGG).
  •  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?

...

  •  Väntetider, vi strävar alltid efter så korta responstider som möjligt i våra system men många gånger får vi vänta på svar från andra system (t ex sökning i annan katalog). Om du tror att väntetiden för en användare kan bli större än 1,5 sekunder bör tiden fyllas med något. 1,5-5 sek t ex en spinner, 6-30 sek återkoppling i procent eller liknande, gärna med information om vad som sker. Längre tider skall ha tydliga instruktioner hur aktivitet avbryts och reell feedback för vad som sker, t ex Läser in fil X på 500 Mb, 34%
  •  Felmeddelande, det är inte lätt att veta vilka fel som kan ske men i dialog med utvecklare ta reda på så många som möjligt och se över hur meddelande ser ut. Vi godkänner inte felmeddelande av teknisk karaktär som användare i ålgruppen målgruppen inte förstår. Den typen av felmeddelande får bara vara sekundär information.
  •  Återkoppling vid uppgift, det är vanligt att användaren interagerar med systemet och utför saker. I admin eller ofta-använda system kan återkoppling ske i meddelanderuta som användaren lärt sig titta i. I övrigt skall återkoppling ske med närhetens lag. Var särkilt uppmärksamhet särskilt uppmärksam hur knappar i meddelanden används så att t ex Stäng och Avbryt inte blandas ihop.

...

  •  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.: "The Joy of Micro UX" och "Delightful Experience"
  •  Övergångar, idag är övergångarna mellan olika system otroligt viktiga. Vilka övergånger övergångar 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: https://inera.atlassian.net/l/c/cSDxKbP0

Avslut

  •  Spara ner material på angiven plats.
    Normalt på Inera så sparar vi ner:
    - prototyper på GitHub, instruktion.
    - material i Figma i Ineras Figma-space.
    - 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.

...