Archive for maj, 2009

Genopfind ikke hjulet!

fredag, maj 29th, 2009

Det er enkelt og helt urimeligt sandt. Denne artikel fra UIE.com rammer hovedet på sømmet efter min mening: Lad være med at genopfinde funktionalitet, interaktion, designs, som andre har designet og forfinet en million gange før!

http://www.uie.com/articles/componentspatternsframeworks

Dele af den løsning du sidder og arbejder på lige nu, er allerede designet – muligvis meget bedre end du er igang med at designe den. Brug energien på at få den viden ind i projektet, i stedet for at etablere den selv (får du den forøvrigt forankret fornuftigt når du er færdig med den?).

We’re seeing that the best teams have a re-use strategy that they divide into three types of libraries: Patterns, Components, and Interaction Design Frameworks. These libraries give the team speed and efficiency, letting them leverage the rich history of things-implemented-before.

I couldn’t agree more!

Læs artiklen og vær enig, det er svært andet. Derefter: Implementer – uha, straks sværere. Men det giver om ikke andet god benzin til argumentationsmoteren.

Ohl.

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

Sig CISU-R til dit Projekt-ür (bedre titel søges…)

onsdag, maj 20th, 2009

Jeg har tidligere skrevet om ressourcer (dokumenter) til usability-kriterier. Mere præcist har jeg henvist til Common Industry Specification for Usability – Requirements – eller CISU-R. Ganske fortinligt dokument viser det sig (ved granskning). Faktisk understøtter det en af mine kæpheste (eller darlings (don’t kill it!)), nemlig det at opstille usability-mål for det projekt eller produkt man arbejder med. Idéen er helt rationel og logisk: Hvis man ikke sætter et mål for hvor brugbart noget er, så kan man heller ikke vurdere om man har opnået det niveau.

Jeg har gjort mig en del tanker og etableret mig en forståelse omkring brugen af usability-kriterier og -mål. En forståelse jeg så prædker, primært på IT-Universitetet: På samme måde som de fleste af mine andre mentale modeller, så ender formidlingen ofte i noget tre-punkts-form. Usability-kriterierne har jeg passet ind i en model med: Brugssituation (brugere, mål, brugskontekst), Usabilitymål (kvalitet) og Produkt (adgang til ressourcer og kompetencer). Den opstilling synes jeg er frugtbar. Grunden til, at jeg nævner den her er, at CISU-R præsenterer en anden og tilsvarende tre-punkts-liste, som på mange måder er relateret. I den indgår: Context of Use, Performance and Satisfaction Criteria og Test Method and Context for Test. De to opstillinger vil lidt det samme, jeg har blot taget teknologien mere direkte med, mens CISU-R holder lidt mere fast i sammenhængen mellem kriterier og test til vudering af deres opnåelse.

CISU-R er en ramme, en mængde informationer der skal tilvejebringes, en bunke beslutninger der skal tages. Dertil er dokumentet fyldt med eksempler og skabeloner, så det er også ret handlingsanvisende.

Uanset. Jeg synes CISU-R er superfedt, fordi det også passer ind i en problematik jeg gerne arbejder med: Hvad er det der mangler i udviklingsprojekter, for at sikre, at der bliver arbejdet seriøst, professionelt og kompetent med usability. Svaret ligger i CISU-R. Og det er: Specificering af usabilitykrav!

Det er ikke krav til brugergrænsefladen. Det er ikke funktionelle krav til interaktion (der måske, måske ikke er brugervenlig). Nej, det er specifikke usabilitykrav, som understøtter og komplimenterer de øvrige funktionelle, processuelle og kvalitetsorienterede krav.

Det er såre simpelt. I kan ikke arbejde med usability, hvis ikke I stiller krav til det. Det giver ikke mening at slås om ressourcer, testmetoder eller udviklingsproces, hvis ikke der er enighed om, at der skal opnås en bestemt kvalitet i brugen af produktet. Den kvalitet fordrer processen, metoderne og behovet for kompetencer – eller skulle det i bedste fald.

Jeg arbejder selv til daglig i en virksomhed som ikke direkte stiller krav til usability. Der stilles mange andre krav, hvoraf flere er relaterede. Men også derfor er arbejdsprocessen omkring håndtering af usability ikke fastlagt. Den er beskrevet, men bliver – som mange mange andre steder – hånderet lidt lemfældigt (og det er pænt sagt).

Det lækre ved CISU-R, er at den tager opgaven meget alvorligt, hvilket jeg også tror er måden gøre det på, i den moderne, dokumentations-fikserede, modenheds- og certificerings-fokuserede, styringsliderlige softwareudviklings-verden. Der henvises til ISO-standarder i flæng og det beskrives hvordan CISU-R passer ind i alle mulige seriøse  og gennemdokumenterede proces- og metode-beskrivelser.

Men igen. Kunsten er at få etableret usabilitymål i den organisation man indgår i. Som en del af den fælles strategi, som et eksplicit kvalitetsniveau produktet skal opnå.

Tilbage er kun at argumentere for værdien af denne proces (i rigtige penge). Det findes der med garanti også et godt, praksis-orienteret svar på derude…

Lad os komme igang med at specificere vore usability-krav.

Ohür

10 års jubilæum (IT-udvikling på social pension)

fredag, maj 15th, 2009

I år er det 10 år siden jeg blev færdig som Mediekoordinator (a’hva for en fisk?). I mellemtiden kom den uddannelse til at hedde Multimediedesigner og blev langt mere praksis-orienteret end den var for os. Vi rodede mest rundt i konceptudvikling, innovation og projektledelse, men vi fik da også leget med en masse computere. Vi lavede CD-rommer (kan du huske dem?) og multimedie – ja og hjemmesider med flaaaashj!

Sjovt nok synes den “nye” titel, Multimediekoordinator, at være lige så forældet som Mediekoordinator hurtigt blev. Multimedier, hvad er det? Det er jo en lækker fællesbetegnelse, men idag ville jeg vove den påstand, at det ville være nok at sige “web” eller “software”. Ok, der skal nok være en masse ind imellem, men faktum er at det ofte er i en af de to gryder vi IT-mennesker ender. Det jeg også prøver at sige er, at særligt indenfor usability er der to “skoler”. Hvis man vil (og det vil jeg da så lige nu), kan man på mange måder opdele usability-metoder, usability-relaterede fagområder, udviklingsprocesser – ja endda forståelse og perspektiver – i to.

Indenfor softwareudvikling, så er usability faktisk traditionelt en ret effektivitets-orienteret tilgang, der tester op mod en række metrikker (kvantitative optællinger). Indenfor er det begreb så begrænset (synes nogle) at man har valgt at kalde det User Experience. Men netop de to begreber og deres umiddelbare forskel vidner også om forskellige perspektiver på brugen af produktet.

Eyetracking er hot på web, jeg har endnu ikke hørt om det indenfor softwareudvikling. Det samme gælder A/B tests (man udsender løbende forskellige version til brugergrupper og sammenligner brugsdata). Empiriske data er faktisk populære på nettet, hvor analyse af serverstatitik og fornævnte eyetracking vinder frem – og efterhånden bliver tilgængeligt for flere. Google laver google.analytics og jeg ved at der arbejder på højtryk for at lave billige eyetrackere. På mange måder skaber nettets brugssituation og lidt uklare målgrupper, et behov for at få tjekket at skidtet også bruges og virker.

Sådan er traditionen ikke indenfor softwareudvikling. Tværtimod. Jeg oplever i min hverdag, at gode dyder fra usabilitiens højtid fra 90′erne, omkring at brugervenlighedsteste, bliver skubbet til siden af store præfabrikerede og teknisk superkomplekse løsninger, hvor brugergrænseflader kommer i en standard som man ikke skal rode for meget ved. Brugervenligheden er blevet standard, synes nogle at mene (derfor kan de aflyse designfasen). Vi andre synes stadig, at der skal arbejdes for sagen.

Jeg oplever ofte projektledere og usabilitykompetencer, derude i softwarebranchen, der klager deres nød, fordi de kreative designprocesser og forståelsen for kvalitet i brugen, bliver tromlet af alle mulige andre prioriteter. Så usability har reelt aldrig førsteprioritet, der er langt til den strategisk brugercentrerede virksomhed (UMM level E).

Så måske har brugervenligheden i Jakob Nielsens navn vundet på nettet (læs: Sejret sig selv ihjel), men den erkendelse eller forståelse, siver kun meget langsomt ned i softwareudviklingen.

Hvilket bringer mig tilbage til de ti år der er gået, siden jeg blev mediekoordinator. Dengang tænkte vi ikke på usability overhovedet (jeg var med til designe en app der havde et tastatur hvor tasternes rækkefølge hed “abcdefg….osv”). Vi havde meget mere travlt med koncepterne og teknologien. Den tankegang vi grundlagde dengang sidder stadig dybt i mange af os.

Så vi nærmer os en ubehagelig konklusion:

Rigtigt mange steder er forståelsen af hvordan moderne software udvikles = forældet!

For den er udtryk for en über-specialiseret, teknologi-fikseret og ingenør-agtig forståelse. Ikke på en helhedsorienteret og strategisk funderet kvalitetsforståelse – fx for hvordan produktet bruges, når det er afleveret til kunde/marked. Det kan godt være ledelsen sidder med den tilgang (Don’t bet on it), men den er ikke forankret i medarbejderne.

Jeg tror personligt vi er nået til en situation hvor mange projektdeltagere tænker – “Brugervenlighed er vigtigt, det ved vi godt, vi ved bare ikke hvordan vi arbejder med det”.

De ti år er gået. Vi tales ved om ti år…
Til den tid er argumenterne de samme, udfordringerne de samme!

Giv ikke op

Ole G.
Mediekoordinathoor