Facebook = Ankeborg?! Stavningskontrollshumor!
Av naturliga skäl innehöll mitt senaste inlägg här på bloggen ordet Facebook. Med Chromes svenska stavningskontroll blev just ordet Facebook rödmarkerat och nyfiken som jag är var jag tvungen att titta efter vad förslagen var -
Den konspiratorskt lagde kan undra över om någon har funderat ett extra varv. Eller så är det en algoritm som behagar skämta med oss
Utrymme för reflektion, i vilket fall som helst!
Förvirrande interaktion eller förvirrande utförande?
En community som jag är medlem i har nyligen uppdaterat sitt användargränssnitt. Sajten har en historia av att vara programmerardriven och interaktionen är ofta minst sagt konstig men normalt sett kan man i alla fall begripa hur de tänkte, även när det blev fel. Den här gången hade de nog ovanligt bråttom, dock.
På sajten finns diskussionsforum. Det är raka trådar så svarar man på något längre upp inleder man sitt inlägg med numret på den post man svarar på. Inga konstigheter. Så när jag möttes av nedanstående tänkte jag – oj, här har de ändrat. Tidigare aktiverades meddelanderutan genom tryck på länk, men nu är den synlig hela tiden, sist i tråden -

Enkelt textinmatningsfält, placerat efter senaste inlägget i tråden
Så kikade interaktionsdesignern i mej fram och krävde att jag skulle trycka på Reply, för att se vad som skulle hända. Döm om min förvåning när ytterligare ett textinmatningsfält blev synligt!

De två inmatningsfälten; det nya mellan senaste meddelandet i tråden och original-inmatningsfältet
Den rådige förstår att det nya fältet innebär att man svarar direkt på det meddelande vars Reply-länk man tryckte på. Lite förvirrande bara med TVÅ inmatningsfält ovanpå varandra
Men nå, det är inte slut här. För trycker man nyfiket på More händer detta -

När man väljer More expanderas nya val ut. Vart hör dom?
Valen ser ut att höra ihop med textinmatningsfältet men av sammanhanget kan man dra slutsatsen att de hör till inlägget.
För mej visar dethär hur otroligt viktigt det är att den visuella designen samspelar med interaktionsdesignen. För i grund och botten är det inte fel på själva interaktionen, även om den är tvivelaktigt placerad. Nej, det är bristen på gruppering som är problemet – hjärnan får inte tillräcklig hjälp att sortera informationen. Här kunde den grafiska formen kunnat komma till undsättning. Men det vet ju alla – form är något oväsentligt, nåt man kan lägga till efteråt. Inte.
Det är min erfarenhet att i många situationer räcker inte interarktionsdesignen hela vägen fram – den är logisk, den är i linje med hur man utför en viss handling i liknande system, den är på sitt sätt optimal för situationen… men först när man lägger på formen blir det tydligt för användaren vad man förväntas göra och hur.
Med tanke på det är det extra märkligt när beställare säger ”här är formen, gör nu interaktionsdesignen” eller tvärt om. Eller när man, som i exemplet ovan, bortser helt från formgivningen och låter ”dethär ser modernt ut” styra. Förhoppningsvis är det något vi kommer se allt mindre av framöver.
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!





