Illustrasjonsfoto: Eldre kvinne og mann peker på dataskjermen
 

Diskriminerings- og tilgjengelighetsloven forutsetter at IKT-baserte løsninger rettet mot allmennheten må være universelt utformet (tilgjengelige). Sjekk Lovdata for hele loven og Miljøverndepartementet for en begrepsavklaring.

Universell utforming eller inkluderende design, også kalt design for alle, kan kort forklares som utforming av produkter og tjenester som kan brukes av så mange som mulig i en stor variasjon av brukssituasjoner. Dette gjelder også IKT. Difi er tilsynsmyndigheten i Norge.

Retningslinjer og teknikker for økt tilgjengelighet har bl.a. blitt utviklet av World Wide Web Consortium.


 
 

 

I arbeidet er med å utvikle personas, er prosessen med å utvikle dem vel så viktig som selve sluttresultatet. Personas utvikles ofte for at teamet som er ansvarlig for prosjektet bedre skal kunne identifisere seg med brukernes behov. Derfor beskrives personas med bilde, navn o.l. . Dette gjør de som har er med i utviklingsprosessen umiddelbart vet hva som kreves når noen i teamet sier "Hvordan passer dette for Anne?". I mange prosjekter lages det også modeller i full størrelse slik at de i prosjektet alltid skal ha fokus på behovene til brukerne, beskrevet gjennom flere ulike personas.

Selv om personas ikke er ekte brukere, kan man dokumentere det man faktisk vet om potensielle ekte brukerne dokumenteres i form av personas. Målet er er å lære potensielle brukere å kjenne gjennom treffende personas.

Personas blir på mange måter erketyper og beskriver ofte ytterpunktene av målgruppen. Dette kan være spesielt interessant i forhold til kravspesifikasjon for og testing av IKT-baserte produkter og tjenester. ”Ekstrembrukere” vil avdekke behov som også kommer mange andre brukere til gode. Malen for personas varierer en del. Et fyldig oppsett er:

  1. Navn
  2. Alder
  3. Foto
  4. Jobb
  5. Utdannelse
  6. Sosiale omgivelser
  7. Personlighet
  8. Interesser
  9. Personlig historie
  10. Beskrivelse av bruken av IKT (mål, oppgaver, situasjoner)
  11. Behov knyttet til det aktuelle bruksområdet av IKT
  12. Sitater (frustrasjoner, holdninger, verdier osv.)

Personas utvikles gjerne i en arbeidsgruppe som beskriver et passende antall ulike personas for videre bruk. Prosessen kan være omtrent slik:

  1. Danne arbeidsgruppen. De beste personas skapes iidéutveksling og faglig dialog med andre mennesker.
  2. Bestemme hvor mange personas som det er formålstjenelig og hensiktsmessig å utvikle. Et vanlig antall er 5-7 stykk. Arbeidsgruppen kommer med innspill om hvilke personas som skal utvikles og hvordan man skal samle inn informasjonen som trengs for hver persona.
  3. Samle inn informasjonen. Her er det mulig å benytte en rekke arbredsmetodikker, for eksempel intervjuer, fokusgrupper, spørreundersøkelser, statistiske kilder osv. Virksomhetens egen kundeinformasjon kan være en god kilde.
  4. Utvikle personas. Etter at informasjon er samlet inn, utvikles personas i arbeidsgruppen ved å skape innhold til den valgte malen.
  5. "Renskrive" personas. Det er et stykke fra møtenotater og for eksempel foto av tavlen til profesjonelle personas. Informasjonen må renskrives, det må skaffes foto som ikke er identifiserbar osv. Ferdige personas skal være informative og profesjonelt utformet.

Beskrivelsen av en persona kan være alt fra et vanlig dokument til en plakat eller til og med en "papp-person" i naturlig størrelse. Deltakelse i utformingen av personas øker forståelsen for brukernes ønsker og krav uavhengig av om man er bestiller eller utvikler.

I mange prosjekter kan det være tilstrekkelig å velge ut noen av punktene. En persona har dog et navn og hun/han illustreres med foto for å gjøre en persona mer menneskelig og lett å forholde seg til. Punktene 9-10 vil gi en ofte tilstrekkelig kjerne av informasjon om vedkommendes IKT-relaterte ønsker og krav. Punkt 10 om behov er avgjørende når man utformer personas for å gjøre et produkt eller en tjeneste best mulig for brukere med funksjonsnedsettelser – og dermed for de fleste!

For bestilleren av en IKT-løsning eller -tjeneste vil en slik beskrivelse belyse hva som må forlanges av løsningen eller tjenesten for å tilfredsstille brukernes krav og lovens bestemmelser om tilgjengelighet. Dette må utviklere oversette til tekniske krav som implementeres i forhold til tilgjengelighetsstandarder.

Litt mer om brukerens behov (punkt 10):

Når man utvikler personas og fokuserer på brukere med funksjonsnedsettelser, er det lett å trå til medisinske diagnoser. Det er imidlertid ikke nødvendig for personas eller utforming av tilgjengelige løsninger eller tjenester å beskrive diagnoser. Det kan være greit å ha en person(a) med dysleksi, men det kan være like formålstjenelig å si at en persona har lese- eller skrivevansker. På tilsvarende måte trenger man kanskje ikke bruke begrepet demens om det er nok å si at en person(a) sliter litt med å huske ting. Mange kan identifisere seg med en" rotekopp", selv om det i virkeligheten dreier seg om konsentrasjonsvansker. Utviklingshemning kan være grunnen til at abstrakt tenking eller problemløsing er krevende, men kanskje en hvilken som helst nybegynner har tilsvarende utfordringer. Grønn stær kan være årsaken til synshemning. Det kan likevel være nok å si at for en person(a) er det umulig å lese nettsider med liten tekst eller dårlig kontrast, og at hun eller han bruker leselist. Behovet for hjelpemidler er vitig å få satt ord på fordi dette har konkrete konsekvenser for den tekniske løsningen.

I forbindelse med vårt arbeid i Nettborger-prosjektet har vi innsett at det ofte mangler vesentlig informasjon for at personas skal være nyttige gjennom hele utviklingsprosessen. For eksempel, hva betyr "rotekopp" eller en person(a) med synsheming for dem som skal utvikle og implementere et nettsted?

Vi har derfor utvidet personabeskrivelsen med informasjon som skal hjelpe dem som utvikler og implementerer løsninger. Med en utvidet personasbeskrivelse prøver vi å svare på spørsmålet "og hva så?" som utviklere gjerne stiller når de ser en persona som er beskrevet med en funksjonsnedsettelse.

Utvidet persona

I Nettborger-prosjektet har vi utvidet personabeskrivelsen med informasjon som vil kunne hjelpe utviklerne og dem som skal implementere løsningen. Med tanke på universell utforming og de nye kravene som stilles, vil en utvidet personabeskrivelse kunne sikre en bedre kravspesifikasjon.

Vi har utvidet personabeskrivelsen med følgende punkter:

  1. Beskrivelse av brukerproblemet.
  2. Momenter til kravspesifikasjon.
  3. Tips til utvikler.
  4. Tips til implementering.

Disse punktene gjentas for hvert problem.

Eksempler

I prosjektet har vi laget noen få enksempler som viser hvordan personabeskrivelsen kan utvides med informasjon som hjelper dem som skal utvikler og implementerer løsningen. I disse eksemplene har vi tonet ned de 10 vanlige punktene som beskrives i en persona, nettopp for å fokusere på de utvidede elementene.

For enkle eksempler se:

Side oppdatert 19.3.2012


   
 
      Tekst: © www.karde.no – Foto: © www.clipart.com