Posts Tagged ‘udviklingsproces’

Say-do Konflicten i arbejdet med brugervenlighed

mandag, november 30th, 2009

En blogpost hos Adaptive Path lægger op til flere forskellige diskussioner. Det primære er, at nogle begreber og forståelser indenfor design og User Experience, er ved at blive så almindelige, at nogle oplever det som et faresignal. Noget man skal være påpasselig overfor.

En af kommentarerne til dette indlæg nævner, at mange virksomheder taler om innovation og bruger-centreret tilgang i iterative designprocesser, hvor der skal tænkes ud af boksen (ja, måske kan jeg godt fornemme ,at det er noget vi hører igen og igen) – men at meget få, helhjertet, også har disse tilgange implementeret.

Jeg er enig. Men det er nok naturlig at smøre lidt rigeligt på. Tidligere har jeg gjort mig klog på, at “brugervenlighed” har sejret sig selv ihjel. Det er blevet et gratis, udhulet, helt overordnet og flertydigt begreb, noget alle forventer og fejlagtigt tror er implicit i alle digitale produkter. Men jeg tror også, at forholdet mellem det der siges i reklameøjemed og det er foregår i udviklingsprocessen, stikker dybere end som så.

Indenfor usability (og andre fagområder) taler man om say-do konflikter: At brugerne siger en ting, men gør en anden. Hvilket også er grunden til, at vi gerne vil se dem in action når vi brugervenligheds-tester. Det samme gør sig gældende når vi snakker om usability i udviklingsprocesser. Vi kan allesammen nikke og være enige. “Ja, naturligvis laver vi det brugervenligt”. Men når det kommer til stykket, så er det nemmere sagt end gjort. Af mange grunde.

En grund kunne være, at vi simpelthen ikke er vant til at lade et brugscentreret designprincip overskygge andre traditionelt fremherskende opfattelser af, hvad der er rigtigt og forkert – og som dermed styrer vores overordnede prioritering og beslutningsproces. Hvis vi er tekniske specialister, så forventer vi at være vidende om hvordan tingene laves bedst, ikke være flæbende fjolser, der hele tiden skal have de besværlige brugere til at kvalificere det for os. Hvis vi er projektledere, så vil vi tage hurtige og effektive beslutninger – eller hvad ved jeg. På den måde kræver det en samlet og eksplicit forståelse af et brugscentreret princip, før at alle designbeslutninger tages på et brugerkvalificeret grundlag. Og en sådan forståelse kommer ikke af sig selv…

Det kræver en hvis styrke som organisation – hvorfor det også er en sjældenhed – at være helt skarp på hvornår og hvorfor man laver usability, mens det er ligeså vigtigt at være skarp på hvor man ikke gør det og hvorfor ikke. Men hvis det ikke et tydeligt i et projekt, så er det næsten umuligt at håndtere en usability-proces kvalificeret og systematisk. Så falder de gode intentioner på stribe og vi fik alligevel ikke helt arbejdet med produktet som vi fik lovet hinanden og omverdenen.

Hvad kan vi lære at det? At vi skal gøre hinanden en tjeneste og blive meget præcise, når vi i vores projekter, taler om brugervenlighed eller andre lignende buzzwords. Vi skal tage diskussionen om hvad formålet er, hvilken værdi det skaber og hvordan det skal implementeres og følges til dørs.

Se, allerede der bliver det til en række begreber og tanker, som er nemme og sidde halvsløvt tilbage og nikke til. Ikke desto mindre.

Det er derfor det er svært. Det er derfor opgaven ikke er at sige, men at gøre. Og blive ved med at gøre.

Udviklere og usability: Skyld eller ansvar?

onsdag, september 2nd, 2009

En venlig person antydede forleden overfor mig, at han mente, at der indenfor usability, var en lidt kedeligt tendens til altid at skælde ud på “udviklere”. Det er rigtigt. Min forståelse er, at der i nogle situationer er meget god grund til denne kritik, selvom at man skal huske at den ikke er ‘personlig’, men snarere er et udtryk for en generel udfordring indenfor IT-udvikling. Men det er også spredehagl og derfor fejlplaceret kritik i mange tilfælde. Udviklere der interesserer sig for usability, er selvsagt lidt trætte af at høre og læse den slags.

Lad mig lige bruge et par linjer på at beskrive, hvorfor jeg selv mener at den situation er opstået. Mere overordnet går usability eller UX ud på at se på IT-udvikling med et brugs-centreret perspektiv. På et tidspunkt i udviklingsprocessen skal noget tankegods oversættes til mekanik. De der traditionelt ofte har skulle foretage denne oversættelse er udviklerne. De har gerne opgaven med at omsætte nogle krav, som kan være meget overordnede, til noget teknologi. De designer, foretager valg, beslutter. Det er i den proces de ofte ikke er kvalificerede til at – kvalificere. De har en anden faglig baggrund, kommer fra en anden uddannelsesmæssig kultur og er løsningsorienterede. De har som regel slet ikke direkte empirisk indblik i hvordan produktet skal bruges og har ikke mulighed for selv at kvalificere deres designvalg.

Men – og det er her jeg synes man burde ændre retorikken – er det nu også fair at give udviklerne det ansvar og dermed skylden for ikke at arbejde brugercentreret nok?

Nej, naturligvis ikke. Det skal de heller ikke umiddelbart, det er ikke deres opgave. På samme måde som jeg ikke skal bestemme hvordan en teknisk validering skal skrives eller bestemme hvordan databasen bedst normaliseres.

Skylden må i første omgang placeres hos ledelsen. Den ledelse, der ikke sikrer at der er kompetencer og ressourcer til rådighed, til at få kvalificeret designbeslutninger igennem hele udviklingsprocessen. Se bare på Usability Maturity Model. For den handler langt overvejende om at sikre, at de rigtige metoder, processer, ressourcer og kompetencer er til stede i organisationen.

Så usabilityfolk skal holde op med at skyde på pianisten, men i stedet skyde på barejeren.

Det ændrer dog ikke ved den udfordring der stadig eksisterer. Det ændrer heller ikke ved at usabilityfolket, til stadighed må arbejde på at sælge budskabet, til både udviklere og ledelse, uanset hvor træls det kan blive i længden (vi ved vi har ret?). Det ændrer heller ikke ved, at vi skal blive ved med at finde gode måder at gå fra idé og koncept til teknologi, uden at tabe brugerne og os selv på vejen.

Men alt det ved vi jo godt…

iOle

At bage – en kvalitets-kage

onsdag, maj 27th, 2009

Dette indlæg er primært et link til en anden artikel: “Follow the Recipe” på UXmatters.com. Er din tid knap, så stop med at læse her og læs der i stedet.

Mit take er, at artiklen arbejder med at forstå hvorfor vi skal have beskrevne processer for arbejdet med usability, hvorfor det giver mening at følge dem og – som er artiklens omdrejningspunkt – hvorfor man kunne tænkes at fravige disse processer. Det er nogle gode overvejelser, der sætter mine tanker på to spor.

1) De mest interessante begrundelser i artiklen, er efter min mening ikke mangel på ressourcer. Mere relevant tror jeg det er, at se på det bevidste valg (som også kan være på baggrund af mangel på ressourcer) eller at se på den manglende erfaring.  Jeg tror dog at det i endnu højere grad handler om det ubevidste valg (som trods alt også er en slags mangel på erfaring), et ubevidst valg der (ikke) fortages, fordi der ikke er forståelse for hvilken betydning processerne har og hvorfor den kvalitet der kommer ud af det er vigtig.

2) Og netop kvalitet synes jeg er et meget interessant begreb. Usability er en kvalitetsegenskab, men kvalitet er en svær og underlig størrelse. Jeg ved meget om usability som kvalitet, men ikke så meget om kvalitet som grundlæggende idé. Men umiddelbart tænker jeg at kvalitet er svært, fordi det er en samlet, tværgående størrelse, noget der både ligger hos den enkelte, men som også opstår af helheden. Det er noget der ikke opstår af sig selv, men som skal passes (selvom alt har en kvalitet). Det skal passes fra start til slut (og også bagefter..), med evaluering og justering undervejs. Det handler om styring, om motivation og alt muligt andet.

Så overordnet mener jeg vi skal lære at forstå kvaliteten. Vi skal forstå hvad den koster og hvad den er værd. Vi skal forstå hvordan den passes igennem en række processer og hvordan den enkelte bidrager til det.

OLe