Gå till slutet av bannern
Gå till början av bannern

**Användargrupper

Hoppa till slutet på meta-data
Gå till början av metadata

Du visar en gammal version av den här sidan. Visa nuvarande version.

Jämför med nuvarande Visa sidhistorik

« Föregående Version 46 Nästa »

"Varför ska vi använda det här då det är krångligare?"


TL;DR

Det är inte enbart invånaren som använder det färdiga programmet. I designprocessen behöver du även ta hänsyn till behandlarens upplevelse.

Tänk på att tjänsten används av flera olika användare - på olika sätt.

Vilka är dina användare?

Vilka är användarna av tjänsten ni utvecklar? (det som drar nytta av och använder dina tjänster?) Olika uppdrag, projekt och moment kan ha olika kunder med vitt spridda behov och upplevelser, vilket gör det viktigt att identifiera varje unik användargrupp innan arbetet med ett nytt moment börjar.

En risk är att enbart se en användar-/"kundgrupps" behov och helt åsidosätta en annan grupps behov. En konsekvens av det kan bli att programmet ni utvecklar kommer användas i liten omfattning eller inte alls. (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.)

Kundgrupp 1 Patienten

Slutanvändaren som vill ha ett resultat av användandet av 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 är den som innehar kunskap om sin vardag och sina besvär, dem som tjänsten skall hjälpa motverka eller ge stöd mot.

Kundgrupp 2 Behandlaren

Den andra kundgruppen är behandlaren. Många gånger är den ursprunglige beställaren av tjänsten.

Denna kundgrupp är den som innehar kunskapen och metoderna för behandling av en sjukdom eller besvär.

Det finns en stor risk med att enbart lyssna på beställaren av tjänsten, det gör det lätt att enbart fokusera på vad behandlaren vill leverera till patienten - och inte vad patienten faktiskt vill ha levererat av behandlaren.

Kunden har alltid rätt?

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 team; Att gifta 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 vacker om det visar sig att taket är för lågt.



  • Inga etiketter