Posts Tagged ‘teknologi’

Brukertesting – praktisk og upraktisk

fredag, september 16th, 2011

For ordens skyld

Jon Gunnar Wold, en av forfatterne av boken Praktisk brukertesting, etterlyste bokanmeldere via Twitter. Jeg er interessert i temaet og meldte meg frivillig til å teste boken. Dette er dermed en sponset bloggpost, men jeg har ikke mottatt annen kompensasjon enn selve boken for å skrive om den.

Om meg

Jeg har tidvis skrevet om jobb her på bloggen, men en god del av leserne har antakelig ikke helt klart for seg hva jeg jobber med. Jeg er testleder og teknisk tester i Vizrt, som (blant annet) utvikler kontrollsystemer for tv-grafikk. Vi lager altså ikke selve grafikken, men verktøyene som brukes for å lage den og få den spilt ut på luften. Jeg bruker mye av tiden min på å planlegge test og grave fram nødvendig teknisk informasjon om kommende systemer og funksjonalitet, men får også leke med morsomme duppeditter. Teamet mitt fokuserer mest på funksjonell testing, men har lav terskel for å rapportere om ting som går på ren brukervennlighet. I tillegg har noen utviklere på avdelingen eksperimentert med brukertesting og oppnådd gode resultater med svært enkle midler.

Om boken

Til poenget. Boken heter altså “Praktisk brukertesting”, og den er akkurat det den gir seg ut for å være. Jeg kom meg greit gjennom hele boken på en halv arbeidsdag. For de som har enda mindre tid å avse åpner boken med en presentasjon av ulike roller som kan tenkes å ha nytte av boken, med tips om hvilke kapitler de bør se spesielt på. Det er et gjennomgående fokus på nytteverdi i arbeidslivet, og en god balanse mellom det ideelle og det oppnåelige.

Før jeg åpnet boken hadde jeg en konkret liste av spørsmål jeg håpet å finne forslag til løsninger på:

  1. Hva skjer med resultatene av brukertest når deadline nærmer seg og kunden skal på luften med den nye funksjonaliteten på tirsdag?
  2. Hvordan håndterer man brukertesting med en målgruppe som er vanskelig å definere og ikke minst vanskelig tilgjengelig?
  3. Hvordan kan man praktisk gjennomføre brukertest av svært komplekse systemer?

Min personlige dom over boken blir dermed avhengig av i hvilken grad jeg fikk nyttige svar på disse spørsmålene. Det skal jeg komme tilbake til.

Først litt mer generelt om boken. Dette er ikke den første teksten jeg leser om brukertesting, selv om jeg på ingen måte er ekspert på området. Det de fleste tekster om brukertesting har til felles er at de er fokusert på metode. I så måte ble jeg svært positivt overrasket over Praktisk brukertesting.

Det er riktignok et kapittel om metode, og det kapittelet sier bare en brøkdel av det det kunne ha sagt. Mesteparten av boken dreier seg om andre ting: Ren praktisk gjennomføring av brukertester, ned til detaljnivå med forslag til sjekklister. Hvordan logge og analysere resultatene, og ikke minst – hvordan få gjennomslag for å gjøre endringer basert på resultatene. En fornuftig prioritering, spør du meg. Metodikk finnes det hauger av annen tilgjengelig litteratur på, og den store bøygen er ikke egentlig å finne ut av metodene, men å få noen konkrete resultater av testingen, i form av bedre produkter.

Boken er tydelig skrevet av folk med mye praktisk erfaring, og bruker flittig sitater fra og referanser til andre erfarne kilder. Den er konkret og behagelig kortfattet, men samtidig fleksibel, og fokuserer gjennomgående på praksis framfor teori – learning by doing. Det dukker likevel opp en påminnelse mot slutten om at brukertesting ikke erstatter interaksjonsdesignere.

En ekstra styrke er at boken er skrevet på norsk, med det norske arbeidsmarkedet som utgangspunkt. Du skal ikke forbi mange landegrenser før du finner store forskjeller i bedriftskultur og brukerkultur. Rådene som gis er fornuftige i forhold til norsk kultur, og eksemplene er hovedsakelig fra norske bedrifter. Dermed er de lett omsettelige i praksis, for ferske brukertestere som tester systemer utviklet i Norge for norske brukere.

Dette er som sagt en styrke, men samtidig en svakhet. Jeg savner et avsnitt eller to om det internasjonale aspektet, både med tanke på brukermassen (i hvilken grad kan man generalisere brukertest gjort i ett land til brukere i et annet?) og med tanke på forankring av brukertesting innad i en internasjonal organisasjon med utviklere i mange land. Kanskje i neste utgave?

Så tilbake til utgangspunktet. Spørsmålene mine var ikke enkle, og de har ikke enkle svar. Boken behandler temaet om tidsfrister på realistisk vis. Noen ganger er det rett og slett ikke tid – prøv igjen neste gang, og planlegg bedre fra start av. Det forutsetter riktignok at den som er interessert i å kjøre brukertesting er med ganske tidlig i prosjektet, og ikke minst at prosjektet er veldefinert. Som så mange andre bøker om test og prosess bærer Praktisk brukertesting preg av konsulentbransje og prosjektbasert utvikling, der man har en plan, en kravspesifikasjon, en prosjektleder og en gruppe mennesker som jobber på et bestemt prosjekt i en bestemt periode. I min bedrift er ikke dette alltid (eller ofte) tilfelle. Spørsmål to og tre blir ikke egentlig besvart.

Vil jeg nå hoppe til verket og sette i gang brukertester på jobben?

Tja.

Produktene jeg jobber med har en del aspekter som gjør at brukertesting ikke er helt rett fram. Som nevnt innledningsvis:

  • Målgruppen er vanskelig tilgjengelig. Brukerne er ulike yrkesgrupper hos TV-stasjoner rundt omkring i verden. For de spesifikke produktene jeg har testansvar for er det mest relevant å kjøre brukertest på journalister og operatører – det vil si de som legger informasjonen inn i systemet, og de som sørger for at den blir spilt ut på luften til rett tid. Det er ikke praktisk og ressursmessig mulig å få brukerne til å komme til oss – vi må komme til dem. Selv da kan det være vanskelig å få tilgang til testpersonene vi trenger.
  • Testmiljøet er komplekst og kostbart. En ren oppgavebasert test vil ikke være god nok for oss, ettersom en viktig faktor er hvordan systemet fungerer under tidspress med mange beskjeder som flyr fram og tilbake og ting som må endres på sekunders varsel. TV-seere ville bli overrasket over hvor kaotisk situasjonen i kontrollrommet kan framstå under sending, selv om de som sitter der har full kontroll. Noen sekunders forsinkelse som ingen ville lagt merke til i en veldefinert test i rolig setting vil være et stort problem under sending. Å sette opp en egen, realistisk lab er for dyrt og uansett nesten umulig (se neste punkt), og å få tilgang til tv-selskapenes egne kontrollrom er heller ikke rett fram.
  • Målgruppen er vanskelig å definere. Systemene våre integrerer tett med øvrig programvare og hardware hos kunden, og det er milevise forskjeller i oppsett og konfigurasjon fra kunde til kunde. Det er tildels store forskjeller i både brukergrensesnittet og arbeidsflyten. Dermed er vi på gyngende grunn når vi skal prøve å generalisere testresultater og ikke minst prioritere hva som er viktigst å endre. Endringer gjort for å tilpasse produktet til arbeidsflyten til en kunde fører ikke sjelden til at en annen kunde roper opp i protest fordi det kompliserer arbeidsflyten hos dem. Det betyr ikke at brukertest er umulig, men det betyr at vi trenger et mye bredere datagrunnlag enn de 3-5 testpersonene boken legger opp til – og fra kunder over hele verden.

At brukertesting kunne være nyttig for oss er det liten tvil om. Vi, som alle andre, har utfordringer på brukergrensesnittfronten, og de spede forsøkene som har vært gjort har vist at det er mye å hente. Likevel nøler jeg med å sette i gang brukertest av annet enn enkelte, begrensede prosjekter og funksjoner. For de fleste produktene tror jeg kost/nytte vil være større med andre tiltak, i alle fall der vi er nå. For eksempel:

  • Det er vedkjent at verken utviklerne og testerne har tilgang på nok domenekunnskap. Det kan vi gjøre noe med, på ulike måter. Økt domenekunnskap gir ikke automatisk gode brukergrensesnitt, men det øker sannsynligheten for at man utvikler det kunden egentlig trenger for å utføre arbeidsoppgavene sine.
  • Fattigmanns brukertest: Ren observasjon av brukere i deres eget miljø, mens de utfører sitt vanlige arbeid. Denne metoden har vi i testavdelingen allerede tatt i bruk, men arbeidet kan og bør både systematiseres mer og følges bedre opp – og deretter utvides. Selv om dette ikke kan regnes som en brukertest, har Praktisk brukertesting mange nyttige råd som kan brukes også på denne metoden, spesielt med tanke på analyse og bruk av resultatene

Konklusjon

Hvis du snuser på brukertesting og trenger en dytt for å komme i gang, er dette boken for deg. Hvis du allerede har litt erfaring og kunne tenke deg gode tips for å forbedre måten du jobber på, er det også boken for deg.

Verdi for pengene er ikke så relevant som mål, en bedrift som har råd til å kjøre brukertester har uansett råd til de få kronene denne boken koster. Viktigere er at den er verd arbeidstiden som går med til å lese den. Den er både kort nok, tydelig nok og nyttig nok.

Ikke ta deg nær av at jeg er vrang – jeg mener at brukertesting er en verdifull arbeidsmetode og bør brukes overalt der det er praktisk og ressursmessig gjennomførbart. For de aller fleste IT-prosjekter er det det.

Kvinner og IT – er det noe problem, da?

mandag, mars 7th, 2011

Som kvinne i IT har jeg blitt bedt om å snakke til en gruppe IT-studenter om det å være kvinne i IT. Foreløpig befinner foredraget seg kun på drodlestadiet, men jeg håper bloggeverden vil drodle litt sammen med meg, i anledning dagen.

I 2004 skrev jeg om kvinner og Linux, i en bloggpost som er overraskende aktuell i dagens mobbedebatt. Foredraget for studentene får nok en litt annen vinkling, i og med at arbeidshverdagen og ikke mobbing er tema, men jeg regner med å svippe innom emner som selvtillit. Jeg vil også si noe om typiske feller man bør prøve å unngå, både i egne holdninger og tanker og overfor hersketeknikker man kan møte som ung, usikker og nyutdannet. Jeg kommer neppe til å gå mye inn på den organisatoriske og strukturelle biten, det vil min medforedragsholder med denslags kompetanse dekke. Jeg er er altså først og fremst tilstede som Exhibit A: En vaskeekte kvinnelig IT-arbeidstaker.

Selv har jeg egentlig få opplevelser av kjønn som noen betydelig faktor i arbeidslivet, men jeg vet jo at det eksisterer andre historier enn min, og jeg observerer ikke minst at det er få av oss. Derfor vil jeg veldig gjerne høre om andres erfaringer.

Jeg slenger ut noen spørsmål, og lover å komme med en oppsummering etterhvert. Du trenger verken være kvinne eller IT-menneske for å komme med innspill, og innspill i form av nye spørsmål er også høyst velkomne.

  1. Hvorfor er det så få kvinner i rent tekniske IT-stillinger? Utviklere, systemadministratorer, nettverksdriftere?
  2. Om du er en kvinnelig geek: Hvordan opplever du arbeidshverdagen din? Hva slags tanker har du om kjønnsperspektivet? Har du opplevd å bli diskriminert på grunn av kjønn? Har du opplevd å bli fremhevet på grunn av kjønn?
  3. Om du er en mannlig geek: Har du kvinnelige kolleger? Hva slags tanker har du om kjønnsforskjeller i arbeidslivet?
  4. Hvis du skulle gitt et godt råd til kvinnelige (og mannlige?) IT-studenter som skal ut i arbeidslivet, hva ville det være?
  5. Noen andre tanker om temaet? Noen gode historier?

Rekk opp og begynn på nytt!

torsdag, februar 10th, 2011

Jeg har en klok, strikkende venninne som alltid sier at hvis man vil strikke, må man være villig til å rekke opp. Noen små unøyaktigheter kan man alltids klare å leve med eller trikse til slik at de ikke synes i det ferdige produktet, men når du sitter der med en feil som er for stor til å skjule har du bare tre valg:

  1. Bli sur og legge det halvferdige strikketøyet i en skuff (min favorittløsning!).
  2. Strikke ferdig likevel, men ende opp med å ikke bruke det ferdige plagget særlig mye fordi a) er stygt, b) ikke passer, eller c) begge deler.
  3. Rekke opp, rette feilen, begynne på nytt. Gjerne flere ganger, til resultatet blir bra.

Hvor mange av dere kan si, med hånden på hjertet, at dere som regel velger den tredje veien? Til tross for at den helt åpenbart er den mest rasjonelle?

Nemlig.

Vel, den siste måneden har jeg jobbet med et utviklingsprosjekt der utviklerne på en forbilledlig og ikke minst inspirerende måte har gjort nettopp det. Til tross for at programmet fungerte helt greit, kjørte de brukertest etter brukertest, forkastet, endret og tenkte nytt, uten å henge seg opp i hvor mye tid de allerede hadde brukt på forrige løsning. Brukergrensesnittet ble noe helt annet enn utgangspunktet, og mye, mye bedre.

Neste gang jeg strikker meg inn i et hjørne skal jeg prøve å bite det i meg og rekke opp.

Te med stor T

tirsdag, mars 23rd, 2010

Det er bare plass til en begrenset mengde ting i livet mitt på en gang. I det siste har det ikke vært mye fart på bloggen, men desto mer fart bak fasadene på en helt ny nettside og nettbutikk – Te med stor T!

Det er mer arbeid enn man skulle tro å starte nettbutikk. Bare det å starte AS er en haug med papirarbeid. Så skal man ha bankpapirer i orden, og få tak i kredittkort, og få det verifisert hos en betalingsportal. Dessuten må man finne et netthandelsystem som fungerer, og tilpasse det både med innstillinger, innhold og design, koble det til betalingsløsning, sette opp prosedyrer for frakt. Dessuten må man jo ha varer å selge, som både skal møysommelig velges ut, bestilles, pakkes, fotograferes, beskrives og telles opp. Og beregnes pris, avanse og moms på.

Hvorfor gjør vi alt dette? Det er neppe noe vi blir rik av med det første. Men vi er veldig glade i god te, og synes at mange flere burde bli like glade i god te. Og så er vi litt spent på å se om dette fungerer i praksis. Målet er å tjene nok penger til å betale revisorregningen på slutten av året!

“Ikke et sikkerhetsproblem” – Ikke bra nok

tirsdag, september 1st, 2009

Politiets nye nettsider får hard medfart i dag. Dagbladet formidler mange gode poenger fra flere eksperter, og VG påpeker at sidene er et eneste stort sikkerhetshull. Man skulle tro at sikkerhet var et viktig kriterium for utvikling av nettsidene til en av de samfunnsinstitusjonene som er aller mest avhengig av etterrettelighet og folkets tillit. I stedet ser det ut til at politiet og deres konsulenter mangler enhver forståelse for grunnleggende IT-sikkerhet. De har slengt hele nettstedet på https – antakelig i den tro at det øker sikkerheten – men ligger (eller lå, det ser ut til at noen har vært ute og plugget hull nå) fullstendig åpne for kryss-side-skripting.

Selv når feilene blir påpekt forstår de ikke alvoret i saken. Prosjektleder Tore Engen uttaler til VG at det “ikke er et sikkerhetsproblem” at Politiets nettadresse kan benyttes til videresending til andre nettsider. Dette til tross for at dette åpner for at hvem som helst kan lure brukere til å sende informasjon ment for politiet til en helt annen mottaker – for eksempel anmeldelser og sensitive henvendelser. I tillegg kan hvem som helst legge ut informasjon som ser ut til å være gitt av politiet, noe Nettavisens skjermbilde fra politi.no demonstrerer på humoristisk vis.

At disse feilene finnes er i utgangspunktet ille nok. Men at prosjektets leder står og sier at disse gapende sikkerhetshullene er bagatellmessige og antyder at de vil bli fikset mest for å slippe at folk maser om det, er urovekkende.

Når det gjelder prisen, som mange har harselert over, er han like avfeiende. “De fleste tenker på nettside for en liten bedrift på ti personer. Der kan man slippe unna med 500 000 kroner i utviklingskostnader.” sier han til Dagbladet. Dersom Engen kjente fagområdet så godt som han burde ville han vite at ingen bedrift med ti personer bruker en halv million på nettsidene sine. De fleste bedrifter på denne størrelsen ligger nærmere fem tusen kroner, bedrifter med sterkt informeringsbehov og svært interaktive nettsteder kommer kanskje opp i femti tusen, altså en tiendedel av den “fillesummen” som nevnes.

De fleste med kompetanse på området forstår at et nettsted med slike dimensjoner og (forhåpentligvis) utbyggingsmuligheter som Politiets er ikke kan utvikles på en måned av en fjortis som sveiver noe sammen av WordPress og noen tilfeldige plugins, og heller ikke kan kjøre på en server satt sammen av brukte deler plassert i en kjeller et sted. Men derfra til 25,6 millioner er det et langt steg. Med bedre prosjektplanlegging burde disse kostnadene kunne vært redusert en hel del.

Når det er sagt, fortjener de litt ros også. Noe av kritikken har gått på at sidene framstår som om de var laget for ti år siden. Jeg mener det enkle designet er et godt utgangspunkt. Det er ikke nødvendig å bruke mengder av bilder, videoer, javascriptmenyer og fancy web2.0-magi for å lage funksjonelle, informative nettsider (selv om man kan lure på hva de brukte all tiden og pengene på når de ikke brukte den til å lage dilldall). Sidene fungerer godt for svaksynte og er fullt funksjonelle selv om man skrur av både bilder og javascript.  Man får håpe (med de summene som er brukt på hardware og software, og det litt pussige grepet med å legge css, bilder og js på hvert sitt eget domene som en form for last- eller forespørselbalansering) at tregheten til sidene er et forbigående problem som vil bli fikset med noen enkle justeringer av flaskehalser i løpet av de neste dagene.

Når det gjelder informasjonsformidling, er ikke utformingen like heldig. De mange pressemeldingene på forsiden kunne med hell vært lagt på en egen underside, eventuelt med visning av den nyeste pressemeldingen i en boks på forsiden. Forsiden burde vært dedikert til formidling av svar på de spørsmålene folk har når de går inn på sidene. Både side- og toppmenyen ser ut til å være greit sortert, sammen med de fire temaboksene, men alle pressemeldingene tar hovedfokus og forkludrer informasjonen i menyene. Her burde de lært av andre offentlige etater som NAV og Lånekassen, nettsteder med liknende formål og bruksmønster som Politiets.

Alt i alt? Noen lyspunkter, men dette er rett og slett ikke bra nok, uansett pris. Andre offentlige etaters nettsider løper i sirkler rundt denne satsningen. Jeg forstår at det er lett å i første omgang gå i forsvarsposisjon og avfeie kritikk når man er stolt over prosjektet man har lansert. Når støvet har lagt seg håper jeg prosjektleder og hans medarbeidere tar til seg det som kommer fram i media i dag med et åpent sinn, og lar seg påvirke i det videre arbeidet med nettsidene. Det meste av kritikken er svært konstruktiv, og bunner i et ønske om bedre nettsider.

GUI for /etc/fstab

fredag, juli 10th, 2009

Hvis tittelen ikke sier deg noe, så kan du sikkert hoppe over resten av denne bloggposten.

Nyere Linux-versjoner har blitt ganske flinke til å la brukere slippe å redigere /etc/fstab manuelt. Det er en god ting. Men av og til må jeg fremdeles inn der og kløne, og det er akkurat så sjelden at jeg aldri husker nøyaktig hvilke opsjoner som er av og på som standard og hva jeg må huske på å spesifisere manuelt. Hver gang jeg gjør det irriterer jeg meg over at jeg ikke bare kan fyre opp et lite GUI, skrive inn hva jeg vil montere hvor og trykke på noen knapper for å fikse resten av magien.

I dag har det vært sprint-fredag på jobben (også kjent som “research day” eller “lær deg noe du ikke kan-dag”), så jeg bestemte meg for å leke litt med JavaScript. Resultatet ble en bitteliten webapplikasjon som setter sammen en linje du kan lime inn i /etc/fstab:  The fstab line generator.

Teknisk aspergers

onsdag, desember 10th, 2008

I jobben min har jeg av og til kommet i kontakt med mennesker med aspergers syndrom. Dette er en mild form for autisme som litt forenklet sagt gir seg utslag i at personen har problemer med å forstå sosiale koder. De fleste av dem fungerer helt greit i vanlige sosiale situasjoner fordi de har lært hvordan det er forventet at man reagerer i ulike situasjoner. “Hvis Petter smiler og sier hei, er det meningen at jeg sier hei tilbake. Dersom det er mandag kan jeg også spørre om det har vært en fin helg.”

Problemet er ikke språklig – personene det gjelder kan godt være over gjennomsnittlig flinke med språket. Det er heller ikke et spørsmål om intelligens. Det er rett og slett mangel på en form for innsikt som ikke kan læres – innsikten i hvordan menneskelig samhandling foregår under overflaten. Derfor blir personer med aspergers syndrom gjerne i villrede når de møter nye situasjoner, spesielt slike som er ladde med komplekse følelser, som sjalusi, forelskelse eller fornærmelse. De er sjelden flinke til konflikthåndtering, på grunn av manglende forståelse av de underliggende motivene og følelsene til personene som er involvert i konflikten.

På samme måte møter jeg med jevne mellomrom personer med noe jeg vil kalle teknisk aspergers. Det er ikke en diagnose, men burde kanskje vært det. Det er nemlig sterke paralleller til vanlig aspergers, bortsett fra at det i stedet for sosial innsikt rammer den tekniske innsikten.

Mennesker med aspergers styrer ofte unna jobber som krever høy grad av sosial interaksjon. Slik havner en del av dem i IT-industrien. Det er nok også tilfelle at de fleste som lider av teknisk aspergers styrer unna jobber som krever høy grad av teknisk interaksjon, men det gjelder ikke alle.

En person med teknisk aspergers kan ofte være vanskelig å skille fra andre, spesielt på lavere eller svært yrkesrettede utdanningsnivåer. Selv i det praktiske arbeidslivet kan man overse denne egenskapen i en kollega i lengre tid. Teknisk aspergers betyr nemlig ikke at personen ikke kan noe om teknikk. Det kan være snakk om svært kunnskapsrike personer, med solid mestring av programmeringsspråk, teknikker og metoder.

Men på ett eller annet tidspunkt dukker det gjerne opp en situasjon som ligger litt utenfor allfarvei, noe som ikke kan løses eller uttrykkes ved hjelp av de teknikkene personen allerede kan. Her er det du ser forskjell på den som har lært seg hva som skjer og kan gjengi det, og den som faktisk forstår hva som foregår under overflaten. Etter langvarig observasjon av en rekke slike personer er mitt inntrykk at dette ikke har noe å gjøre med manglende intelligens eller lav utdanning. Det er, i likhet med sosiale koder for personer med aspergers syndrom, en liten bit av systemet som rett og slett ikke er der.

Man kan sannsynligvis lage intervjuer og ansettelsestester som fanger opp slike jobbsøkere. Men det er ikke nødvendigvis gitt at man alltid bør luke dem ut. Jeg har arbeidet med personer med aspergers syndrom som gjør en svært god jobb når man tar hensyn til deres behov i forhold til kommunikasjon, og jeg har arbeidet med personer med teknisk aspergers som også gjør en svært god jobb og er en nyttig ressurs i et team. De kan ofte være mer systematiske og strukturerte i sin tilnærming til arbeidet enn det som til tider er tilfelle for mennesker med en mer intuitiv tilnærming til teknologi.