Nettavisene flommer over av trender og spådommer for året som kommer. De skriver om økonomi, miljø, kjendiser, interiør og mote.  Noen slår til og andre bommer. Her presenteres mine spådommer for fagområdet brukskvalitet i 2010.

1.    Generelt bedre brukskvalitet
Folk flest finner seg ikke i hva som helst lenger. De har sett brukervennlige websider og programvare før og skjønner at ikke at som har med data å gjøre må være komplett ubegripelig. De vil i beste fall protestere og i verste fall bare forsvinne lydløst over til en konkurrent hvis noe ikke er bra nok. Dette gjør at seriøse aktører ikke våger å la være å gjøre noe med brukskvaliteten på websidene eller programvaren sin.

2.    Større etterspørsel etter UX-kompetanse
På slutten av 2009 kom det flere stillingsannonser innen UX/ usability enn på lenge. Både Steria, Tarantell og Netlife er/ var på jakt etter nye folk som kan faget. Det er til og med mulig å få seg jobb innen brukervennlighet i Kristiansand. Dette er et tydelig tegn på at etterspørselen er på vei opp og at flere krefter trengs i 2010.

Oppdatering 22.02.2010
Octaga, Colour Line ,Finn.no med flere har søkt etter brukervennlighetskompetanse i årets to første måneder.

3.    Økt modenhet for usability
Usabilityguruen Jacob Nielsen skrev for flere år siden to artikler om organisasjoners modenhet når det gjelder usability. Vi ser tydelig at mange organisasjoner og bedrifter er i ferd med å forstå hva som skal til. Flere har nå egne interaksjonsdesignere eller HCI-folk som baner vei. Modenheten vil derfor fortsette å øke.

4.    Krav til helhetlig brukeropplevelse gir større grad av tverrfaglighet
I fagmiljøet har blikket i lengre tid vært rettet mot helhetlige brukeropplevelser som går langt ut over det å bestemme hvor knappen skal stå. Men helhetlige brukeropplevelser gjør at vi fort dumper borti domene til andre kunnskapsrike fagspesialister som også må involveres når det gjelder å utforme løsninger og gi svar på kompliserte problemstillinger. Det kan være IT-sikkerhetsspesialister, ITIL-folk eller Business Intelligence rådgivere. Sammen skal vi i året som kommer finne enda smartere og mer helhetlige løsninger.

5.    Design tar høyde for samfunnsansvar
Design vi leverer i 2010 vil i større grad gjenspeile det samfunnsansvaret vi har. Her snakker vi om krav, men også høyere bevissthet rundt temaer som universell utforming, grønn it og bærekraftighet.

Oppdatering 22.02.2010
Raskt nedbrytbart plastikkmateriale  er under utvikling
Bloggpost om hvordan informasjonsdesign kan redde miljøet får høye lesertall og mange kommentarer

6.    Alle snobber ned
Finanskrisen har satt sine spor. Kundene krever mindre snobbete løsninger og ser seg ikke blind på fancy (men unyttig) funksjonalitet .  ”Det enkle er ofte det beste” er et uttrykk som ikke går av moten i dette året.

Oppdatering 04.01.2010
Året begynner bra med følgende tweet fra @runegri “I just started the new year by removing some unnecessary features. Feels good!9:27 AM Jan 4th from TweetDeck”

7.    Useit.com får nytt design
Jacob Nielsen skjønner at alle har skjønt at det urgamle designet på useit.com ikke duger lenger. Han kryper til korset og lar noen superflinke designere lage ny side til ham. Den nye siden vil inneholde elementer fra sosiale medier.

Oppdatering 22.02.2010
Ingen tegn til redesign foreløpig.

Tusen takk til alle dere som har fulgt oss på brukskvalitet.no i 2009!
Hva tror du det nye året vil bringe?

Foto: Flickr by: AmmarQ8.com

1. Lær deg stammespråket. Smidige metoder inneholder begreper, artefakter og seremonier som du bør sette deg inn i
Skal du inn i et smidigprosjekt, må du forstå begrepene som brukes og finne de foraene som gjør at du får formidlet designforslag og endringer. Du vil nok kjenne igjen problemstillingene som oppstår, men de kommer gjerne i en annen rekkefølge og heter andre ting enn det du er vant til.

 
2. Bli med på de seremoniene som er nyttig for ditt arbeid og for teamfølelsen
“Du står midt i standup-en vår”, fikk jeg beskjed om en av de første dagene i prosjektet. Seremonier som ståoppmøter, scrum of scrums og retrospektiver er en del av arbeidshverdagen for medarbeidere i et smidigprosjekt. Om du skal delta på alt, får du ikke gjort stort annet, særlig hvis du skal jobbe for flere team samtidig. Her er det nyttig å prøve seg frem, slik at du får med deg det som skjer, uten at du trenger å overhøre alle tekniske eller forretningsmessige avveininger som gjøres underveis. Det er viktig at designere er med på diskusjoner rundt produktkøen for å få frem gui-relaterte oppgaver. Hvis du har en dedikert plass i et av teamene, kan det være greit å følge seremoniene til det teamet, slik at du føler at du er ordentlig med. Det er aldri gøy å føle seg utenfor.
 
3. Tolk brukerhistorier ved å tegne ut skjermbilder
I smidigprosjekter er kravene til systemet utformet som brukerhistorier. Brukerhistoriene er korte og inneholder en begrunnelse for hvorfor kravet skal gjennomføres. I foredraget GUI-prototyper er Gode på Smidig2008  snakket jeg om at enhver tekstlig beskrivelse kan tolkes på mange forskjellige måter. Det er en stor fordel å tegne ut brukerhistoriene i form av skjermbilder som kan brukes i kommunikasjon med både utviklere og forretningssiden. Skjermbildene kan også synliggjøre behovet for nye brukerhistorier som må til for å få ting til å henge sammen.

4. Lær deg å formulere nye brukerhistorier
De første gangene jeg viste nye skjermbilder fikk jeg stadig høre: “men, det er en annen brukerhistorie”. “Javel”, tenkte jeg, ”da får jeg skrive en ny historie.”
Brukerhistoriene har en enkel form, og det er lett å lære seg å skrive nye
Eksempel på mal:
Som en <bruker>
ønsker jeg <funksjon>
 slik at <verdi>
Brukerhistoriene legges inn i en produktkø som brukes til å prioritere oppgavene. Det er produkteier på forretningssiden som prioriterer, så her gjelder det å bruke sin påvirkningskraft.

5. Heng oppdaterte skjermbildeskisser opp på veggen
Fra jeg hang de første skissene opp på veggen til utviklere og arkitekter uoppfordret stod rundt dem å diskuterte GUI tok det under fem minutter. Skjermbildeskisser som blir liggende på en filserver kommuniserer ikke så bra. Det gjør heller ikke designforslag som kun finnes inne i ditt hode. Det er noe med å få skissene opp på veggen, se sammenhenger mellom dem og tegne endringsforslag rett på papiret som gir en stor ekstraverdi.

6. Utnevn en “stylist” i hvert utviklingsteam som har ansvar for GUI og stilark
Det er fornuftig at noen holder orden i stilarket og sørger for å formidle GUI-ting videre til resten av teamet. Hvis prosjektet er stort, er det viktig at dette ansvaret ikke ligger på en person alene, men at alle teamene som jobber med GUI har minst én person som kjenner stilarket og GUI-komponentene spesielt godt.

7. Bedre kommunikasjon ved avholde ståoppmøter for designere og stylister 1-2 ganger i uken
Ståoppmøter er godt egnet for kjappe avklaringer og statusoppdateringer. Å avholde ståoppmøter for alle som jobber med GUI-relaterte oppgaver, gjør informasjonsflyten bedre.
 
8. Kjør brukertester
Smidig gir deg ingen unnskyldninger for å la være.

9. Lag GUI-retningslinjer i form av sjekklister underveis
Ved å utforme GUI-retningslinjer som en sjekkliste, er det lettere å bruke denne til gjennomgang av (nesten) ferdigutviklede skjermbilder. Å få utviklere og testere til å pugge retningslinjene kan være en utfordring. Vi arrangerte kurs med quiz. Husk premier!
 
10. Sørg for at GUI-retningslinjene blir en del av Definition of Done
I store prosjekter er det ofte vanskelig å få til et konsistent grensesnitt. Smidigprosjekter er intet unntak. “Definition of Done” er en sjekkliste som brukes til å definere hva som skal til for at en utviklingsoppgave skal kunne sees på som ferdig. Som designer kan du sørge for at GUI-retningslinjene blir en del av denne definisjonen.

Tipsene er basert på arbeid i et stort smidigprosjekt med totalt 11  utviklingsteam og 3-4 dedikerte Gui-ressurser. Tusen takk til mine kolleger Ram, Johannes og Trond for verdifulle innspill til innlegget. Har du andre tips, råd eller andre erfaringer du ønsker å dele? Skriv gjerne en kommentar.

Lær mer:
Tre modeller for organisering av designere  i smidige prosjekter
3-minutters guide: Dette er Scrum (pdf)

1. Ikke lenke til andre nettsteder
Dette grusomme stuntet gjøres av mange nettaviser. Når de lenker til andre nettsteder er det sine egne datterselskaper. Årsaken er at de ikke vil lenke til sine konkurrenter, men resultatet er ondskapsfullt – som BBC kan fortelle, er det å lenke til andre nettsteder noe av det brukerne deres setter mest pris på. ”You are what you share”, sa Joshua Porter. Så til alle nettaviser som ikke lenker til kilder: Hvis ikke deler noen ting, så er du….?

2. Levere halve artikler på RSS
Nettsteder som kun leverer overskrift og lokketekst i sin RSS-feed er onde. De vil ha deg til å klikke inn til nettsidene hvor de kan få vist frem reklamebanners, og friste deg med andre lenker. Når jeg skal anbefale gode feeds til mine venner nevner jeg bare de som gir meg hele artikkelen.

3. La være å gjøre ting enklere fordi du vil tape sidevisninger
Sidevisninger var det samme som penger i gamle dager, før bannerfesten ble avlyst. Men de som overlever i lengden er de som utvikler seg og blir mer brukervennlige. Et godt eksempel er alle diskusjonene om bildevisning på et større norsk rubrikknettsted (min tidligere arbeidsgiver). Å gjøre bildevisningen bedre med enkel lightboxteknikk var et stort tema ettersom det ville kannibalisere antallet sidevisninger men det burde ikke være noe tema i det hele tatt dersom det gjør bruken av sidene enklere.
Et annet eksempel er Tyske bilbladet Auto Motor und Sport sitt bildegalleri hvor hvert 10. bilde laster hele siden på nytt (og dermed refresher bannerne) istedenfor å hoppe sømløst gjennom alle bildene.

4. Banners midt i innholdet
Tydelig visuell gruppering av informasjonselementer på websider er en av de mest grunnleggende teknikker for å skape god oversikt og lesbarhet. Men ondskapen bobler frem og vil plassere reklamebanner midt i artikler, midt i menyer (vg.no osv.) For å lure deg til å klikke på dem. Men det går på bekostning av visuell støy, og kostnaden er betydelig. Det å skape uro på siden gjør at vi ikke klarer å fokusere blikket og vi blir slitne av å lese, og leser færre artikler som igjen fører til… ja du kan selv resonnere videre.

5. Lokkeoverskrifter
Overskrifter som mangler en vesentlig del av informasjonen gjør at du bare MÅ klikke. Og selvsagt er historien langt fra så spennende som du kanskje trodde. Men du klikket, og ondskapen har nok en gang gitt flere sidevisninger ved å rope ulv. En god løsning er å fylle overskriftene med mest mulig informasjon, da leser vi faktisk mer, se eksempler fra BBC hos vår venn Jakob. Dessuten lar vi oss bare lure når noen roper ulv første gangen.

6. Skjule vesentlig informasjon
Dersom jeg googler spesifikke firmanavn på jakt etter et firma sin hjemmeside får jeg som regel 2-3 sider med treff i ulike nettkataloger. Disse utgjør en ikke ubetydelig del av ondskapen på internett i 2009. Forretningsmodellene er ofte like onde som de er enkle – skjule vesentlig informasjon som for eksempel adressen til hjemmesiden slik at annonsørene må kjøpe pluss/gull/super/turbo-oppføring og dermed gi kroner i kassa. Men mellomledd er og blir mellomledd og vi brukere forstår forskjellen. Google er nødvendig, men de klassiske nettkatalogene gir ingen verdi ved å skjule informasjon.

Løsningen er bærekraftig design
En løsning er ikke bærekraftig dersom du må ty til sleipe triks for å få folk til å klikke på noe de ikke trenger. Det er helt greit å selge ting, reklamere osv men det må skje på brukerens premisser. Når kommersielle websider ikke baserer seg på hurtige gevinster men i stedet for gjør det de kan for å støtte folks behov vil brukerne bli takknemlige. De vil huske deg, anbefale deg og spre ditt gode rykte for deg, helt gratis. Da vil du tjene penger på en bærekraftig måte.

Omlag 70 personer deltok på seminaret om universell utforming som ble avholdt i mars 2009.

På et seminar tidligere denne måneden var en rekke aktører fra det offentlige og det private til stede. Fokus på seminaret var den nye loven om universell utforming. Det var en tankevekker at seminaret ikke var utformet etter retningslinjene for tilgjengelige kurs, møter og konferanser. Blant foredragsholderne var representanter fra Helsedirektoratet, leverandørsiden og brukerperspektivet.

Ny lov om forbud mot diskriminering
Seniorrådgiver Stig Aga Aandstad fortalte om den nye loven om forbud mot diskriminering på grunn av nedsatt funksjonsevne. I loven står det ” “Nye IKT-løsninger […] skal være universelt utformet fra og med 1. juli 2011, men likevel tidligst tolv måneder etter at det foreligger standarder eller retningslinjer for innholdet i plikten. For eksisterende IKT-løsninger gjelder plikten fra 1. januar 2021.” Det ble også reist også en del spørsmål rundt hvordan dette skal forstås. Hva er for eksempel en ny IKT-løsning?

Påvirker statens innkjøp
Frank Fardal fra DIFI fortalte i sitt innlegg hvordan den nye loven vil kunne påvirke statens innkjøp i årene fremover. Det ble påpekt at kompetanseheving blant bestillerne var viktig for at de skal vite hva de skal spørre etter.

Universell utforming gjør målgruppen større
Universell utforming og brukervennlighet er ikke det samme, men er likevel to sider av samme sak. Det er lett å tenke på blinde som målgruppen som skal tilfredsstilles når man snakker om universell utforming. Men, som det flere ganger kom frem på dette seminaret, er universell utforming noe som er til hjelp for en stor gruppe med ulike behov, og som gjør at flere kan benytte seg av de systemene og nettsidene vi utvikler.

Potensial for innovasjon
Fjernkontrollen og enhåndskranen er eksempler på at teknologi som i utgangspunktet ble utviklet for et spesielt formål nå er til nytte for mange. Mulighet for opplesning av tekst som er lagt inn med tanke på blinde kan også være tilnytte for en som kjører bil eller en som har tatt en øyeoperasjon. Det ligger et stort potensial for innovasjon i tilknytning til universell uforming.

Foredrag uten PowerPoint
Dyslektikeren Jonas var den eneste av foredragsholderne som stilte uten PowerPoint-presentasjon. I stedet fortalte han sin historie om møtet med skolen, hvor lang tid det hadde tatt å få de riktige hjelpemidlene og hvor mye han lærte nå som han hadde dem. For flere av dem som satt i salen var mangelen på visuell fremstilling en fordel. En representant fra Blindeforbundet mente at alle foredragsholderne burde stilt uten PowerPoint for at alle tilhørere skulle ha de samme forutsetningene. Videre forklarte han at det ikke var så lett for en blind person å vite hvor kaffen var når den som snakket bare sa ”der oppe”.

Hva er det til lunsj?
I lunsjen var det satt frem tapas av forskjellige slag. En ting som vi seende kanskje ikke tenker så mye over er at det kan være vanskelig for blinde og svaksynte å finne ut hva som står på bordet. En av de svaksynte fikk øye på en hvit lapp med svart skrift som lå på et av fatene. Lappen opplyste om at det som lå på fatet ”inneholder nøtter.” Det kunne med andre ord være alt fra fyrstekake til foccatia med pesto.

Skal vi tenke på alt mulig?
Hvis du jobber med universell uforming er det en trøst at løsninger som lages for å dekke et spesialbehov er til gagn for mange. Er er vanskelig å tenkte på alt. Det er likevel ikke noen unnskyldning for å ikke tenke på universell uforming i det hele tatt. Enten brukeren er fremmedspråklig, allergiker, blind, dyslektiker, håndleddsoperert eller midlertidig ukonsentrert vil universelt utformede løsninger kunne komme til nytte. Det er en vesentlig forskjell på å betrakte universelle løsninger som spesialtilpasning for et mindretall og det å se på det som en mulighet for tilgjengeliggjøring for en større målgruppe. Det unormale er faktisk helt normalt i et inkluderende og universelt uformet samfunn.

Lenker:
Veileder for tilgjengelige møter, kurs og konferanser
Presentasjoner fra seminaret

På Flybussen sine sider blir jeg møtt av blide ansikter-  hele 10 tilsammen og mange er animerte. Søkefeltet som drukner i dette visuellet orgiet av ansikter er også et syn for seg. Under de 10px store dropdown-kontrollene finnes en vannrett gradestokk av enorme dimensjoner. Er det 11 grader kvikksølvet viser?

Nei, det er en slider for å velge klokkeslett. Og hvor er søkeknappen? Så grundig som dette er det sjelden jeg står fast på noe nettsted. Jeg VET at det går en buss til og fra Sonsveien, men Son er ikke noe sted å finne. Så i dette skjemaet velger jeg som følger:

Se så. Der kom det et resultat, det bare skled ned fra den hengepuppen som tidligere ble vist under gradestokken. I listen vises alle ruter på valgte tidspunkt (ca 16 grader) fra Gardermoen – til gardermoen, med reisetid på 0 minutter. Fantastisk! Dropdown-kontrollen “til flyplass” lar deg i steden velge “fra flyplass”. Det gjorde jeg, i den tro at jeg fikk se avganger fra Gardermoen når det var ca. 16 grader. Den gang ei, da fikk jeg samme resultat en gang til. Stedslisten viser bare de store byene så jeg har nå forstått av flybussen.no er en merkevare som ikke favner alle busser som går fra Gardermoen. Litt googling avslører at det er Flybussekspressen som går til Son. Men nå er jeg nysgjerrig på hva slags tilbud flybussen.no har og leter videre for å se hva mer flybussen.no har å tilby.

Du kommer hvertfall ikke frem med flybussen.no
Du er ikke fremme før du er fremme, skryter de på sine nettsider. Denne noe kryptiske påstand underbygges av deres nye nettløsning, lansert 29. september i fjor iflg. nevnte nettside. Siden som informerer om lanseringen nevner bl.a.:

“Hurtigsøket gir deg anledning til å finne rutetider for Flybussen med noen få tastetrykk”

Hva slags hurtighet de har målt det til vites ikke, erfaring fra brukertester viser at dropdown-kontrollere er notorisk vanskelige å bruke og dersom du måler antall klikk, så er de noe av det mest klikk-krevende jeg vet om. Dessuten foregår hurtigsøket HELT uten tastetrykk.

“Sist men ikke minst, har du også mulighet til å bruke vår karttjeneste. Denne finner du øverst til høyre på hver enkelt avdeling sin underside. Dersom du skal på et møte kan du skrive inn adressen, så vil vi vise deg hvilke holdeplasser som er nærmest. Du kan også planlegge hvilken bussavgang du skal benytte med kartløsningen”

Dette høres nyttig ut. Men si meg en ting,  hvor er “øverst til høyre på hver enkelt avdeling sin underside” om jeg tør spørre? Jeg ser et grønt kart på forsiden, det kalles “detaljert søk” og gjør følgende: Du kan velge et sted, og deretter får du det samme skjema som for hurtigsøk, men da kun for det stedet du valgte i kartet.

Er det pinlig nok, eller skal jeg fortsette?
Jeg kunne latt godt nok få være godt nok og slippe flybussen.no ut av gapestokken. Jeg er tross alt ikke ond, så jeg kunne vendt det andre kinnet til som vanlig. Men det var helt til jeg klikket på en link og oppdaget at den åpnet samme side, men da inne i et frameset:

Det var dråpen. Nå er det fengselsregler som gjelder. Flybussen, kjære snille Flybussen, fortell meg hvorfor dere lar meg oppleve alt dette, i 2009:

Tomme sider
Menyvalget “Flybussene i Norge” inneholder kun et gigantisk banner med reklame for Flybussen, med teksten “Du er ikke fremme før du er fremme”

Elendig informasjonsarkitektur
“Kontakt” og “selskapene” i hovedmenyen er samme ting, men splittet opp og ikke linket mellom hverandre. Det finnes også en tredje side som heter “kontaktinfo”. Se om du klarer å finne den, den har nemlig et annet innhold…

STORE BOKSTAVER og floskler
I venstremenyen, som jeg ikke helt har forstått hvor og når dukker opp, BRUKES UTELUKKENDE STORE BOKSTAVER. Se f.eks. menyvalget “BEFORDRINGSVEDTEKTER” som ikke har noe innhold, men som henviser til et sted (ikke linket) hvor disse kan leses.

Under menypunktet “VELKOMMEN TIL VÅRE NYE NETTSIDER” finner man enda mer informasjon om de tidligere omtalte “web sidene” (overlagt ord delings feil, red. anm)

SAS Flybussen har sammen med flybusser i 14 norske byer etablert nye nettsider. Dette for at du som kunde skal oppleve våre sider som mer brukervennlig og informative.

Nei kjære dere, men jeg finner det hele svært interessant rent faglig… Tanken er god, men akk så brukerfiendtlig gjennomførst. Her er det de beste intensjoner om å skape gode opplevelser, de er til og med uttalt på nettstedet – Brukervennlige og informative skal de være. Så hva med å la brukerne medvirke neste gang? Se for øvrig mine 10 bud for gode brukeropplevelser.

Døde linker
Sist, men ikke minst: under “KJØP BUSSBILLETTEN PÅ NETT” kan man klikke på linken “Klikk her for kjøp” og få følgende beskjed:

“Siden er ute av drift.
Billetter kan kjøpes på bussen.”

Og med det får flybussen i Oslo siste ord i denne omgang.

Smidig metodikk er spennende og veldig i vinden om dagen. Spesielt Scrum er populært. Det er sannsynlig at interaktive designere før eller siden vil komme bort i metodikken og jobbe med utviklere som jobber smidig. Smidig-tankesettet er forlokkende fordi det er i tråd med det brukerorientert design ønsker: tett kommunikasjon, kundeinvolvering og mulighet til å ta hensyn til endringer (se Smidig-manifestet). Men det første spørsmålet designere lurer på er: Hvor i all verden passer jeg inn i denne metodikken?

Her presenterer jeg tre modeller på organiseringer vi har sett og jobbet etter. Jeg bruker Scrum som eksempel siden det er det jeg har erfaring med, men modellene kan også generaliseres og brukes på andre metodikker.

I figurene betyr “PO” Product Owner (produkteier) og UX betyr User eXperience (designer).

Modell 1: Designer i utviklingsteam

De fleste designere kommer inn i et IT-prosjekt samtidig som utviklerne og det er da lett å tenke at designeren også skal jobbe i teamet sammen med utviklerne.

Fordeler:

• Sitter nært til utviklerne

Det at designeren sitter nært utviklerne gjør det lettere å samarbeid og man kan få til arbeidsprosesser der utviklerne spør mens de jobber. Da klarer man opp misforståelser og man kan løse ting designeren ikke har tenkt på. Kvaliteten på det implementerte kan dermed øke og man får lettere godt samarbeidsklima siden man sitter i samme båt.

Ulemper:

• Scrum er laget for og av utviklere. Det finnes ingen naturlig plass for en designer
• Designoppgaver kan være vanskelig å bryte ned i oppgaver/gule lapper innenfor en sprint
• Svært ressurskrevende

Mange av seremoniene i Scrum egner seg kun for de som jobber med de tekniske delene av prosjektet. Er det hensiktsmessig for en designer å være med på planning poker og estimere story points?

Mange designoppgaver går over lenger tid enn en sprint (avhengig av hvor lang sprinten er). Det kan også være vanskelig å si når noen av oppgavene kan anses som ferdig. Hva er f.eks. definisjonen av “ferdig” for overordnet konsept eller for navigasjonsmodell?

Denne modellen er ressurskrevende. I følge Scrum skal alle som er med i scrum-teamet være 100% i prosjektet og skjermet fra andre forstyrrelser. Min erfaring tilsier at designere ofte er involvert i flere prosjekter samtidig. I tillegg er det ofte manko på designere i IT-prosjekter generelt.

Modell 2: Designer(e) i ressurs-pool

Designerne sitter sammen i et team og fungerer som rådgivere inn mot prosjektene. Designerne er her ikke en del av de faktiske prosjektene og gir kun råd og føringer, de er dermed ikke tett inne på problemstillingene.

Fordeler:

• Designere kan sitte i eget team
• Mer tilgjengelig for flere projekter
• Kan løse ressursproblemer (designere er gjerne i manko)

Det at designerne sitter i eget team gjør at det lettere for designerne ha gode sparringpartnere, noe som bør øke kvaliteten på design. Det er også en fordel dersom du prøver å innføre felles designpatterns på tvers av systemporteføljen din eller du ønsker å konsistens i design og brukergrensesnitt i flere prosjekter.

Ved å ha rådgivende designere kan du i teorien ha en mer fleksibel oppbygning som gjør det lettere å sette inn designressurser der de trengs. Dette gjør seg spesielt gjeldende dersom du har mange prosjekter som kjører og få tilgjengelige designere.

Ulemper:

• For langt unna prosjektet
• Blir rådført for lite og for sent
• Skaper lettere “oss” og “dem” følelse

Den klart største ulempen med denne modellen er at designerne ikke sitter i prosjektet, noe som gjør at de ikke kommer godt nok inn i problemstillingene. De kan dermed kun hjelpe til med enkle problemstillinger.

En annen konsekvens av å være utenfor prosjektet er at de ikke blir rådført like mye som de hadde blitt gjort om de var en del av prosjektet. Dette henger sammen med at det finnes færre naturlige arenaer for kommunikasjon. Når designerne først kommer inn blir det lett mye kritikk, og da kommer kritikken som oftest etter at sprinten er ferdig og deler allerede er implementert.

Modell 3: Designer utenfor team

Fordeler:

• Tilpasset Scrum
• Nære teamet
• Støtter primært produkteier (som virker mer naturlig?)

I denne modellen deltar designeren kun i de Scrum-seremoniene som er hensiktsmessige for han og der han kan bidra ut i fra rollen han har, dvs at modellen er tilpasset til Scrum.

Designeren sitter fortsatt nærme teamet, men fokus er på å støtte de med funksjonelt ansvar og fungere som brobygger mellom produkteier og teamet.

Ulemper:

• Ressurskrevende (men åpner for at designer kan delta i flere prosjekter)

Konklusjon

Så hvilken modell skal du velge? Det spørs på flere faktorer, blant annet hva du ønsker å løse og om du har tilgang til nok designressurser, eventuelt hva du har råd til å leie inn.

Dersom ressursene er knappe

Om du har få ressurser mener jeg at modell 2 er bedre enn ingenting. Men vær klar over at nytten er begrenset siden designeren får liten reell mulighet til å sette seg inn i problemstillingen eller lære sammen med resten av teamet. Designeren får også liten påvirkningskraft.

Dersom UX-personen også jobber med utvikling

Modell 1 egner seg godt dersom den som har ansvaret for brukeropplevelsen også jobber med utvikling (husk at den som har ansvaret for brukeropplevelsen ikke trenger å være en designer). Om du er så heldig å ha en dyktig front-end utvikler på teamet er det ingenting i veien for å be denne personen ta ansvar for brukeropplevelsen.

Dersom designer ikke er 100% tilgjenglig, men du ønsker maks påvirkningskraft

Personlig forerekker jeg modell 3 — designer utenfor teamet. Dette er den modellen som har fungert best for meg. Designeren kan jobbe svært tett med produkteier og de kan sammen spesifisere løsninger og presentere disse for teamet. Dette er også en modell som gjør det mulig for designeren å bruke tiden sin maksimalt ved kun å delta på de Scrum-seremoniene som er hensiktsmessige for hans rolle.

Uansett kommer du ikke unna at både vi som er designere og de som er utviklere må tilpasse Scrum-metodikken for at vi skal jobbe bedre sammen. Målet er det samme for begge grupper: Lage bedre løsninger for brukerne.

Har du noen erfaringer eller forslag til andre modeller? Kom med dem i kommentarene!

PS. 25. februar skal Dataforeningen ved faggruppene BITS og EPU holde et medlemsmøte om dette temaet. Tre erfarne designere og tre erfarne scrummasters/utviklere kommer og deler sine erfaringer. Målet er at alle skal kunne gå hjem med seks gode forslag til hvordan vi kan jobbe bedre sammen. Bli med!

(Oppdatert 3.2 etter tilbakemeldinger fra deltakere på XP meetup).

1. Snakk med brukerne dine
Ved å bruke kvalitative undersøkelsesmetoder vil du få innsikt i brukernes behov og med din kunnskap om ditt marked og din teknologi vil du ha de beste forutsetninger for å skape gode brukeropplevelser.

2. Planlegg brukeropplevelsen
Det er enkelt å legge en plan for brukeropplevelsen. Bedrifter har ofte merkevarestrategier som inneholder stikkord for hva slags assosiasjoner de ønsker at brukerne skal ha til deres merkevare. Skal merkevaren oppleves som Moderne, Innovativ og Spennende? Bruk det som en rød tråd når du designer.

3. Ta ansvar for brukeropplevelsen
Brukeropplevelsen er summen av alle beslutninger om teknologi, implementasjon, utseende og interaksjon. Systemutviklere er ofte de som har størst påvirkning på brukeropplevelsen, men de er ofte ikke klar over det. Ethvert prosjekt må ha en beslutningstager som er ansvarlig for brukeropplevelsen og kan være brukerens advokat, sørge for motivasjon, inspirasjon og være ansvarlig for å ivareta den helhetlige visjonen.

4. La brukerne medvirke i prosjektet
Brukermedvirkning er en forutsetning for å lykkes med å skape gode brukeropplevelser. Ved å vise prototyper for faktiske sluttbrukere, gjennomføre brukervennlighetstester og planlegge for forandringer i prosjektet på grunnlag av slike undersøkelser vil du kvalitetssikre brukeropplevelsen på et tidlig tidspunkt slik at du kan lansere med minimal risiko.

5. Vær entusiastisk
Entusiasme smitter. Dersom prosjektdeltakerne er entusiastiske overfor produktet de lager, vil det vises. Løsninger som lages med lidenskap vil ofte holde høy brukskvalitet. Den som er ansvarlig for brukeropplevelsen må skape motivasjon og inspirasjon.

6. Vær konsekvent
Ukonsekvent oppførsel fra digitale produkter kan i verste fall oppleves som psykopatisk. Vær konsekvent med navigasjon, begreper, utseende og tekst.

7. Ha et passende tonefall
Språk, tekst og tilbakemeldinger er viktig. Ved å sørge for et omtenksomt, saklig og høflig tonefall som treffer din målgruppe unngår du at brukeropplevelsen blir upersonlig, tørr eller kjedelig.

8. Design omtenksomhet
Dersom brukerne skal like produktet ditt, må det oppføre seg som en omtenksom person. Databaser er notoriske til å legge ansvar for sin utilstrekkelighet over på brukeren så du må sørge for at alle deler av ditt system ”oppfører seg ordentlig”.

9. Mål brukeropplevelsen
Dersom det er verdt å lansere, er det verdt å måle. Empirisk grunnlag om faktisk bruk får du først etter lansering, men du må ta høyde for det underveis. Med webløsninger må du bygge inn støtte for webanalyse underveis for å få de svar du ønsker. Det er billigere enn å gjøre det i etterkant.

10. Gjør det for brukerne
Googles 1. bud slår fast at brukeren kommer først, ikke pengene. Det er egentlig ganske enkelt, sier journalist Jan Omdahl: ”Setter du brukeren i fokus, kommer inntektene etter. Setter du inntektene foran brukeropplevelsen, går brukerne et annet sted.”

Har du flere bud? Det finnes også andre mer manifest-lignende lister å finne på nettet, f.eks. Eric Reiss’ Web Dogma og Dieter Rams 10 commandments.

Har du noen gang opplevd at alle nikker og tror de er enige, selv om det viser seg at de tenker på helt forskjellige ting? Utviklere har ofte en unik evne til å tenke abstrakt. Det er ikke sikkert at sjefen har den samme forestillingsevnen. Eller kanskje han bare ser for seg ting på en annen måte. En tekstlig beskrivelse kan tolkes på mange måter. Prototyping er en av flere teknikker du kan bruke for å gjøre systemkravene mer håndfast og forståelig for alle i prosjektet.

Hva er GUI-prototyper Gode til?

Det er flere grunner til å bruker prototyper i smidige prosjekter. Det prototyper er Gode til er blant annet:

  
• Å kommunisere – å sikre at alle er enige om de samme tingene
• Å spesifisere – å si noe om hvordan ulike funksjoner skal se ut og hvordan de skal fungere
• Å gjøre brukertester på – slik at prosjektet på et tidlig tidspunkt kan få vite om de er på rett vei.

Detaljnivå og tidsbruk

Det finnes flere ulike former for prototyping. Noen av dem er:

• HTML-prototyper
• Prototyper i PowerPoint
• Photoshop-skisser
• Papirprototyper

Det å snakke om høy- eller lavnivå brukertesting gir egentlig ikke så mye mening, det som betyr noe er riktig grad av detaljnivå og hvor lang tid du bruker i forhold til resultatene du oppnår. I mange tilfeller vil papirprototyper være det riktige valget i smidige prosjekter. Papirprototyping gjør det mulig for designere å sprinte og å ligge et hestehode foran med spesifikasjonene.

Slides fra lyntalen som ble holdt på Smidig 2008 finner du her:
[slideshare id=681600&doc=guiprototyper-er-gode-eli-toftyandersen-slideshare-1224668565309169-9&w=425]

GUI-prototyping var tema for en av Open Space sesjonene som ble satt opp på konferansen. Har du erfaring med bruk av GUI-prototyper i smidige prosjekter? Del dem gjerne med oss!

Eli Toftøy-Andersen gjesteblogger på brukskvalitet.no med jevne mellomrom. Til vanlig jobber hun som rådgiver innen brukervennlighet og design i Steria AS.

I følge Microsoft tilbyr SharePoint en ”enkel, velkjent og konsekvent brukeropplevelse”. Kan en standardløsning være brukervennlig i seg selv? Nei, selvfølgelig ikke. Det kommer an på hvordan løsningen designes, implementeres og anvendes.

Er SharePoint lett eller vanskelig?

Det er solgt 75 millioner lisenser for Microsoft SharePoint. Det betyr at det er opptil 75 millioner mennesker som bruker denne plattformen (i større eller mindre grad.) Noen synes SharePoint er lett, andre synes det er vanskelig. Mye er avhengig av hvem de er, hva de kan og hva de bruker løsningen til. Hvis det var slik at alle SharePoint-løsninger var enkle og brukervennlige i seg selv, hadde vi ikke hatt en jobb å gjøre. Men kan vi som designere og interaksjonsdesignere være til hjelp hvis vi ikke kjenner løsningen og vet hva den har å tilby?

Ta med deg usability-verktøykassen

Den gode nyheten er at de fleste av usabilityteknikkene vi bruker i andre prosjekter kan tas med inn i SharePoint-prosjekter. Bruk av strukturkart er et eksempel. Når du gjør en informasjonskartlegging og sitter igjen med masse gule lapper med innholdselementer er strukturkart nyttige. Å lage et strukturkart fremfor å legge kategoriene rett inn som i SharePoint kan spare deg for masse tid når du skal få oversikt, endre navn og restrukturere. Brukertesting på papirprototyper er en annen teknikk jeg har god erfaring med å bruke i SharePoint prosjekter.

Ikke la funksjonalitets-freakerne styre showet

En av grunnene til at SharePoint er så populært er at det har så mange funksjoner. Det at en funksjon er tilgjengelig er ikke det samme som at den må benyttes. For brukerne kan det være et mareritt å bli overlesset med funksjonalitet fra første stund. Legg derfor til funksjonalitet litt etter hvert og ta bort alt som ikke er nødvendig.

Fra ulldott til drømmeslott

Du trenger ikke være en SharePoint-ekspert for å lage en prototyp for et intranett basert på denne plattformen. Du trenger heller ikke være ekspert for å lage en grafisk skisse, men det kan være greit å vite litt om plattformen, hva det er mulig å endre på og hvilke konsekvenser designforslagene dine får, spesielt hvis du har begrenset med tid og utviklingsressurser til rådighet. Hvis SharePoint er ullent for deg, risikerer du å designe et drømmeslott. Dette kan lett skape frustrasjon i prosjektet. Frustrasjon for deg, fordi systemet ikke blir slik du hadde designet det — irritasjon hos utviklere fordi det du har designet ikke er mulig i SharePoint, og urealistiske forventninger hos interessenter i prosjektet som får se skissene og regner med at det er sånn det kommer til å bli.

Nøkkelen er kunnskap

Når du jobber med interaksjonsdesign er det alltid greit å ha oversikt over plattformen du designer for. Kommer det opp forslag om funksjonalitet som ikke finnes som en del av standardpakken, må denne naturlig nok defineres mer nøyaktig. Noen av webdelene i SharePoint kan ha delvis overlappende funksjonalitet. Da gjelder det å kunne gi kunden gode råd om hvilken webdel de bør bruke og hvilke konsekvenser valgene får. Legger du for stor vekt på det grafiske vil det kunne gå ut over fleksibiliteten og brukeropplevelsen totalt sett.

Når alt kommer til alt er det kunnskap det dreier seg om. Har du kunnskap om hvordan SharePoint fungerer, er det også lettere å designe et brukervennlig system basert på denne plattformen.

Se også slides fra presentasjonen på Yggdrasil 2008:
[slideshare id=681618&doc=sharepoint-en-brukervennlig-standardlsning-slideshare-1224669046519194-8&w=425]

Eli Toftøy-Andersen gjesteblogger på brukskvalitet.no med jevne mellomrom. Til vanlig jobber hun som rådgiver innen brukervennlighet og design i Steria AS.

Haakon Halvorsen (t.v.) og James Bjerkholt fra Tarantell

The power of default handler om at man i alle steg skal ha ett ferdig definert valg som er godt nok til at man kan trykke “neste” hele veien. Målinger viste at 2 av 3 brukere ikke tok seg bryet med å endre defaultvalgene. Ved å holde antall valg nede unngår man også “the paradox of choice”. Det gir brukerne større tilfredshet å forholde seg til færre valg.