Inkluderas kundgrupperna i utvecklingsprocessen?
Invånare
Behandlare
Administratör
Landsting/Region/Kommun
Exempel på hur man gör detta: Länka till nästa kapitel eller skriv kort/motivera om tex tjänsteresor, intervjuer och medverkan.
– Användarcentrerademetoder
| Stil |
|---|
| import | https://sob.udo.se/css/confluence.css |
|---|
|
Image Removed
"Varför ska vi använda det här då det är krångligare?"
| Tips |
|---|
|
Det är inte enbart invånaren som använder det färdiga programmet. Även behandlarens upplevelse måste finnas med i designprocessen |
All välmening, men...
..det har nämnts tidigare i denna guide, men det behöver nämnas om och om igen - designprocessen tar tid - och är det något som tar väldigt mycket tid så är det att få med användarnas upplevelse i skapandet av en ny tjänst. Men även om det tar mycket tid så är det essentiellt att designteamet uppmärksammar de behov som användarna har.
Kärnan av ditt och ditt teams arbete finns hos användarna och deras tjänsten du utvecklar. Den har olika användare - som använder den på olika sätt - och du behöver skaffa dig kunskap om dessa. I designprocessen behöver du även ta hänsyn till behandlarens upplevelse. |
Vilka är dina
"kunder"användare?
Vilka är det dom användarna av tjänsten ni utvecklar? (de som drar nytta av och använder dina tjänster?) Olika uppdrag, projekt och moment kan ha olika kunder användare med vitt spridda behov och upplevelser, vilket gör det viktigt att identifiera varje unik kundgrupp användargrupp innan arbetet med ett nytt moment börjar.
En risk är Gör inte misstaget att enbart se till en kundgrupps användargrupps behov och helt åsidosätta åsidosätt en annan grupps användargrupps behov. Det som riskerar hända på grund av ett sådant åsidosättande är att tjänsten du och ditt team bistår med inte kommer användas.
| Sektion |
|---|
| Kolumn |
|---|
|
| Info |
|---|
| icon | false |
|---|
| title | Kundgrupp Målgrupp 1 Patientenpatienten/invånaren |
|---|
| Slutanvändaren som vill ha ett faktiskt resultat av användandet av att använda tjänsten som erbjuds. För att kunna få ett resultat så måste denna användare nyttja tjänsten och tycka att den är användbar. Denna kundgrupp användargrupp är den som innehar har kunskap om sin vardag och sina besvär, dem som tjänsten skall ska hjälpa motverka eller ge stöd mot. |
|
| Kolumn |
|---|
|
| Info |
|---|
| icon | false |
|---|
| title | Kundgrupp Målgrupp 2 Behandlarenbehandlaren |
|---|
| Den andra kundgruppen användargruppen är behandlaren. Många gånger är den ursprunglige beställaren av tjänsten.Denna kundgrupp är den som innehar behandlarna. Det är inte ovanligt att det är behandlare som efterfrågar eller beställer tjänsten. Denna användargrupp har kunskapen och metoderna för behandling av en sjukdom eller ett besvär. Det finns en stor risk med att enbart lyssna på beställaren av tjänsten, det gör det är lätt hänt att enbart fokusera på vad behandlaren vill leverera till patienten - och inte vad patienten faktiskt vill ha levererat av behandlaren. Ställ krav på att involvera båda användargrupperna och designa för deras faktiska behov. |
|
|
Kunden har alltid rätt?
| Sektion |
|---|
|
Exempel:
Nedan är ett exempel på två kunder i ett projekt för ett moment för kroniker. Exemplet visar på vikten att ha med kunderna genom hela designprocessen och inte enbart i början där teamet utforskar kundernas, användarnas, behov.
| Sektion |
|---|
| Kolumn |
|---|
|
| Info |
|---|
| icon | false |
|---|
| title | Kund 1 Patienten |
|---|
|
- Diagnostiserad med en kronisk sjukdom.
- Är ofta inbokad på kontroller till vårdcentralen.
- Skulle vilja på ett enkelt sätt kunna rapportera sina framgångar och besvär istället för att behöva svara på de frågorna vid varje besök - då det kan vara svårt att komma ihåg när man väl är på besöket.
- Vill även kunna läsa på om sin sjukdom och kunna få svar på om hen har några frågor.
|
| Kolumn |
|---|
|
| Info |
|---|
| icon | false |
|---|
| title | Kund 2 Behandlaren |
|---|
|
- Behandlaren vill på ett enkelt sätt kunna övervaka patientens arbete.
- För att veta hur det går för patienten vill behandlaren att patienten ska kunna skatta sina besvär mellan besöken för att lättare kunna värdera hur effektiv behandlingen är.
|
| Observera |
|---|
| icon | false |
|---|
| title | Momentet byggs |
|---|
|
Ett moment skapas efter att ha lyssnat på vad kunderna vill att momentet ska uppfylla. - Möjlighet att rapportera in besvär efter ett formulär som behandlaren har tillhandahållit, som behandlaren sedan själv kan räkna ut ett resultat ifrån som visar på om behandlingen går bra eller dåligt.
- Information läggs in i en sida med löpande text så att patienten själv kan läsa på om all tillgänglig information från behandlaren.
|
Efter att momentet byggts och publicerats visar det sig att det inte används av behandlarna.
| Sektion |
|---|
| Kolumn |
|---|
|
| Varning |
|---|
| icon | false |
|---|
| title | Kund 1 Patienten |
|---|
|
- Vill på ett enkelt sätt kunna rapportera in och inte för mycket frågor på en och samma gång.
- Tycker inte om för mycket text på ett och samma ställe.
- Vill ha skräddarsydd information om sina specifika mediciner och behandlingar
|
| Kolumn |
|---|
|
| Varning |
|---|
| icon | false |
|---|
| title | Kund 2 Behandlaren |
|---|
|
- Vill inte dubbelarbeta eller behöva titta på flera sidor för att få reda på hur det går för patienten. Det blir för många klick och rörigt att arbeta.
- Vill inte behöva göra för många inställningar varje gång ett nytt moment startas för en patient.
|
Image Removed
| Sektion |
|---|
| Kolumn |
|---|
|
Behov »Den ena användargruppens behov kommer inte överensstämma med den andras behov. De kommer att använda tjänsten på två olika sätt, och därför ser deras behov olika ut. Här kommer den stora utmaningen som designer och utvecklingsteam; att sammanföra de två gruppernas behov så att båda användarna av ett färdigt moment blir nöjda.
I kapitlet "Förstå behov" kommer du läsa om olika metoder för att fånga in användarnas behov och få hjälp att tratta ned dessa till så kallade tjänsteresor. En tjänsteresa beskriver en eller flera användares resa genom en tjänst, vilka interaktionspunkter som finns - då användaren gör något med tjänsten - och vilka steg på "baksidan" som behöver vara involverade.
Tjänsteresan gör det möjligt att få en "före" och "efterbild" av tjänsten som du utvecklar: Hur det var innan ett moment togs fram och vad momentet ska hjälpa med under denna resa. Det är med hjälp av användaren som tjänsteresan tar form, och detta kan göras på olika sätt:
- intervjuer
- observationer
- workshops
- enkäter
- m.m.
Tänk på användaren
Det är användaren som är kärnan i designerns arbete. Först och främst måste behovet och funktionen uppfyllas innan estetisk utformning spelar roll, annars riskerar momentet att inte användas på grund av att någon av användargrupperna inte uppskattar det nya arbetssättet - kanske upplevs det för krångligt, omständligt eller för osäkert - allt detta behöver designern förhålla sig till.
Det spelar ingen roll om tapeten är vacker om det visar sig att taket är för lågt.
Image Added
| Stil |
|---|
| import | https://uxa.se/dgcss |
|---|
|
|