Brukskvalitet

(Jeg holdt et innlegg om dette på XP meetup 2. februar. Jeg og Jon holdt også tidligere i år et kurs i regi av Steria der vi snakket om hvordan vi kan få til mer brukervennlige løsninger i smidige prosjekter. Et av emnene jeg tok opp da var hvordan vi kan organisere designere inn i smidige prosjekter.)

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