Varning för interaktionsdesign

Johan Berndtsson

Varning_liten Sedan jag startade mitt första företag i användbarhetsbranschen 1994 har jag stött på otaliga projekt där en förändring av arbetssätt, från textbaserade krav till ett systematiskt arbete med interaktionsdesign, har lett till dramatiskt minskade intäkter.

Det är sant. Jag svär. Är du tveksam? Inte då.

Textbaserade krav har den fördelen att de är svåra att tolka, vilket gör att alla som läser dem får sin egen bild av hur systemet kommer att se ut och fungera. I praktiken innebär det massor av ändringar både under projektets gång, och även i det uppföljande projektet (eller i "den aktiva förvaltning") som syftar till att fixa till de största bristerna.

Eftersom de flesta systembyggare tar betalt på löpande räkning, åtminstone för tilläggsbeställningar, så är detta ett fantastiskt lönsamt upplägg. Projektets budget överskrids så gott som alltid, och pengarna hamnar i systembyggarens fickor.

Att då införa ett arbetssätt som skulle leda till att kunden redan innan själva systembyggandet påbörjas vet hur systemet kommer att se ut och fungera vore ju komplett vansinne.

Genom att visuellt beskriva exakt hur systemet skall se ut och fungera innan man drar igång skulle värdet av varje affär minska dramatiskt, och systembyggarens intäkter därmed minska i motsvarande utsträckning.

Alltså. Några råd till er som bygger system:

  • Undvik till varje pris att arbeta med interaktionsdesign!
  • Om du har egen personal som är utbildad inom området, se till att de inte kommer fram i projekten, lyft istället fram vältaliga tekniker med vidlyftiga visioner som kan skapa ett begär hos kunden utan att konkret behöva visa exakt hur detta kommer att ta sig uttryck i kundens system.
  • Avfärda alla förslag om att ta fram detaljerade beskrivningar över hur systemet kommer att se ut och fungera som att det "bara handlar om att rita några bilder".
  • Om, bevare mig väl, någon kund varit så förslagen att han inkluderar en interaktionsdesign i beställningsunderlaget, stryk då kunden från din lista. Den kunden kommer aldrig att bli lika lönsam igen.

/Johan Berndtsson

PS. Om du trots allt tycker att det verkar intressant att arbeta med interaktionsdesign, skicka ett mail, så lovar jag att se till att du får professionell hjälp. DS.

Lämna en kommentar

4 kommentarer

  • Henrik Artman

    Hej, Två kommentarer: (1) även om jag principiellt helt håller med om att maktordningen och den ekonomiska strukturen inom IT-industrin så vill jag ändå säga att vi inte får stigmatisera alla de individer som seriöst och med övertygat sinne arbetar inom IT-sektorn. Att "Janne" på konsultfirma X medvetet skulle sitta och försöka försinka eller skapa kalla krav utan att se till kundens bästa är en hård dom. Problemet är mer komplext det handlar å ena sidan om en tradition där avändbarhet/interaktionsdesign ses som en del av problemlösning och konstruktion, snarare problemanalys och idéskapande. Det handlar om att man överlämpar ansvar - och vad ska då en stackars "Janne" utan kunskaper i användbarhet, användarcentrerad design, interaktionsdesign etc. göra. Det handlar om att användbarhet inte har ett centrum utan genomsyrar mer eller mindre alla aktiviteter och att man riskerar få ett delat ansvar (=inget ansvar). Det handlar om att beställarorganisationer förlitar sig på teknik och ser teknik som lösning på kärnprocesser istället för stödprocesser (hur många utbildningar inom MDI läser grundligt verksamhetsteori??). Det handlar om att man sällan har klart för sig vilka effekter i organisationen man vill uppnå - och än värre aldrig mäter dem. Kan du tänka dig att ett företag som skulle ändra "tvättningen av flaskor" inte alls skulle mäta om det nya sättet att tvätta flaskor blev mer effektivt än tidigare sätt? Tänk om IT-sektorn kunde lära oss av dels arkitekter och deras sätt att arbete, men även processindustrin och deras sätt att våga mäta effekter. Eller tänk om beställarorganisationer faktiskt ställde sådana rigorösa krav på verksamhetsstödjande IT som man gör på automatiserade processer. Allvarligast av allt: Det handlar om en förlegad och i allra högsta grad traditionstyngd syn på utbildning och ingenjörskonst. Utbildningen inom IT borde radikalt reformeras från grunden, för idag utbildar vi mer problemlösare än problemanalytiker och merparten av alla system som byggs byggs på felaktiga grunder det är alltså problemanalysen som ofta fallerar snarare är problemanalysen. Det är inte sällan som det är beställarorganisationen som står för problemanalysen och är den gjord från önsketänkande så blir det som det blir. Sedan är det få som reflekterar över problemanalysen och skapar huvudlöst - på inuse skulle ni antagligen säga att man förlorar sikten på effekterna och fokuserar på problemrymden. Men det är inte "Jannes" fel - det är en traditionstyngd praktik. Låt oss ändra hela systemet från grunden. Men hur? Det skulle krävas en revolution... (2) Erik Markensten diskuterar just fördelen med att arbeta med interaktionsdesign innan man beställer ett system i sin utmärkta lic-avhandling (http://www.nada.kth.se/~artman/Doktorand_texter/ErikM.pdf). Erik menar att man just i detta beställningsarbete behöver interaktionsdesigners/användbarhetsmänniskor antingen som konsulter eller internt (såsom Kronofogden organiserat sitt arbete genom att anställa Fredrik Andersson). Även om jag tror att detta utmärkta sätt att arbeta är mer eller mindre idealt, så tror jag också att många beställarorganisationer själva kan arbeta med interaktionsdesign på ett bra sätt åtminstone har min forskning visat på exempel på organisationer som inte alls hade användbarhetskompetens på ett bra sätt arbetade med användbarhet (se . Men som sagt Johan du har rätt i att IT-utveckling kan bli mycket effektivare genom tidigt interaktionsarbete och vettiga effektmätningsmetoder. Men varför blev "användbarhet" en bransch som var tvungen att uppfinna detta på nytt? Det är sådant jag funderar på... Nåväl detta var några snabba reflektioner - tack för alla era intressanta reflektioner på Inuseful! /Henrik

  • eric idebro

    "Genom att visuellt beskriva EXAKT (min versalisering) hur systemet skall se ut och fungera innan man drar igång..." detta låter misstänkt likt en gammal hederlig vattenfallsmetod. Menar du vekrligen att man exakt ska beskriva hur saker och ting ska se ut och fungera? Innebär itne det att saker man missat, och det gör man alltid, inte ska tas hänsyn till?

  • Johan Berndtsson

    Henrik. Tack för som vanligt upplysta kommentarer. :-) Min avsikt är inte att utmåla "Janne" som en bov, utan endast att poängtera det sorgliga i att de ersättningsmodeller som existerar i systemutvecklingsbranschen får negativa effekter för de beställare som inte själva förser sig med interaktionsdesignskompetens. I de allra flesta fall är, precis som du säger, "Janne" inte medveten om detta. Han agerar och navigerar bara i ett socialat och affärsmässigt system som uppmuntrar till ett visst beteende. En viktig åtgärd för att få till stånd en förändring är att bidra till att fler interaktionsdesigners börjar arbeta hos eller åt beställare istället för hos eller åt leverantörer. Eric. Nej. Ursäkta ett slarvigt, eller möjligen provicerande ordval ("exakt"). Poängen är att man idag ofta väljer att inte beskriva systemet, så som vi ser det just nu, bör se ut och fungera, eftersom man vet att "det ändå blir ändringar". Klart att bilden av hur systemet bör se ut och fungera förändras och förfinas med tiden, men genom att så tidigt som möjligt vara tidig med att beskriva systemet så kan man fånga de största bristerna redan på papper, vilket är mycket billigare än att vänta tills programkoden är skriven. :-) /Johan

  • eric idebro

    Johan: check! Då håller jag med i det du säger!