Kategoriarkiv: Metod

Testa till döds?

Beslut ska baseras på fakta, inte på förutfattade meningar, och därför gillar jag trenden just nu där allt mer studier av olika slag görs. Men. Man måste också förstå NÄR det är lämpligt att genomföra en studie och när man inte ska göra det… och ibland kanske man inte ska använda den metod man tänkt sig.

Precis som med resten av det samhälle vi just nu har så är det för många bara siffrorna som räknas – allt ska vara hypereffektivt och människor hinner inte ens andas och tänka efter, utom när det gäller att rädda sitt eget skinn. Så även inom User Experience, där klick-statistik och kvantitativa användningstester fått stort genomslag medan mer explorativa och kvalitativa metoder inte alls får samma fokus, trots allt prat om Service Design.

Jag brukar säga att människan är herre på täppan på denhär planeten av en anledning – nämligen vår enastående förmåga att anpassa oss. Måste vi använda dåliga eller undermåliga verktyg så anpassar vi oss efter det. När vi sedan får ändamålsenliga verktyg är motståndet först mycket stort, innan vi vänjer oss vid det nya sättet med.

Är det då alltid lämpligt att mäta mitt i förändring? Eller ska man kanske låta förändringskurvan slå i botten innan man testar om ändringen fick önskad effekt? För mig är det enbart en retoriskt fråga. Har man med återkommande användare att göra, som exempelvis på intranät och på många av de tjänster som finns där ute, som Facebook, Tumblr och din internetbank, så litar man alltid till invanda mönster/etablerade beteenden. Ändra, och användaren upplever att allt är helt galet. Testa just då och du kommer få ändra tillbaka till det gamla.

Jag har testat intranät där folk sitter med sökvägar nedskrivna på PostIt-lappar. När man sedan efter noggranna kortsorteringar ändrar strukturen blir användarna tokiga. PostIt-lapparna fungerar inte längre! Då ska det till en modig person som äger pengarna och makten. Annars beställs snabbt en återgång till det gamla… (och det är då man måste ha en bra strategi i botten, där alla beslut som fattas bottnar i verksamhetens affärsplan eller regeringsuppdrag, men det är ett ämne för ett annat inlägg!)

Därför tycker jag att det känns skönt att någon tar bladet från munnen och säger det jag också tycker, nämligen att kvantitativa inkrementella tester visserligen har en viktig plats men att den platsen både är väldigt specifik och behöver kompletteras med kvalitativa metoder. För ofta när man testar, och låter ett oreflekterat testresultat styra – då kanske den egentliga effekten är att man cementerar dåliga men väl inlärda mönster?

Läs och fundera. Hur tycker du?

Threats of A/B tests and UX research: adoption time and incrementalism (på engelska, hoppar ut till annan plats).

Strategins olidliga svårighet

Strategi. Smaka på ordet. Det finns överallt. I yrkestitlar, i uppdragsbeskrivningar. Sökstrategier, strategi för sociala kanaler. Publiceringsstrategi. Kommunikationsstrategi. Webbstrategi. IT-strategi. Strategi för sociala medier.

Och då har jag inte ens närmat mej alla de strategier som finns utanför det digitala rummet.

Jag får ofta känslan av att man smetar på orden ”strategi” och ”strateg” för att ge det man gör högre status än det har.

Frågan är vad av allt det där som EGENTLIGEN är strategi och vad som är taktiska val respektive daglig/operativ verksamhet.

För att kunna svara på den frågan behöver man först reda ut begreppen –

Begreppet strategi definieras ofta utifrån en militär terminologi och för många är det besvärligt. Men det behöver det inte vara.  Enklast är det att titta på detta med hjälp av ett tankeexperiment –

Du sitter på en tillståndsgivande och inspekterande myndighet. Är syftet med myndigheten då att ge (och dra in) tillstånd, eller är tillståndsgivandet i sig ett sätt att exempelvis säkerställa en långsiktigt hållbar miljö?

Myndighetens existens är beslutad på en strategisk nivå, som ett av kanske flera sätt att säkerställa långsiktigt hållbar hantering av miljöfarliga ämnen, där man sett att ett sätt att uppnå giftfri miljö är att kontrollera användningen av miljöfarliga ämnen. Att man gör det genom tillståndsgivande är den taktiska nivån. Den dagliga verksamheten är sedan operativ – att göra jobbet.

I praktiken är det därför ganska sällan man i sin dagliga verksamhet arbetar affärsstrategiskt eller verksamhetsstrategiskt. Snarare arbetar man strategiskt inom ramen för det begränsade uppdraget med olika val och åtgärder vars syfte är att möta målet (bättre miljö), inom ramen för myndighetens uppdrag (tillståndsgivande och kontroll). Den typen av frågeställningar är ledningsfrågor och diskussion och val görs ofta utan att resten av organisationen är inblandad. Inom ramen för detta gör sedan olika delar av verksamheten taktiska val som sedan omsätts i den operativa verksamheten.

Som en del av taktiken kan man behöva utforma specifika strategier för olika delar av verksamheten, där dessa mer taktiska, underordnade, strategier beskriver hur man ska kunna bidra till att på bästa sätt realisera den övergripande strategin. Det är oftast de underordnade strategierna man som anställd kommer i kontakt med.

Ofta är det lite mer komplext, dock, och med tanke på hur förvirrat det är med alla dessa strategier och vad begreppet ”strateg” egentligen motsvarar för kompetens och förmåga tycker i alla fall jag att det kan finnas anledning att definiera någon form av baskriterier för vad en strategi är och vad som krävs för att man ska kunna kalla sig strateg –

Tydlig koppling till ett mål | En strategi är per definition något som ska bidra med att ett mål uppfylls eller uppnås. Oftast bygger strategin på en bedömning av var man är idag, var man vill vara, och hur förutsättningarna för att nå dit ser ut. Själva strategin är beskrivningen av hur man ska möta målet.

Detta är inte alltid enkelt eftersom det kräver att man vågar utgå från antaganden om både framtiden och vägen dit (se tex Why smart people struggle with strategy, av Roger Martin, som kanske iofs mer utgår från ett bönräknarmekaniskt sätt att se ”smart” men ändå har en poäng).

Metod, inte aktiviteter | En strategi är en beskriven metod för att nå dit man vill.

Exempelvis så kan en IT-strategi vara att utgå från ett plattformsparadigm (.NET, Java…), en en- eller flerleverantörsstrategi, med exempelvis Bring Your Own Device i slutanvändarledet, och så vidare. Den beskriver inte exakt vilka protokoll och versioner som ska följas – det är den taktiska eller operativa nivån, utan sätter ramarna inom vilka man ska verka.

På samma sätt beskriver en kommunikationsstrategi hur intressentgrupp A respektive B och C ska nås, på bästa sätt – människa till människa, traditionella medier, events, digitala kanaler. Vilka behov och därmed intressenter exempelvis en webbplats ska möta är en del av kommunikationsstrategin – ”intressentgrupp A och B behöver styras bort från telefonsupporten, de ska få hjälp via webben istället”. Strategin beskriver inte exakt HUR det ska gå till, men ATT det ska ske.

Affärs/verksamhetsstrategin slutligen är modern till dem alla. Affärsstrategin beskriver vilka marknader man måste nå och hur, hur verksamheten måste se ut för att det ska vara möjligt, och så vidare, och verksamhetsstrategin beskriver på samma sätt hur man ska uppfylla sitt uppdrag. Alla andra strategier i en verksamhet är underordnade affärsstrategin, som ofta inte heter ”strategi” utan affärs- respektive verksamhetsplan.

Medveten | En av de allra viktigaste kriterierna är att strategin är ett medvetet beslut. Det finns gott om instinktiva strategier, bland dem en uppsjö av överlevnadsstrategier, men för att din strategi för digitala kanaler eller din IT-strategi ska kvalificera sig som strategi krävs att den bygger på medvetna beslut och ställningstaganden grundade på en medveten analys av en situation.

Vem är då strateg? | Den som driver och genomför arbetet med att ta fram en strategi – den roll som har det på sitt bord – är strateg. För att kunna göra det jobbet, oavsett om man ansvarar för en stödfunktion som IT, kommunikation eller HR eller om man står för en verksamhetsgren, behöver man ha god förståelse för verksamheten i form av omvärld, omständigheterna för det vardagliga arbetet, affärsidé eller uppdrag, och affärs- eller verksamhetsstrategin. För att kunna ha det behöver man ha god analysförmåga och hög abstraktionsförmåga, relativt ämnet, och kunna se makroperspektivet snarare än fokusera på enskilda lösningar.

Att man behöver vara modig och kreativ säger sig självt.

Det är möjligt att till titeln vara exempelvis IT-strateg utan att ha koll på ovanstående men sannolikheten att man väljer rätt strategi givet mål, behov och förutsättningar är ganska liten.

Baserat på detta resonemang, som för all del inte försöker vara heltäckande – detta är trots allt bara ett blogginlägg! – kan man snabbt se att en hel del saker som idag ofta kallas strategi egentligen är taktiska val eller operativ verksamhet.

Exempelvis kan man ha en sökstrategi som definierar vad användarna ska kunna hitta och hur det övergripande ska gå till, exempelvis kan man ha en Enterprise Search-strategi eller en mer segmenterad strategi. Men valet av sökmotor/er är taktiskt och tweakandet av sökfunktionen är operativt verksamhet.

Valet att ha en webbplats eller app är en del av en kommunikations-, marknads- eller HR/rekryteringsstrategi, kopplad till affärsstrategin/affärsplanen (eller så är den affärstrategin, tex om man är en online-butik eller -tjänst). Men plattformsval, innehållsval, designval är alla taktiska, medan själva implementeringsprojektet, och den löpande förvaltningen, är operativ verksamhet.

Oavsett typ av strategi måste den referera till verksamhetens övergripande mål och strategi, dvs. affärsplanen eller verksamhetsplanen, instruktionen eller direktivet.

Har ”strategin” inte de kvaliteterna, då kanske det är a) läge att fundera över om det överhuvudtaget är relevant med en strategi – det kanske mer är en policy (taktiskt verktyg) eller instruktion (stöd i operativ verksamhet)? – eller b) fila lite till på arbetet, så att strategin kan bli det framåtriktade verktyg det behöver vara 🙂

Är du en målgrupp, lilla vän?

Nu och igen dyker begreppet ”målgrupper” upp. Vi ska rikta oss till målgrupperna, vi ska förstå målgrupperna, vi ska undvika att ha ett inifrån-och-ut-perspektiv. Det är i all välmening som det dyker upp i Webbriktlinjerna, i Användningsforums Designprinciper för offentliga digitala tjänster, i anbudsförfrågningar och i metodbeskrivningar.

Ordet målgrupper har vi lånat från kommunikationsteorin och marknadsföringsteorin och innebär ett passivt avsändare-mottagare-förhållande. Det bygger på att jag, som är ägare och avsändare, ska anpassa min information så att mottagaren klarar av att ta emot den på bästa sätt.

Så långt gott och väl. Att vi ska informera på mottagarens villkor kan inte nog understrykas. Det verkliga problemet uppstår när man försöker klämma in interna handläggare, webbplatsens eller tjänstens ägare, och så vidare, i målgruppsmodellen. För dessa grupper är inte målgrupper. De är intressenter.

Intressenter har lika typer av relationer både till varandra och till tjänsten. De har olika krav och olika behov. Den stora skillnaden mellan målgrupp och intressent är att målgruppsbegreppet är passivt medan intressentbegreppet signalerar delaktighet och aktivitet – modellen är tredimensionell och rymmer många olika beroenden och relationer; ta och ge.

Så ser sig exempelvis väldigt sällan kommunstyrelsen, eller koncernens ledningsgrupp, sig själva som målgrupp för varesig intranätet eller den externa webbplatsen. Men – de är intressenter för det är de som äger både nyttan och pengarna och deras intressen behöver också tas om hand.

Personer som söker jobb, som ska ansöka om dagisplats, som vill ta reda på sina rättigheter, som vill veta saker om ett pågående byggprojekt eller vill köpa en semesterresa. Personer som ska handlägga ansökningar, personer som ska ansvara för att informationen är korrekt. Aktieägare. Medborgare. Massor av människor med olika roller och intressen.

Är löneadministratörer en målgrupp för HR-systemet eller är det en intressentgrupp som också är användare?

Stänger man in alla dessa människor i målgruppsmodellen har man gjort världen och möjligheterna att förstå den liten. Särskilt om man arbetar i ett sammanhang där delaktighet och samverkan står högt på dagordningen. Vilket det borde göra i hela den offentliga sektorn.

Det är dags att börja fundera på vad orden och begreppen vi använder egentligen betyder. Och jag, jag använder bara målgruppsbegreppet när det handlar om klassisk information en-till-många. När det är vi och många tillsammans, när vi måste ta in flera perspektiv för att uppnå en balanserad helhet. Då är det intressenter som gäller.

Om man frågar mej.

(Man gör också hela UX-begreppet en otjänst när man låser sig i målgruppsbegreppet eftersom man fråntar sig själv en begreppsmodell som ger en möjligheten att bli verksamhetsstrategisk – något jag respekterar att inte alla vill men då får man lov att acceptera att man får arbeta på den taktiska nivån. Strategin – tankarna om resan, vägen och målet – tillhör då någon annan.)

Enkätens vara

I vintras skrev Internet World:s Magnus Höij att han tyckte att det var dags att döda webbenkäten. Vid en första anblick är det svårt att inte hålla med – för vem är INTE irriterad på alla dessa enkäter som dyker upp, i tid och otid?

Jag tror att en majoritet av alla som arbetar med användarupplevelsen står bakom tanken att svaret på ens frågor inte står att finna i intressenternas – användare, ägare, kunder, anställda… – egna åsikter och idéer om hur saker och ting borde fungera; istället ska man observera beteenden och dra slutsatser. Man betraktar och lär, får idéer, planterar dem, och ser vad som händer.

Ett sätt att betrakta användande på är att samla in statistik. Det är en väldigt populär metod, med rötterna djupt i ett ekonomistiskt tänkande. Ni vet – ”man kan bara styra det man kan mäta”. Följaktligen är besöksstatistik är en av de metoder som Höij pekar på som ersättning för dedär elektroniska formulären vi antingen klickar bort eller, som han påpekar, ljuger i när vi berättar om oss själva.

Men som i så många andra fall är inte frågan om en metod eller ett verktyg alltid är bra eller dåligt. Istället handlar det om hur, när och varför man använder den.

Enkäten som sådan är ett kvantitativt verktyg. Det betyder att man med fördel använder det för att samla in kvantitativa data.

Även besöks- och sökstatistik är ett kvantitativt verktyg. Det betyder att du egentligen inte vet varför besökarna väljer att göra som de gör – du bara ser ATT de gör.

Att de båda är kvantitativa verktyg betyder inte att de gör samma saker; att de är mot varandra utbytbara. Nej, frågan är istället en helt annan, och kanske mer besvärlig, fråga, nämligen – VARFÖR mäter du? VAD vill du uppnå? VAD vill du styra?

Ska man kunna svara på de frågorna behöver man ha en strategi; för att kunna ha en strategi måste man ha en vision. Vill man kunna mäta om de taktiska åtgärder man implementerar har önskvärd effekt måste man definiera målens mätpunkter. Vilka mätpunkter och mätmetoder man väljer påverkar resultatet.

Många strävar efter att reducera antalet mätpunkter. Ett reducerat mätande resulterar dock i en reducerad bild – ungefär som när låg bandbredd gör att bilden på den livestreamade fotbollsmatchen inte riktigt går att följa; man måste helt enkelt extrapolera från de data man har och ju färre punkter med tillförlitliga data, desto bredare blir gissningarna.

Samtidigt är det opraktiskt att alltid se hela bilden – det tar för lång tid att bearbeta datat. Istället måste man välja ett balanserat mellanting där vare sig dataförlust eller tidsåtgång och kostnad blir för stora.

Bäst blir resultatet om man har ett antal olika typer av sätt att få in information. Själv använder jag exempelvis ibland enkäten som ett sätt att ge en kvantitativ dimension åt något som framkommit i djupintervjuer, särskilt om uppdraget är sånt att olika typer av observationsbaserade metoder inte är praktiskt möjliga att använda. Ett antal utvalda demografiska data att korsreferera mot samt grundfrågan och man är uppe i maxnivån för acceptabelt antal frågor, dvs 5-7. (Taket finns av två skäl – dels vill du ha många svar, vilket betyder att enkäten måste vara så smärtfri som möjligt för respondenten, dels ökar svårigheten att tolka svaren logaritmiskt med antalet frågor du ställer.) Resultatet är verifierandet (eller inte) av en hypotes.

Nyckeln är att veta exakt vad man vill ha reda på. Alltså raka motsatsen mot de allmänt hållna standardenkäter vi bombarderas med. Och som alltså även jag vill bli av med.

Systemeffekter och krav – Varför fanns det ingen mjölk?

Häromdagen var jag inne i en mindre livsmedelsbutik för att handla lite. Det var en måndag runt lunchtid och mjölkdisken var helt ren sånär som på några få paket. Nåja jag fick i alla fall lite mjölk och nämnde det för kassörskan. Hon kunde inte dölja sin frustration över att mejeriet trots påtalande och försök att öka på beställningarna inte levererade tillräckligt mycket.

Det hela verkade bottna i ett smart beställningssystem som varje dag vid en viss tidpunkt stämde av saldot och därefter drog slutsatser kring hur butikens omsättning resten av helgen skulle se ut. Problemet är bara sa kassörskan att det är senare framåt fredag eftermiddag den riktiga veckoruschen kommer till den här butiken, dvs. man har en i allmänhet oproportionerligt stor omsättning under helgen vilket lösningen verkar ha svårt att kompensera för.

Det måste vara besvärligt för de enskilda affärerna att känna till behov men ha ett system som kör över intuition och kunskap kring de specifika förutsättningarna. I grund och botten handlar detta om ett intressentperspektiv där leverantören drar fördelarna på en mer övergripande nivå men där enskilda butiker kommer i kläm. Det vill säga för leverantören kan det här angreppssättet räknas hem men vissa av mejeriets kunder blir lidande och i slutändan påverkas jag som slutkund.

Så effekten blev att jag fick inte kunde köpa den mjölk jag ville ha samt att butiken och leverantören förlorade intäkten. Vem fick dessutom kommentarerna från kunderna, de som orsakade problematiken eller butiken?

Att förstå, identifiera och ta tillvara relevanta intressenters behov och lösningens konsekvenser i drift är ett mycket viktigt område där man i  många fall inte lägger nog med tid resurser. Med rätt perspektiv såsom det vi erbjuder inom UX-området kan risken för liknande systemeffekter minimeras.

Menyn till höger eller vänster? Tänk själv!

Jag hade tänkt skriva ett inlägg om hur man kan se en trend där det dominerande navigeringsparadigmet vänsternavigering – något jag länge stångat skallen blodig mot – har fått ge vika för horisontella och högerställda navigeringar. Men så trillade jag över ett gammalt utkast som aldrig blev något inlägg. Det hade inspirerats av en av Jakob Nielsens Alertboxar, denna gång med rubriken ”Horizontal Attention Leans Left”, och som vanligt hade jag blivit lite arg.

Två saker retade mej. För det första – den bristande argumentationen. När de enda argument man har är ”alla gör så” och ”alla har alltid gjort så” så har man inget argument.

Lyssna själv. ”Alla andra klär sej i blått så då är det så man ska göra” kanske inte känns så illa men ”alla andra retar Johan så då måste det vara OK” borde tända varningslampor.

Om alla alltid hade gjort som man alltid hade gjort skulle jorden fortfarande vara platt, solen snurra runt jorden och ingen skulle ha en aning om att smittsamma sjukdomar orsakas av virus eller bakterieinfektioner. Att ifrågasätta och att bygga sina argument på fakta driver oss framåt. Och det är bra.

För det andra – Nielsen har en unik ställning i branschen. När han talar lyssnar folk, okritiskt. Effekterna av hans råd påverkar många användare, beställare och utövare, världen över. Det gör att han har ett särskilt ansvar för det han säger. När han gång på gång (senast i Alertboxen ”Kindle Fire Usability Findings”) basunerar ut sina egna personliga åsikter som om de vore sanningar gjutna i betong visar han att han inte tar det ansvaret.

Så kommer jag då in på den spaning jag ursprungligen hade tänkt mej skriva idag. Från att ha varit den dominanta modellen för navigering oavsett tjänstens syfte kan man se allt fler webbplatser som frångår vänsternavigering, antingen helt eller delvis. Befriande. Jag är verkligen inte anhängare till teorin om ”one size fits all”. Tvärtom bör man göra en bedömning där ägarens syfte och besökarens mål vägs in, innan man fattar några beslut i den vägen.

Att paradigmet nu bryts tolkar jag som att allt fler börjar titta på ändamål, effekt och nytta, och på att branschen professionaliserats – alltihopa bra saker.

Inte en dag för tidigt.

En av mina starkaste invändningar mot genomgående vänsternavigering stärks av utfallet av eyetracking-tester. Med tanke på att resultaten alltid anses STYRKA placering av navigering till vänster är det intressant i sej, eftersom det pekar på hur svårt det är att tolka den insamlade datan (vilket i sej tyder på att de flesta tester är dåligt sammansatta).

I vilket fall som helst – majoriteten av alla eyetracking-tester visar att användarens fokus är centrerat kring den övre vänstra kvartilen, samt i gränslandet mellan de två övre kvartilerna. Om det beror på att alla de testade sajterna hade sin mest intressanta information där eller inte är svårt att avgöra. Men när andra säger att just på grund av att fokus ligger där det gör är det där navigationen ska placeras säger jag istället att det är där man ska lägga den viktiga meningsbärande informationen; det användaren letar efter, och det som kommunicerar vad sajten handlar om.

Placerar man den kompletta innehållsförteckningen – en navigation är, i grund och botten, en innehållsförteckning – på den plats där användaren har störst fokus signalerar man att just förteckningen, inte innehållet, är det viktigaste.

I vissa fall är såklart innehållsförteckningen oerhört central. Men i många fall är den sekundär. Vad som är viktigt är istället att användaren lyckas göra det hon ska, så snabbt och smärtfritt som möjligt.

En naturlig konsekvens av detta är att man först tänker ”vad vill användaren göra här” och sedan ”hur ska jag gå tillväga för att göra det så enkelt som möjligt för användaren”. Förhoppningsvis är det det som nu börjar hända – ett skifte från det förhärskande ”såhär navigerar man, hur ska jag då strukturera och namnge saker för att användaren ska hitta” till ett mer nyanserat ”jag måste förstå användaren innan jag designar en lösning” – inte bara en modenyck. Att kategoriska uttalanden, som Nielsens, får ge vika för kritiskt tänkande.

Jag håller tummarna.

Post-PC eran

År 2007, för drygt fyra år sedan lanserade Apple sin första iPhone i USA. Ett år senare lanserades en uppdaterad version i 70 länder. I och med detta började den smartphoneboom vi ser idag vilket nog kan ses som det definitiva startskottet på den så kallade Post-Pc eran. Begreppet kanske kan tolkas som att PC:n är död men det handlar snarare om att vi använder IT-baserade lösningar på helt nya typer av enheter där datorn tidigare var enda alternativet.

Idag äger en stor del av svenskarna en smartphone som erbjuder tjänster och möjligheter som inte fanns för fem år sedan. Jag tror ganska många aktörer är tagna på sängen av det snabba genomslaget och det är verkligen fascinerande hur snabbt det gått. Vi ser en ökad diversifiering av enheter och miljöer där människor använder it-lösningar. Vidare påverkas användningen av tjänster då de blir tillgängliga i nya typer av sammanhang såsom exempelvis via Ipad och pekplattor.

Många är i uppkopplade konstant till tjänster men på olika sätt och med olika behov beroende på var man är och vilken typ av enhet man använder sig av. Att skapa ändamålsenliga lösningar handlar alltså inte bara om att göra något bygga något rent tekniskt för en viss typ av enhet utan förstå de specifika behov och möjligheter som olika enheter erbjuder.

Ifrån ett verksamhetsperspektiv kan detta påverka verksamhetens strategi och affärsmodell genom de möjligheter som erbjuds i och med Post-PC eran.

Inom UX-området finns det många spännande utmaningar då en stor del av de principer, vanor och mönster har byggts upp under eran då desktopdatorerna med dess metaforer varit dominerande (detta gäller även it-branschen i stort). Nu är det helt nya typer av enheter med nya interaktionsprinciper och användningsvanor vi ser framför oss och även om mycket har hänt är jag säker på att helt nya infallsvinklar och metoder kommer dyka upp den närmaste tiden.

Kravhantering – kontraproduktivt?

Kravhantering, så som den bedrivs i IT-projekt idag, är slöseri med tid och resurser. Med tanke på hur många, särskilt inom användbarhetsområdet, som arbetar med kravhantering är det förstås en provokativ tanke.

Kraven finns där för att det är en stor lucka mellan affärs- och verksamhetskonsulternas abstrakta rapporter och den faktiska systemimplementationen de ibland förordar. Så långt allt väl. Men vad är kraven egentligen bra för? Vad försöker de beskriva?

Jag hävdar bestämt att krav är en artefakt av ett alltför ingenjörsorienterat arbetssätt. Ett arbetssätt där man trots allt uppmärksammat att man på något sätt måste definiera och specificera vad det är som ska göras, visst. Problemet är att så fort kraven är formulerade glömmer man varenda ord om vad, varför och för vem. Du kan ha kartlagt och skrivit personas, definierat scenarios, vad som helst, men när kraven finns där är det dom som styr. Obevekligt. Och i 9 fall av 10 levereras ett system som uppfyller tillräckligt många av kraven för att leveransen ska vara godkänd men som inte går att använda och som inte fyller nån affärsnytta.

Pengar i sjön.

Och det värsta är inte att jag säger dethär utan att det faktiskt händer. Igen och igen och igen. Och beställarna svarar med att försöka bli bättre och bättre på att skriva krav. Blir det det?

Inte så vitt jag vet.

Snarare har kraven förvandlats från generella ”bilen ska vara bränslesnål” till specifika ”bränsleinsprutningen måste vara kalibrerad till 0,00001% marginal”. Kontraproduktivt.

Därför har jag börjat prata om att krav är föråldrat. Vill man verkligen uppnå affärsnytta kartlägger man behov och förväntningar och matchar dem mot verksamhetens strategier och visioner.

Detdär är ju inget nytt för de flesta av oss. Men nästan alla arbetar fortfarande med krav och kravhantering – det är till och med en särskild yrkesroll och i linjeverksamhet har man ofta kravhanterare anställda; först tar man fram behoven, målen och konceptet. Sen simsalabim gör man krav.

Och där någonstans tappar man bort hela nyttan med investeringen.

Som en konsekvens av detta provar jag just nu med att strunta i krav. Det enda (sic!) som behövs är ju egentligen att kartlägga, prioritera och balansera alla intressenters behov och förväntningar, inklusive affärsstrategierna och målen. Sen dokumenterar man det i koncept, design rationale, lösningsarkitektur och interaktionsdesign. Hur exakt man går till väga beror ju på om man implementerar standardsystem, om man gör en app till en padda, eller vad det nu är, men i grunden är det ju inga konstigheter.

Självklart måste man ha koll på informationsarkitektur och verksamhetsregler och en massa andra saker. Men så fort man gör krav av dem blir det de som styr, inte nyttan eller meningen med hela investeringen.

Och hela meningen med det vi gör är ju att det ska bli nytta, nytta och ändamålsenligt!

Vad, varför, hur och hur

Utvecklingsmetoder får ofta stor uppmärksamhet inom it-området. Leverantörer säljer sin unika metod, kunder som beställer system och tjänster har sin metod vilka ofta är kvalitetssäkrade. Men hur mycket påverkar egentligen metoden slutresultatet?

Det är bra att det finns metoder, utan dessa skulle  skapandet av it-lösningar vara en än mer svårlöst uppgift och jag tror valet av metod (SCRUM, RUP mfl.) är av stor vikt för hur tidsramar och produkt svarar upp till en kravmängd.

Men är det ”rätt” krav och avvägningar som adresseras givet det tänkta verksamhets- och användningssammanhanget? Vad och varför-frågor riskerar lätt att hamna mellan stolarna. Projektet kan med andra ord hålla tiden men resultatet i användning – i verksamhetssammanhanget kan vara en besvikelse. Den andra extremen är ett försenat projekt där lösningen blir en succé. Det är helt klart att vissa metoder är mer öppna för att krav/behov behandlas mer flexibelt under projektets gång men jag tror generellt på att ett ökat fokus på verksamhets/användarbehov och effekter skulle ge fördelar.

I dagsläget känns det som att metoder och ansatser som tagits fram (de som används idag) gjorts av personer som främst arbetat med implementation av programvara. Fokus blir då lätt på en effektiv utvecklingsprocess ur ett implementationsperspektiv.

Det är ytterst viktigt att it-projekt drivs mer i termer av affärsutvecklingsprojekt och metoderna måste därför ligga mer i linje kring hur en verksamhet i allmänhet utvecklar sina koncept/produkter och idéer. Samtidigt är det viktigt att projektet drivs kostnadseffektivt och levererar en it-lösning av hög kvalitet baserad på en väl genomtänkt och stabil arkitektur. Vad, varför, hur (process), hur (teknisk lösning) samt förväntade effekter måste i många fall balanseras bättre.

Utfallet av en it-investering påverkas ju trots allt av hur lösningen fungerar i faktisk användning i ett sammanhang. Jag är övertygad om att ux-kompetenser kan bidra i mycket större utsträckning och betydligt tidigare i arbetet med nya it-lösningar genom att arbeta mer integrerat med krav- och verksamhetsfrågor för att uppnå tänkta effekter i användning.

Användbarhet och standardsystem – är det möjligt?

Spontant vill man svara ett rungande NEJ på den frågan och jag tror att de flesta som jobbat med den typen av lösningar är beredda att hålla med. Ändå köps de. Beslutet tas ofta av IS/IT och det baseras på att det passar ihop med IT-strategin, att man redan äger plattformen som en del i en licens man ändå betalar för och för att man har krav på sej att minska utvecklings- och förvaltningskostnaderna.

Men faktum är att detdär NEJ:et inte behöver vara så rungande. Nycklarna är tre –

1. Väl genomförd behovsanalys
Grunden anger förutsättningarna. Många projekt byggs på ett gungfly av lösa antaganden; antaganden om affärsnytta, om användarnas behov, om organisationens behov… Oavsett om du ska implementera ett handläggarstöd, en extern webb eller ett verksamhetsstödjande intranät måste du ha koll på följande faktorer –

  • Affärsmål och de därmed sammanlänkade affärsstrategierna
  • Verksamhetens och affärens nu och bör-lägen
  • Kulturen internt, samt det interna politiska spelet
  • Samtliga intressenters förväntan, både på företaget/organisationen och på ett eventuellt system

Förstår man ovanstående kan man koppla affärsmål, strategier, användarbehov, förväntningar och kultur till bör-läget varpå man kan börja ta fram en konkret åtgärdlista. Åtgärdslistan bildar sedan tillsammans med övriga faktorer underlag för effektmål och produktmål.

Nyttan av detta är tydlig i två olika lägen: dels när helt ny plattform ska väljas/köpas in – man vet helt enkelt vad plattformen måste kunna för att komma ifråga; dels när det redan finns en inköpt plattform (vanligare än man skulle önska) eftersom man då har ett bra underlag när den ska konfigureras för att fungera optimalt.

2. Dokumenterat stark produktkunskap aktivt tillgänglig
Majoriteten av standardprodukterna är väldigt flexibla… och oflexibla. Vissa saker kan konfigureras väldigt långt och kan fås att både fungera och uppträda mot användaren på olika sätt. Andra saker är oerhört stelbenta. Att ha en teknisk arkitekt som kan plattformen i sömnen är ett måste, och vet man redan i behovsanalysen vilken plattform det handlar om (som sagt – vanligare än man skulle önska) kan man löpande diskutera olika alternativa åtgärder/sätt att hantera behovet.
Att ha en sån person med är också en garant för att det som designas och implementeras faktiskt är optimalt både för användarna, ägarna och tekniken.

Jag brukar säga att vem som helst kan designa det perfekta tidrapporteringssystemet men bara några få kan ta fram ett som fungerar både tekniskt och för användarna – ALLA användarna. Det gäller särskilt när det gäller lösningar baserade på standardplattformar; för användarna kan det ibland vara mer eller mindre egalt om det är en dropplista eller kryssrutor men för systemet kan det vara skillnaden mellan att ställa om ett värde eller en veckas specialanpassning (som sedan gör att dedär vinsterna man ville göra i förvaltningsledet omintetgjordes).

3. Mikroanvändbarhet som en del i konfigurationsprocessen
Eftersom många av standardplattformarna är oflexibla på punkter som egentligen är avgörande för den vanliga användaren är det extra viktigt att de får hjälp i de små detaljerna. Här är enkla användningstester ett starkt kort. I praktiken betyder det att namngivning, visuella informationsstrukturer, placeringar och disposition/layout inte ska tas fram enbart av projektgruppen utan med stöd i kontinuerliga tester genomförda under själva implementeringen. Ska avdelningen/sektionen heta ”Om oss”, ”Om företaget” eller ”Om NAMNXYZ”? Gör enkla klicktester så ökar sannolikheten för att folk hittar rätt när de väl behöver vad-det-nu-är.

Undantaget är de fall när det finns starka skäl, kopplade till bör-läget, för centralt beslut, till exempel när namngivning, visuell informationsstruktur med mera är ett sätt att kommunicera identitet och riktning.

Medvetenheten om dessa tre nyckelpunkter innebär att sannolikheten att de nyttor man ursprungligen tänkt sej faktiskt kan realiseras, i tid och på budget, i ett system som faktiskt går att använda. Och inte minst det senare är ju vi UX och användbarhetsexperter intresserade av 🙂