Modul 2, Användningsfall

På den här sidan

Modul 2

  • Användningsfallen beskriver vilka tjänster användarna behöver och hur dessa genomförs i systemet.
  • Planeringen av användargränssnittet styrs av väl utarbetade användningsfall. Med hjälp av dem skapas inga onödiga funktioner och innehåll i tjänsten.
  • Användningsfallen är centrala även med tanke på en lyckad användartestning av tillgängligheten.

Användningsfall och serviceutveckling

Webbtjänsten skapas i en programutvecklingsprocess, som nuförtiden allt oftare baseras på så kallad agil utveckling, men som särskilt i omfattande projekt även kan stöda sig på den mer traditionella vattenfallsmodellen eller kvalitetsportar genom vilka tjänsten måste gå innan vissa arbetsskeden färdigställs. I sådana modeller kan enskilda utvecklingsskeden på motsvarande sätt rekursivt baseras på samma utvecklingsprocess, eller verkställa ett från den processen fristående, mer agilt, iterativt utvecklingssätt.

Oberoende av formen på processen, ska man beakta planering av användningsfall i serviceutvecklingen. Tyvärr så sker detta ännu inte i alla webbtjänster, utan användningsfall anses ha en närmare koppling till programvaruprodukter. Webbtjänsten är dock lika mycket ett programvaruprojekt, och specifikationens roll är inte mindre i den – tvärtom: Erfarenheten av praktiska utvecklingsprojekt har visat att i synnerhet merparten av problemen kopplade till tillgänglighet uppstår redan i specifikationsskedet, som är bristfälligt eller som inte ens alltid genomförs. Tjänstens utveckling kan till och med inledas direkt med visualisering av användargränssnittet utan något beslut om vilka funktioner tjänsten överhuvudtaget ska utföra. Problemet har också upprepats i utvärderingen av läget för Helsingfors stads tjänster (Servicecentralen, 2020).

Användningsfall är både en grund för specifikationen och en förutsättning för en effektiv användartestning av tillgänglighet. Därför fäster man särskild uppmärksamhet vid användningsfall i Helsingfors tillgänglighetsmodell.

Användningsfall: Use case och User story

Med användningsfall (use case) avses en funktion eller en serie funktioner som användaren utför i tjänsten så att tjänsten kan uppfylla ett behov som anvisats till den. I användningsfall beskriver man användarens och systemets växelverkan. Användningsfallet berättar i vilket tillstånd systemet är, hur systemet reagerar under användningsfallet, vilka undantag kan uppstå och till vad systemets tillstånd ändras när användningsfallet har utförts.

En användarberättelse (user story), eller ett scenario, påminner om ett användningsfall, men den skrivs i allmänhet på en högre nivå och ur användarens perspektiv: Vad vill användaren göra i tjänsten och varför? Vad är målet för den här uppgiften för användaren? Berättelsen kan, som namnet antyder, vara en mer prosaisk beskrivning, som inte behöver ta ställning till vad som händer tekniskt i tjänsten.

Användningsfall och scenarion används för att specificera tjänstens funktionella krav. Fördelen med metoderna är att det inte borde skapas onödiga funktioner i användargränssnittet, vilka särskilt i webbtjänsten och på dess huvudsidor väsentligt kan belasta användbarheten, när varje tjänsterelaterad intresseaktör har tagit dit sina egna lyft, insättningar och formulär utan att all denna ”bloat” i själva verket hör ihop med de uppgifter på grund av vilka man erbjuder tjänsten till användarna.

Alla användargränssnittfunktioner borde skapas endast av användningsfall och användningsfallen borde i sin tur itereras, när man upptäcker att användargränssnittet fortfarande saknar några av de grundläggande krav som är uppsatta för tjänsten eller att kraven innehåller oförutsedda egenskaper. Användningsfall och användarberättelser passar således särskilt bra för agil utveckling och MVP-publicering (minimum viable product).

Tillgänglighet i användningsfall

Det är i allmänhet enkelt att föra in tillgänglighetsrelaterade krav i användningsfall. De syns bland annat som begränsningar som är anslutna till uppgiften: Användaren kan exempelvis inte granska hela sidovyn på en gång eller ser inte längre än en elementgrupp (på grund av skärmförstoring eller skärmläsare); användaren använder endast tangentbord utan något pekdon (mus, beröringsaktivering); användaren känner inte till allmänna datatekniska konventioner såsom symbolerna för meny, spara eller lokalisering/läge (senioranvändare); språk och läsning kan skapa utmaningar, och så vidare.

Trots detta är det inte alltid självklart att beakta tillgänglighetskrav, i synnerhet om synvinkeln är lite mindre bekant. Särskilt tekniska hjälpmedel, såsom skärmläsare, kan verka exotiska och krångliga att placera i konkreta användningsfall. Å andra sidan kan redan utmaningar på en väldigt grundläggande nivå som äldre användare stöter på i webbtjänsternas användargränssnitt överraska med sin enkelhet. Vad betyder symbolen med tre streck ovanpå varandra? Är den kanske en dekoration? Vågar man röra den med musen? Vad händer om den här länken öppnar en icke-webbsida till ett annat program som jag inte vill ha just nu, när jag vill öppna en webbsida?

Du kan ta hjälp av följande metod: Börja upprättandet av användningsfallen med användarberättelser på en högre nivå, som skrivs ur en sådan användares perspektiv för vilken funktionen föreställs vara både viktig och möjligtvis svår. Användaren kan till och med konsekvent vara en så kallad särskild användare: En person med sensoriska eller kognitiva begränsningar på grund av exempelvis språkkunskap, läskunnighet, funktionsnedsättning eller hög ålder.

Om användningsfallet upprättas så att den aktuella användaren klarar av den, är det sannolikt att även andra användare klarar av uppgiften – till och med ganska lätt. Då är det också enklare att i programvarukraven som härletts från användningsfallet innefatta exempelvis hjälpmedelsrelaterade särskilda observationer och därigenom de WCAG-kriterier som förutsätts i lagen. Dessa kan annars visa sig som en stor och svårkonkretiserad grupp av ganska abstrakta krav.

Exempel

Användarberättelse/scenario

Användare X besöker tjänsten för första gången. Hens modersmål är Y, men hen kan också en del engelska. X behöver använda en skärmläsare med webbläsare och använder den både i smarttelefonen och med datorn. X märker att tjänstens språk troligtvis är finska, som hen knappt förstår. X upptäcker dock att man kan ändra tjänstens språk; vår användare märker samtidigt att engelska är ett av språken som stöds, så hen väljer det. Användargränssnittets språk ändras till engelska och hjälpmedelsprogrammets syntetisator berättar nu om tjänstens innehåll på ett begripligt språk. X börjar undersöka innehållet på tjänstens huvudsida på nytt.

Som användningsfall

Användaren kan byta tjänstens språk till något av följande: finska, svenska eller engelska.

Från användningsfallet till följande preciserade grupp av användningsfall

  1. Användaren upptäcker enkelt att hen kan byta tjänstens språk.
  2. Användaren upptäcker att språket kan bytas till något av följande språk, dock på så sätt att det redan valda språket inte kan ställas in: Finska, svenska, engelska.
  3. Användaren byter språk. Ändringen träder ikraft i hela tjänsten.

Användningsfall #1 ovan som exempel: Användaren upptäcker enkelt att man kan byta tjänstens språk

Användare: Tjänstens kund

Objekt: Alla webbsidor i tjänsten.

Utgångsvillkor:  

– Användaren använde tjänsten för första gången och känner inte till tjänstens sidostruktur.

– Således finns det i minnet valda språket inte i tjänstens cookies-uppgifter

– Användarens modersmål är ett annat språk än tjänstens standardspråk.

Begränsningar: Gäller inte publikationer som inte är webbsidor (till exempel PDF-dokument).

Mål: När användaren öppnar tjänstens webbsida och undersöker eller bläddrar i den som vanligt från början av sidan, upptäcker hen utan något särskilt utredande att det går att byta språk på tjänsten.

När alla tre mer precisa användningsfall har skrivits upp, kan man från dem härleda bland annat följande funktionella krav som specificerar programvarugenomförandet och användargränssnittsplaneringen.

Följande krav från gruppen av användningsfall

  1. Byte av språk ska placeras i bannerdelen av standardbassidan.
    1. Detta garanterar att valet erbjuds på alla tjänstens webbsidor.
  2. Språkvalet ska finnas i början av bannern direkt efter länken (logotypen) för Tillbaka till huvudsidan.
    1. Funktionen är visuellt enkel att upptäcka även med skärmförstoring
    2. Skärmläsaranvändare med annat modersmål än tjänstens språk upptäcker funktionen lättare, om man inte behöver leta efter den bland ett innehåll eller i en navigeringsmeny på ett främmande språk.
  3. Språkvalet får inte baseras på ett element på standardspråket, såsom att behöva förstå en meny eller ett namn.
  4. Det finns två valbara språk, eftersom ett språk alltid är aktivt, kan det inte väljas.
  5. Undvik i mån av möjlighet användning av särskild kontroll eller innehåll som presenteras och döljs dynamiskt, eftersom skräddarsydda, tunga tekniska lösningar är onödiga här och försvårar bytet av språk för hjälpmedelsanvändare.
  6. Språknamnen ska skrivas på respektive språk: suomi, svenska, English.

Tekniska lösningar

  • • Språkvalet genomförs som vanliga HTML-textlänkar, som alltid syns i bannern direkt efter länken (logotypen) för Tillbaka till huvudsidan.
    • Om länktexterna inte kan användas i en responsiv vy, placeras de i en språkmeny, där knappen som öppnar menyn namnges för tekniska hjälpmedel på så sätt att de språk som kan väljas räknas upp (t.ex. svenska, English):
  • Den bläddringsordning, det vill säga DOM-ordning, som språklänkarna är uppradade motsvarar den visuella layouten.
  • Endast länkarna för de språk som användaren kan välja är framme. Således finns det alltid två länkar.
  • Länkarnas ordning från vänster till höger: 1. finska, 2. svenska, 3. engelska.
  • HTML-taggen för varje länk har ett lang-attribut som motsvarar språket.
  • Eftersom det är fråga om en single page app (SPA) och ändring av sidokontexten, ska man, förutom byte av språket i användargränssnittets innehåll, säkerställa följande när språklänken aktiveras:
    • kravet (namn på annat redan registrerat krav) uppfylls (webbläsarinriktningen flyttas till början av sidan, till snabblänken, när hela sidokontexten uppdateras).
    • kravet (namn på annat redan registrerat krav) uppfylls (sidans title-tagg uppdateras när sidokontexten uppdateras).

Redan med en ganska enkel analys som härletts ur användningsfallet kan man här både säkerställa att det tekniska genomförandet redan från början följer WCAG-kriterierna och utveckla tjänstens användbarhet.

Ursprunglig version: Tero Pesonen
Skapad: 4.3.2021

Lär dig mer