Designprocess & aktiviteter
Ibland kan det vara bra att fundera på vad som behöver ingå i projektet. Listan nedan är inte en komplett lista och vad som passar in för respektive projekt varierar såklart men ta gärna en stund och gå igenom listan.
Listans rubriker utgår från Ineras Ledningssystem.
Innehåll:
Med hjärtat
Vi arbetar med tjänster och system som berör hela Sveriges befolkning. Att säkerställa att vi skapar de bästa förutsättningarna för att alla, oavsett vem hen är, ska kunna ta del av vår information och våra tjänster ska alltid vara kärnan i det vi gör.
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 https://inera.atlassian.net/wiki/spaces/USI/pages/10781831.
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 mer på https://inera.atlassian.net/wiki/spaces/USI/pages/575602957.
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: https://inera.atlassian.net/wiki/spaces/USI/pages/45189131
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 Myndigheten 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?
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 hanterar 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 ).
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 sitt barn som 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.
Research - hantera behoven
Processen ska säkerställa att vi fångar och förstår de behov av digitalisering som våra kunder och ägare har och prioriterar utveckling/initiativ som ligger i linje med Ineras strategi, skapar nytta samt är hållbara.
Omvärldsbevakning, hur ser omvärlden ut. Vad är bäst och sämst vad lär vi oss? Samla skärmdumpar på bra och smarta lösningar för återanvändning. Välj ut bra delar och samla ihop dem för återanvändning
Dataanalys, har vi data, vilket och vad kan vi lära oss av det?
KPI, Key Performance Indicators, ja dessa är svåra att identifiera i vår värld då vi inte säljer något. Vi använder ofta NKI (Nöjd Kund Index) som en indikator men också för kännedom då det kommer till Varumärken. Lägg energi på att hitta KPIer som kan bevisa att tiden vi lagt på UX har varit väl värt tiden. Utöver att ta fram KPIer måste du göra en så kallad Nollmätning, dvs mätning av användarupplevelse på befintliga system behöver göras med samma testsystem och frågor som det nya senare skall utföras på.
Användarinput, vad säger de användare vi har, kolla med kundservice eller liknande samt tidigare gjorda användarundersökningar.
Planera
Handlar om att arbeta med behoven och exempelvis ta fram användarresor och beskriva funktionalitet.
User Stories ä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 …
User Flows, användarflöden kan visa på de flöden som är tänkta att fungera i kommande system. Vi kan försöka skapa så enkla flöden som möjligt, där systemet gör så stor andel av arbetet som möjligt.
Det är bra om man har möjlighet att identifiera även de flöden som inte är det primärt önskade.
Brainstorm och massor av olika skisser. Fastna aldrig i första idén. Arbeta var för sig, låt alla i teamet skissa, samla ihop och värdera inputen och ta det bästa från varje. Plocka in det bästa från omvärldsbevakningen. Designmönster som redan finns och är använda är bra att bygga vidare på.
Co-creation, med våra komponenter så går det snabbt att skissa upp användarflöden och gränssnitt tillsammans med slutanvändare. Gör i ordning en Figmafil med komponenter som troligen kan komma att återanvändas och ordna dem tillsammans med användare för att ha som gemensam grund för diskussion och vidareutveckling.
Designa
Vi tar inledningsvis fram lösningsförslag i form av koncept, vilka senare ofta förädlas till prototyper som gör det lättare att löpande validera att lösningsförslaget tillgodoser de behov som verksamheten identifierat. Resultatet av detta processteg är en övergripande design.
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.
Visuell design ska följa riktlinjerna för varumärket och använda de komponenter som finns i designsystemet. Säkerställ att den visuella utformningen tar höjd för tillgänglighet och regelverket WCAG. Verifiera med ansvarig för det aktuella varumärket att skisserna är OK.
Wireframes, skapa enkla trådskisser (wireframes) i lämpligt verktyg och gör dem med fördel klickbara för att testa olika flöden. Det är först då det blir klickbart som man skapar sig en känsla för om det kommer fungera.
Prototyp, ibland kan det räcka med klickbara wireframes som prototyp, men ibland om man vill testa mer noggrant kan det vara en idé att bygga en prototyp.
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.
Övergångar, idag är övergångarna mellan olika system otroligt viktiga. Vilka ö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.
Utveckla och bygga
Utveckla och bygga innehåller delprocesser för det vi ofta kallar för applikationsutveckling, även om utvecklingen i praktiken börjar redan i Planera och designa. De flesta utvecklingsprojekt använder ett agilt arbetssätt vilket betyder att arbetet görs i mindre korta iterationer (sprintar).
UI-element, gå igenom vilka UI-element som finns inom ramen för Designsystemet på Inera så du är väl insatt i detta, såväl som de riktlinjer som finns för det varumärke som ditt projekt motsvaras av. Inera har i dagsläget varumärkena UMO, Youmo, 1177 och Inera. Inga andra finns och arbetet skall återspegla något av dessa.
Anpassningsbara UI:n (Responsivitet). Vi arbetar i samtliga webbar (undantag inera.se) med tänket Mobile first då användningen på mobila enheter oftast är i majoritet. Det innebär att det är mobila UI:n som primärt tas fram och det är också de som visas för vår omgivning först. I andra hand visar vi vad som sker på desktop, men nu börjar vi också titta på vad som sker när man t ex speglar upp en mobil på en stor skärm så som TV:n hemma.
Design reviews bör göras under arbetets gång för att verifiera att skisser/prototyper har följts under utvecklingsfasen och ser ut och fungerar som tänkt. Läs mer på .
Tillgänglighetstester bör också göras för att säkerställa att vi uppnått rätt nivå av tillgänglighet, att alla våra användare kommer kunna ta del av tjänsten och att vi följer lagar och regler. Läs mer på
Tänk även på…
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 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ärskilt uppmärksam hur knappar i meddelanden används så att t ex Stäng och Avbryt inte blandas ihop.
Gester, utöver klick på knappar, länkar och andra element blir det allt viktigare att beskriva gester som skall fungera i våra UI:n. Detta är något som ofta inte specificerats i våra UI:n och förväntade beteenden i våra gränssnitt fungerar inte. Fundera på var Tap eller klick inte kommer vara det naturliga, är det Swipe, Pinch, Rotate, Shake eller andra gester som behöver fungera?
Micro Interactions, 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. Exempel: "The Joy of Micro UX" och "Delightful Experience"
Leverera, stödja och följa upp
Syftet med flertalet av våra tjänster är att stödja verksamhetsutveckling genom digitalisering. Målet är att tjänsten skapar den nytta vi tänkt oss när tjänsten designades.
Ur ett användarperspektiv är det viktigt att vi följer upp att tjänsten skapar avsedd nytta. Detta bör göras löpande under tjänstens livscykel.
Verifiera KPI:er 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:
Avslut
Avsnittet avslut beskriver vad du som designer behöver göra när du avslutar ditt uppdrag på Inera för att efterkommande designers ska kunna förstå och ta del av det du gjort.
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. Kanske kan ditt projekt bidra med material till
eller
Kontrollera att allt på sidan är utfört.