• Er du en av de som har forstått hvilken konsekvens det kan ha, å la selvorganiserte teams levere perfekt testet kode – med funksjonalitet ingen brukere forstår eller vil ha?
• Har du forsøkt å integrere arbeid med brukersentrert design i smidige prosjekter uten å lykkes?
• Samarbeider utviklerne og interaksjonsdesignerne i prosjektet ditt bra, men de resulterende systemene forblir middelmådige?

Frykt ikke! Ram Yoga og Jon Gunnar Wold har skreddersydd en 180-minutters workshop kun for deg slik at du kan lære av våre erfaringer og lykkes med smidig brukersentrert design. Vi viser deg hvordan UX og smidige metoder utfyller hverandre og hvordan du konkret må arbeide med planlegging, roller og metoder i din organisasjon og  dine prosjekter for at du skal levere nøyaktig den funksjonaliteten brukene dine trenger – og litt til. Sees vi på XP2010 i Trondheim i Juni?

• Les om vår workshop på XP2010 (Engelsk)
• Program for konferansen
• Konferansens hjemmeside
• XP2010 på Twitter

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)

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).

Her er noen smakebiter på lyntaler som er superrelevante for UX:

Øyvind Brande-Lien
Smidig brukerorientert design

Eli Toftøy-Andersen
GUI-prototyper er gode

Jon Gunnar Wold
Slik kan utviklere og designere samarbeide smidig

Daniel Brolund
User-guide-driven development (UGDD)

Og ikke minst: Reidar Sande med Ble Mona Lisa malt iterativt?
Her mangler slides fra videoen men de kan lastes ned her

For de som er interessert finnes det også noen gode intro-til-scrum lyntaler for å komme i gang. Alle videoene ligger her, hvis du lurer på hvor du skal begynne, er topp-lista er fin referanse.

Programmet Comic Life fra plasq.com er et av mange program for å lage tegneserier. Med det kan du raskt lage enkle og underholdende tegneserier ved å legge morsomme snakkebobler til feriebildene dine. Men bruksmulighetene stopper ikke der. Verktøyet kan brukes til å lage enkle, forståelige og refererbare storyboards og scenarier.

Tekstscenarier blir ofte lange og kjedelige å lese. De er også vanskelig å referere til, utfordrende å diskutere, overbeviser lite og skaper lite entusiasme. Bare se på eksemplet under:

Ble du heller ikke inspirert av scenariet? Da er det langt lurere å fortelle samme historie med bilder. Et bilde eller en illustrasjon forteller som kjent mer en tusen ord.

Scott McCloud er et stjerneeksempel. I sin tegneserie om Google Chrome bruker han utviklerne bak systemet som figurer i en fantastisk tegneserie som forklarer på en mesterlig måte selv de mest kompliserte løsningene under panseret til Chrome.

Comic life

Et overraskende enkelt brukergrensesnitt lar deg lage tegneserieruter, legge bilder inn i de og legge snakke- og tenkebobler over bildene dine – perfekt for å lage scenarier i en tidlig fase i utviklingsprosessen.

Med tegneseriescenarier oppnår du en rekke fordeler:

• De gjør det enkelt å kommunisere designideer og konsepter med sjefer, utviklere og sluttbrukere
• Det blir enklere for alle interessenter å endre eller lage egne scenarier
• Det er enklere for interessenter å referere til
• De er interessante å lese (i motsetning til tekstscenarier)
• De gjør det lettere å peke på problemer
• De er raske å lage
• Det er enklere å se ulike løsinger på problemet

Hva må du passe på?

• Sørg for å bruke få snakkebobler – blir det for mange bør du heller lage en ny tegneserierute
• Ikke ha for mye tekst i snakkeboblene.
• Vis interaksjonen mellom mennesker og maskiner
• Sørg for å ha bilder som forteller en histore – ta nye hvis det blir nødvendig.

Har du prøvd å lage og bruke tegneseriescenarier til å kommunisere designideer? Hva er dine erfaringer?

Oppskriften er enkel

1. Lag prototypbasisen (en tom skjerm) på et stykke tykt papir.
2. Lag et snitt øverst i hele skjermens bredde (du må selvfølgelig spare på eventuelle navigasjonsknapper). Lag et tilsvarende snitt i nedre del.
   
3. Lag hele skjerminnholdet på en papirstrimle (tykt papir) med nesten samme bredde som snittene øverst og nederst på skjermen.
   
4. Papirstrimlen stikker du inn i snittene i prototypbasisen fra undersiden øverst og ned fra oversiden nederst.
   
5. Slik vises et utsnitt av skjerminnholdet i prototypen din.
   
6. Når brukeren vil scrolle ned eller opp i skjermbildet tar hun papirstrimmelen med fingeren og drar den opp eller ned (du kan eventuelt hjelpe til med å dra papirstrimlen opp eller ned slik at et nytt utsnitt av skjerminnholdet vises)
   
   
   

Slik kan du scrolle, selv med en papirprototyp. Det fungerer ikke bare på prototyper av mobiltelefoner. Også scrolling i applikasjoner på større skjermer kan løses med denne metoden.

Hvordan synes du det fungerer? Gi oss tilbakemeldinger!

Fra Smidig 2008, UGDD av Daniel Brolund (Agical AB)

Bildet viser en fantastisk slide fra årets smidig2008 konferanse av Daniel Brolund fra Agical AB.

Denne problemstillingen sliter mange med. Det å lage kode med smidige metoder som Scrum, bruke teknikker som BDD, continuous integration og continous deployment er ikke på noen måte en garanti for at det du lager blir brukervennlig. Scrum er en meget god gjennomføringsmetode som takler noen av de største problemene med IT prosjekter som f.eks. kommunikasjon. Men metoden er beviselig mangelfull i å sikre at selve produktet, og ikke bare koden har en stor verdi for den som skal utføre faktiske oppgaver på systemet.

Bob Martin sier at det smidige manifest mangler en femte linje: Craftmanship over crap. Interaksjonsdesigner og forfatter Alan Cooper har et bedre forslag for et tillegg til manifestet, som går på produktkvalitet:
“Responsible craftsmanship over features and functions.”
- While there is value in the latter, we value the former more.

Det er ikke en dum tanke. Det å måle kvalitet i grønne lys, fungerende kode, storypoints levert osv vil aldri bli en garanti for kvalitet. Som jeg sa i min lyntale på smidig2008 så er det utviklerne som har størst påvirkning på brukeropplevelsen og det er på tide at disse kloke menneskene retter sine blikk mot brukskvalitet – Det burde ikke lyse grønt før brukertesten er en positiv opplevelse.

Følg diskusjonen på Alan Coopers blog:
http://www.cooper.com/journal/2008/09/uncle_bob.html