Användarna ska inte designa systemet!

Ibland börjar man skriva ett blogginlägg och så kommer man av sej. Så var det i maj i år när tiden inte riktigt räckte till. Idag fick rubriken ny fart – i dagens CS fanns en artikel med rubriken Innovation måste styras av kundens behov – och det är inte alltid samma sak som det de efterfrågar.

Man kan tycka att det är en självklarhet, men uppenbarligen är det inte det – Bengt Karlöf kan i alla fall skriva en bok om det, i förhoppning att den ska finna en marknad.

Min personliga erfarenhet är i alla fall att man inte ska låta användarna designa systemet. Självklart ska deras behov färga designarbetet men folk med verksamhets- och användbarhetsfokus måste tolka och prioritera behoven – ställa dem i relation till övergripande mål som exempelvis behovet av att förändra ett företags kultur och arbetssätt.

Första gången jag arbetade på det viset var 1997, men fortafarande ses det som kontroversiellt. Och inte minst så sedan beställarna började förstå att man ska blanda in användarna. Och – det ska man. Men vid rätt tillfällen, och på rätt sätt.

Att användarna vet hur de helst vill söka information eller vilken struktur eller namngivning som är mest logisk för just dem betyder inte att de vet VAD systemet ska göra.

Så fick jag det sagt, också

Idealvärld eller pragmatism. En efterkommentar.

Del 3 dröjde lite – den fysiska verkligheten trängde sig på
För de som inte läst del 1 & 2 rekommenderas att göra det innan man läser det följande.

Till syvende og sidst är vi som användbarhetsexperter beroende av de förutsättningar vi ges av beställare och projektledare.
Visst kan vi påverka en del, men ibland begränsas vi av verkligheten.

Exempel: ”Vi har en första release om 8 veckor. Användbarhet är viktigt för oss, kan du hjälpa till”.
Applikationen är då i princip färdig, den ska bara testas och rättas. Alternativt man har verkligen tänkt sig att en fullständig tjänst ska specas, designas, byggas, testas och implementeras på den tiden.

Orsakerna till dessa två scenarios skiljer sig något.

I det första fallet har någon kommit in sent i projektet och upptäckt att användargränssnittet ser för jävligt ut. Eller så har någon gått på en kort kurs och fått idéer. Det är också vanligt förekommande att man upplever sig ha specat hela applikationen/tjänsten/webben och bara vill ha feedback på detaljer när det i verkligheten är så att underlaget mer är att betrakta som en idé.

I det andra fallet har man fått för sig att IT-relaterade konsulter ska hållas kort, annars springer kostnaderna i väg. Så man lägger en stenhård projektplan och försöker kontrollera utförarna i minsta detalj.

I bägge fallen handlar det om god vilja och goda intentioner som slår fel.

Som projektledare eller beställare måste man försöka förstå att standardsystem INTE, som leverantörerna försöker påskina, innebär att det är ”plug’n'play”. För det är det inte. Jag har hittills inte sett ett standardsystem som inte behöver konfigureras noga, som inte kräver omfattande insatser. I vissa fall finns ett oändligt antal alternativa valmöjligheter som var och en påverkar hur resten av systemet kommer bete sig. I andra fall finns inga valmöjligheter alls utan verksamhet och organisation måste anpassa sig till hur systemet fungerar.

Och det gäller att planera projektet därefter. Annars kommer -

a) projektet dra över tidsmässigt
b) projektet kosta minst dubbelt så mycket som budgeterat
c) resultatet trots a & b inte motsvara förväntningarna

Och i utgångsläget handlar det förstås om att verkligen förstå det standardsystem man köper. Och den hjälpen kommer man i ärlighetens namn inte få från leverantören. För de säger bara att deras system kan allt. Och det kan det. Om man programmerar om alltihopa. Men det är det ingen som talar om.