”Operationen lyckades, men patienten dog” är en term som vi kravledare och UX-designers slänger ur oss för att uppmärksamma beslutsfattare och projektledare på risken att missa en produkts "varför" och till att fokusera fler resurser på en ordentlig kravhantering. Våra projekt resulterar i produkter som floppar av många olika anledningar och ett stort antal produkter slopas p.g.a. att ingen ställde frågorna ”Varför tillverkar vi detta?” och skapade en produkt som inte ens behövs. Tid och pengar ödslas i alldeles för många utvecklingsprojekt och det är vårt endast vårt fel. Det är oerhört enkelt att göra rätt från början, vi måste fortsätta fråga ”...men, vad är ditt problem?”
Året var 2002 när Microsoft försökte väcka liv i surfplattekonceptet som hade misslyckats flera gånger tidigare, och som skulle visa sig misslyckas ytterligare en gång. Drygt 10 år senare lanserade Apple ett likadant koncept men med lite snyggare smink som dessutom gav en ganska saftig omsättning på en produkt som bevisligen ingen hade behövt tidigare. Skillnaden var att Apple lyckades att skapa ett behov, ett så starkt HA-begär att det nu för tiden ligger en surfplatta på nästan hälften av alla¹ vardagsrumsbord.
Ladda ner vår guide - Så säkerställer du affärsnyttan
Detta är ett väldigt tydligt exempel som helt och hållet greppar tag om det här blogginläggets poäng och knockar den med en klockren uppercut i första ronden men sen är ju Apple världsmästare i att skapa behov och deras slagkraft är svår att mäta sig med. Vi vanliga dödliga vill gärna kunna skapa den typen av behov och trycka igenom produkter på marknaden bara för vi tycker att det verkar häftigt, men eftersom verkligheten ser annorlunda ut och vi knappast har Apples slagkraft eller ekonomi behöver vi lite hjälp på vägen för att lyckas från början. I våra projekt har alltid vår målgrupp ett behov som grundar sig i att de har en utmaning i sin vardag. Kravhanteringens mål att leverera en lösning som mättar användarnas behov.
Många av er börjar nu tycka att det jag säger är självklart, och ni har helt rätt. Det är helt och hållet glasklart för de flesta av oss att ett projekt ska leverera en produkt som löser en utmaning eller ett problem. Men varför fortsätter vi att misslyckas hela tiden?
Vad hände med Användbarhetstänket?
Utvecklingsprojekt fortsätter leverera dåliga produkter som ingen vill ha och anledningen är oftast samma sak – projektet förstår inte målgruppens problem. Vad hände med Användbarhetstänket?
Människan är i naturen lösningsorienterad. Vi ser ett problem eller en utmaning och försöker hitta en lösning, det är därför vi har kommit oerhört långt i vår samhällsutveckling. Vi är däremot dåliga på att förstå att problemet som vi ser är inte alltid är det verkliga problemet. Det är naturligt svårt för oss att ändra vårt beteende kring problemdefiniering, men som kravledare är just den egenskapen nyckeln till att säkerställa att vi bygger rätt produkt.
Vi måste därför inleda vår kravprocess med att ifrågasätta produktens betydelse för målgruppens utmaningar. Vi måste genom hela utvecklingsprocessen validera vår problemdefiniering så att vi är helt säkra på att produkten som vi levererar motsvarar vad vår målgrupp behöver. Den bittra verkligheten är att målgruppen sällan kan definiera sin utmaning korrekt, detta p.g.a. att de är ovetande av vad deras egen påverkan innebär för deras utmaning. Ett projekt jag jobbade på fick en buggrapport av en kund i videoform, där kunden spelade in sina steg och visade sitt problem. Han klickade på en ikon, förväntade sig att hamna på en sida men hamnade på en annan. Inte helt förvånande gick det ganska snabbt utför med ödmjukheten i projektet och man glömde snabbt hur vi bör jobba med användbarhet.
Vad är det faktiska problemet?
Projektledaren pratade med en utvecklare och de skapade tillsammans en problemdefiniering – ”Knappen fungerar inte som den ska” och utvecklaren påbörjade processen att rätta problemet, helt ovetandes om vad det faktiska problemet var.
Som kvalitetskonsult hamnar detta ganska snart i mitt knä för djupare undersökning eftersom utvecklaren inte kunde återskapa problemet enligt beskrivningen och i koden så ska ”det här inte kunna hända, det är teoretiskt omöjligt!” Vi hade tidigare gjort en målgruppsanalys och kände till vår målgrupp väl och hade även tidigare varit i kontakt med kunden som har rapporterat felet. Alla inblandade hade erfarenhet av den här typen av rapporter sedan tidigare, men ändå var man lite för snabb med att dra slutsatser. Jag kollade på videon och hittade vad som orsakade problemet på en gång. Det visade sig att kunden ALLTID dubbelklickade när han navigerade i systemet. Det var inte fel på knappen, den länkade till helt rätt sida, men när sidan laddas ligger en annan knapp på precis samma ställe vilket gjorde att en dubbelklick också betyder att man navigerar ifrån sidan man vill till.
Problemet – ”Jag hamnar på fel sida”
Problemdefinitionen – Knappen är trasig
Orsaken – Ett inarbetat beteende hos kund som skapade en förväntning.
Lösningen – Utbildning och manualer för slutanvändare
Misstaget – lösningsorienterat tänk kostade projektet tid, pengar och frustration eftersom man inte ifrågasatte problemet tillräckligt.
För att undvika att hamna i den här fällan fler gånger måste man kontinuerligt genom en utvecklingsprocess fortsätta ställa frågan ”Varför?”. ”Varför är du stressad?” – För att jag inte hinner göra allt mitt arbete. ”Varför hinner du inte göra ditt arbete?” – För att det tar lång tid att göra mina uppgifter. ”Varför tar det lång tid?” – För att det är långsamt att arbeta i systemet. Här hade många antagit att systemet har dålig prestanda, medan en till fråga kommer utesluta osäkerheterna. ”Varför är det långsamt att arbeta i systemet?” – För att jag inte hittar rätt funktionalitet. Svaret innebär alltså att systemet inte nödvändigtvis är långsamt, utan snarare lider av att det är för komplext att förstå funktionaliteten.
Nyfikenhet och envishet för att hitta orsaken till problemet!
Det är först vid en nyfikenhet och envishet av en 5-åring som man når den verkliga anledningen till vad som faktiskt orsakade problemet.
Kravledare är generellt duktiga på att försöka involvera målgruppen och gör det ofta genom enkäter, fokusgrupper eller intervjuer och det räcker ofta för duktiga och erfarna kravledare för att bilda en väldigt bra uppfattning av problemområde och behov. Det finns däremot en risk med att acceptera målgruppens egen problemdefinition. Steve Jobs sade att ”Kunden vet sällan själv vad den vill ha.”, och om vi anser att vår kund är vår slutanvändare så är jag beredd att hålla med, men av erfarenhet vet jag också att användaren är väldigt tydlig med vad de vill ha, men det är inte samma sak som vad de faktiskt behöver.
För att verkligen få reda på användarnas ”Varför” bör man ta till en djupare analys. Här kan man alltid förlita sig på en fältstudie. Att få observera användare i den miljö där deras problem uppstår ger ofta kompletterande information till det problemet som användaren själv beskriver, eftersom de själva inte ens är medvetna om många av de steg som leder till att problemet uppstår.
Vill du veta mer om djupgående användarundersökningar och orsaksanalyser, eller har du förslag på andra bra tillvägagångssätt för att samla in denna typ av information hör gärna av dig till mig.
Du når mig på deni.aganovic@addq.se eller 070-360 33 10.
Vill du veta mer om hur du skapar en effektiv kravprocess, ställer krav på rätt nivå och på så sätt ökar affärsnyttan? Då tycker jag att du ska ladda ner vår guide.
