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.

Workshop som metod: bedrägeri på hög nivå

Jag har länge varit allergisk mot användandet av workshoppar. Många undrar varför, det är en vedertagen metod inom IT-branschen, och många kunder förutsätter att man ska använda den – ”vi har sagt att vi ska bjuda in till workshopar, när kan vi ha den första” är en inte helt ovanlig fråga.

Workshoparna kommer också som en naturlig del i exempelvis metoden MSF Agile for Sharepoint, från Microsoft, och är en given grundkomponent i praktiskt taget alla arbeten som görs av verksamhetskonsulter på IT-bolag.

Workshop betyder, fritt översatt, arbetsmöte. Jag har inget emot arbetsmöten. Men vanligen avses med workshop en alldeles särskild typ av arbetsmöte där deltagarna under ganska strikt ledning flyttar gula lappar (eller motsvarande). Workshopledaren leder, definierar och avgränsar arbetet, deltagarna bidrar inom de avgränsade ramarna.

Vad är då felet?

Metoden används för att fånga krav, sägs det. Ett sätt att kartlägga och tillgodose användarnas och verksamhetens behov. Genom att låta en grupp användar- eller beställarerepresentanter få bestämma vad som ska gälla för applikationen, eller vad det nu är, hoppas man att IT-systemet ska göra det man vill att det ska göra. Och man gör det med målet att man på arbetsmötet tillsammans ska nå samförstånd.

Redan nu tror jag de flesta höra själva hur fel det låter, men jag ska ändå vara tydlig -

Oavsett om det gäller målsättning och avgränsning, innehåll och struktur på övergripande eller detaljerad nivå, eller ren PR-verksamhet, handlar konsulten oansvarigt om man oreflekterat använder workshoppen som metod eftersom man med detta överlåter en stor del av arbetet på kunden, samtidigt som man låtsas att man tillvaratar kundens intressen.

I verkligheten har extremt få användare och beställare tillräckligt god uppfattning om exakt hur och vad som ska göras – enligt exempelvis Erik Fors-Andrée är det till och med en risksignal om kunden tror de vet exakt vad som ska göras – och extremt få användare har en bra uppfattning om vilka arbetsredskap de skulle ha nytta av eller hur de skulle se ut. De är experter på att UTFÖRA sitt jobb, men inte alltid på att analysera det i termer av IT-system eller i relation till företagets totala verksamhet, strategier och kultur.

Man lever då också med den falska bilden att införandet av nya system kan göras i en anda av samförstånd när det i verkligheten undantagslöst är så att det finns gott om folk i organisationen som har investerat åtskilligt i tid, pengar och personligt rykte i de befintliga arbetssätten, IT-stödda eller inte, samtidigt som det inte sällan finns motsättningar mellan vad de anställda vill och vad ledningen vill.
Och då har jag ändå inte nämnt alla de högljudda särintressen som genom sina specialiserade utbildningar tror sej vara mer lämpade än alla andra att tala om för folk vad de behöver…

Att då lägga över ansvaret på kunden och kundens medarbetare är inte bara oförsvarbart – det är bedrägeri. Ett fegt bedrägeri.

I bästa fall är konsulten/utföraren omedveten om att det finns bättre metoder. IT-branschen är trots allt fortfarande tekniktung och workshoppen är ett beprövat ingenjörsmässigt verktyg, det vill säga verkar logiskt och som sunt förnuft.
Sunt förnuft har lurat den bäste, många gånger.

I sämsta fall används den mot bättre vetande, eller för att det känns så himla bra att komma ut från en workshop och känna att det finns samförstånd. Många är bara riktigt nöjda om de känner att alla är överens när de kommer ut från ett möte och workshopen är en enda lång orgie i att hamna på samma sida bordet.

Hur det än ligger till, om det är självbedrägeri eller uppsåtligt, så är workshopmetoden inte ett ändamålsenligt tillvägagångssätt varesej syftet är att definiera övergripande omfattning, att ta fram en specifik detaljdesign eller att förankra i en organisation.

Resultatet är bara halvdana kompromisser och undermåliga beslutsunderlag och det är en etiskt motbjudande metod av två skäl – man lurar kunden att göra jobbet, och man gör fel jobb med fel verktyg.

Dags att öppna verktygslådan och se efter vilka alternativen är, den som vågar.

Ja, jag kan höra er – ”Varför presenterar du inga alternativ NU? Det är så lätt att klaga och så svårt att vara konstruktiv, jäkla nej-sägare (”/&%%##/())”. Lugn. Uppföljaren kommer handla om det ;D
Jag bara håller tummarna för att det inte dröjer – det är fullt upp, för tillfället…

”Prototyp” – det läskigaste ordet en kund kan skriva i en uppdragsbeskrivning?

Prototyp – det läskigaste ordet en kund kan skriva i en uppdragsbeskrivning?
Vad är egentligen en prototyp? Wikipedia skriver: 

Prototyp, (av grekiskans proto betyder modell- urbild-, ur-), förlaga, testmodell. Inte färdig utgåva, ett utkast. En prototyp är en produkt som bara finns i ett eller ett fåtal exemplar. En nollserie är en begränsad tillverkningsserie av en produkt vilken man kör för att kunna lansera och marknadsföra produkten i fråga, innan man börjar med massproduktion. 

Den korta beskrivningen på ne.se säger: 

prototyp – prototy´p, originalmodell som de följande formerna baseras på. Inom industriell produktutveckling avses försöksmodell som är riktig i funktion, konstruktion och utseende.

Men hur definierar vi egentligen en prototyp i våra arbetssammanhang? Var börjar och slutar en så kallad prototyp? Ska prototypen kunna ses som en slutlig kravspecifikation?  
Det gäller att ha en väldigt klar och tydlig definition av vad en prototyp är och att man är väldigt överens om innebörden, syftet och slutleveransen av en sådan. Ska den vara klickbar eller bara innefatta bilder som visar på ett flöde? Ska vi visa bilder som vi gjort klickbara eller ska vi faktiskt koda ett flöde med exakta funktioner? Hur många sidor ska den innehålla?
När allt kommer omkring skulle jag nog egentligen vilja avskaffa ordet prototyp helt i mina arbetssammanhang… och istället kalla det ”Ett smakprov på vad som komma skall.” Inte alls flummigt!  :-)

Komplementfärgernas vara eller icke vara…

… eller minska antalet åtminstone.
Något jag funderat på är antalet komplementfärger/sekundära färger som tas fram till en grafisk profil. Lagom är väl alltid bäst? Vad är egentligen lagom antal komplementfärger i en grafisk profil? Jag skulle vilja säga att man ska välja dem varsamt. För många/för mycket blir ingenting till slut. Det säger ingenting och man kommunicerar inte något utmärkande.
Den senaste tiden har jag fått en känsla av att man gärna vill lägga till alla färgfamiljer till den sekundära färgpaletten för att på nått sätt täcka in hela regnbågen.
Man vill ju självklart inte måla in sig i ett hörn och begränsa sig till låt säga 4 sekundära färger. Men skulle inte det tvärt om vara mer stärkande för den grafiska profilen om man alla fall satte nån gräns på antalet färger?
De sekundära färgerna ska väl också lyfta fram företagets värdeord precis som den/de primära färgerna gör?! På ett sätt kan jag känna att om man slänger fram en palett med säg 10 komplementfärger så har man någonstans misslyckats att lyfta fram det specifika med färgerna som ska matchas med företagets värdeord och grundpelare?

Att få användaren att slutföra det man vill att den ska göra…

Dagens fundering/reflektion.
Vet man egentligen antalet kunder/besökare/utförare av enkäter/registreringar etc som inte slutför ”uppgiften” pga ett dåligt gränssnitt?
Vad är det som gör att en användare väljer att avsluta ”uppgiften”/registreringen eller dyl? Det slog mig när jag häromdagen skulle registrera mig som kund i en webbshop och kände att ”detta kan jag verkligen inte slutföra – jag fattar INGENTING – hur många steg måste jag gå igenom?!”.  När jag ser till mig själv och hur jag resonerar gäller det att dialogen är:

1. Intuitiv/Självinstruerande
2. Snabb
3. Inte för många steg/sidor
4. Tydlig start/slut
5. Grafiks design och kommunikation som tydligt visar avsändare, syfte och som förenklar för användaren i ovanstående punkter.

Hur många potentiella kunder/medlemmar/utvärderare etc tappar man egentligen pga av ett risigt flöde och dåligt utformat gränssnitt? Det går väl såklart inte att sätta en siffra eller procenttal på, men det är nog en del runt om på www….

Användarstudiernas vara eller inte vara

Don Norman har i artikeln ”Teknik först, behov sen” (Technology first, needs last) argumenterat för att många uppfinningar fanns det ingen behov av – de uppfanns, behovet uppstod efteråt.
Tesen han driver är att användar- och användningsstudier inte har någon betydelse.

Det är klart att det provocerar. Varför ska företag och organisationer lägga energi på att kartlägga behov om studierna inte leder någon vart?

I en balanserad artikel (Don Norman on Ethnography and Innovation) svarar James Kalbach på den frågan genom att understryka att god kännedom om behov är grundläggande om man vill att det man gör ska komma till användning och nytta, och han pekar på att att Normans uttalanden i artikeln saknar grund.

Kalbachs inlägg i debatten stödjer min egen uppfattning och erfarenhet – intervjubaserade studier där fokus ligger på att identifiera underliggande och outtalade behov möjliggör framtagandet av underlag för prioritering och därmed design av strategier, processer och tjänster som på bästa möjliga sätt möter behoven både från ägare och användare. Vet man vilka behoven och nyttorna är kan man ta fram strategier som gör det möjligt att få optimal utdelning på investeringen.

Att göra som Norman förespråkar – att uppfinna i blindo – är kanske roligt för de inblandade (om de bryr sej mer om att få uppfinna än att det de uppfinner kommer till användning) men kostsamt, och som Kalbach konstaterar är det redan idag tillräckligt med fokus på tekniken – den behöver ingen ytterligare skjuts.

Tecknen omkring oss

Genom århundradena har människan, i alla fall i vad som skulle kunna kallas västerlandet, jagat det perfekta språket. Syfte och bakomliggande orsaker har varierat, förstås. För drygt tusen år sedan letade man efter urspråket, det första, gudomliga, språket innan Babel (eller efter Noak, om man är lagd åt det hållet – jag är ingendera så för mej kvittar det lika). Andra letade efter dolda sanningar, nyckeln till skapelsen i bisarra ordlekar och alfabetiska reduktionstrick.

Genom århundradena förändrades sökandet. Man kom i kontakt med andra kulturer som man inte enkelt kunde bortförklara som mindervärdiga – Kina, till exempel – och dessutom började nationalstaterna ta form. Somliga språkförsök var elitistiska, syftade till att ge en upplyst elit en nyckel till gud (typ), medan andra var mer ”demokratiska” och motiverade av en vilja att göra det lättare att kommunicera.

Gemensamt för dem kan väl sägas vara att de misslyckades i sitt uppsåt. Visserligen bidrog de till att lägga grunden för lingvistiken som område, men man uppnådde varesej kontakt med skapelsens innersta väsen, lyckades återskapa det ursprungliga språket, eller skapa ett nytt språk att ersätta de befintliga.

Vad har det då med användbarhet att göra?

Flera av de perfekta språken har tagit avstamp i ikoner och symboler. Inget av dem har lyckats och bland de nackdelar som ofta lyfts fram är att symbolbaserade språk är alltför mångbottnade och ambivalenta för att fungera, och att de saknar syntax. Man pekar också på att symbolerna, precis som idiomet är i det talade språket, starkt kulturellt beroende (det senare bidrog också till att omkullkasta drömmarna om det universellt begripliga språket).

Det är väl också det som vi, som användbarhetsexperter, brukar säga – undvik att vara för beroende av ikoner och symboler, kombinera alltid ikon med text, bilden kan inte vara ensamt meningsbärande, tänk på att kulturell kontext varierar… och så vidare.

Samtidigt går verkligheten förbi oss. Överallt finns det symboler, framtagna med förväntan att de ska leda oss rätt. I telefonerna, i programvarorna, på webbplatserna. På flygplatser, längs vägar, i varuhus.

Man kan argumentera för att den typen av symboler inte kräver syntax, men de måste åtminstone vara ändamålsenliga; det vill säga leda folk rätt – inte fel.

Användandet av bilder stannar inte där, dock. Piktogram används flitigt för att ge instruktioner. Säkerhetskortet på flyget är ett sånt exempel, IKEAs monteringsanvisningar ett annat – instruktioner för tillagning av hamburgare på snabbmatsställe ytterligare ett.

Många av de bilder som används är återkommande. Man kan (nog) med rätta säga att en konvention håller på att etableras, både vad gäller vilka bilder som används och hur de används – en slags bildspråkssyntax tar form.

Hur vi som användbarhetsexperter hanterar det är intressant. Den symbol som i Office-programmen används för att symbolisera ”spara (filen)” – disketten – har för länge sedan upphört att ha någon koppling till verkligheten. Man skulle tveklöst kunna argumentera för att den är föråldrad och borde ersättas. Men under resans gång har den slutat vara piktogram och är numera ett ideogram och som ideogram fungerar den, om inte annat för att den är så välkänd.

Håller ett bildbaserat de factospråk på att växa fram, universellt till sin natur?

Är det så finns en mängd intressanta frågor att fundera över.

Vem sammanställer ”ordboken”, vem skriver ner ”böjningsreglerna”? Idag handlar mycket om best practise och godtycke, precis som det länge var för de talade och skrivna språk vars regelsystem vi idag tar för givna.

En del av det ansvaret skulle kunna ligga på oss – det gör det redan, men det är inte säkert att vi ser det för vad det är och därför hanterar frågan lättvindigt.

Det vi gör idag kan få efterverkningar långt bortom det vi hade tänkt oss eller trott…

Den som är intresserad av jakten på det perfekta språket kan läsa Umberto Ecos The Search for the Perfect Language. Om hur ”teknologin” påverkar oss och samhället kan man läsa i Our Own Devices, av Edward Tenner.

Usability vs User Experience

I artikeln The Battle Between Usability and User Experience skriver Thomas Baekdal -

Usability is about the ”ability to use” something. The aim for a usable product is to make it easy to use.

A product has a high level of usability when:

• It requires less mental effort to use
• the frequency of mistakes using it is less, or when the mistakes are less disastrous
• it is more powerful, where ”more powerful” means that it can be used to do more or do it faster
• it is more learnable, that is, when a person can figure it out quicker

(source: Rensselaer Polytechnic Institute)

Making usable products is thus fairly simple. You have clear metrics you need to achieve, and you can analyze how to get a good result.

…och fortsätter med att säga -

User-experience is not like usability – it is about feelings. The aim here is to create happiness. You want people to feel happy before, during and after they have used your product.

Min personliga åsikt är att han här är delaktig i att skapa en konflikt som inte behöver finnas men som har orsakat en hel del sveda och värk genom åren.

Användbarhet i sin klassiska form bär ett tydligt arv av naturvetenskapliga värderingar där endast det kvantifierbara är relevant. Det är då en ren ingenjörskonst, vilket betyder att om man följer regelboken kan man inte göra fel. Men vi vet ju alla att det inte är riktigt så enkelt.
”Skriv tydliga fältetiketter” får genast följdfrågan ”för vem?” och det är såna frågor som har fått till följd att ”usability” glidit över till att bli en av flera komponenter i det som är ”user experience” – vad som är användbart varierar med sammanhanget, och det går inte att bortse ifrån. Samtidigt är det svårt för en och samma person att omfatta alla de kompetenser som ingår i begreppet User Experience – usability (som ju också består av ett flertal kompetenser), grafisk form och visuell kommunikation, gränssnittsutveckling, och tillgänglighet – och därför segmenteras området.

Är det en konflikt? Jag tycker inte det. User Experience är så mycket mer än klassisk ingenjörsdriven usability. Usability som begrepp handlar om att uppnå nyttoeffekter som enbart kan realiseras om hela användarupplevelsen tas om hand. Annars blir det bara lite läppstift på grisen.
Att kalla de User Experience handlar bara om att ge plats för alla de kompetenser som faktiskt behövs för att användbarhet och nytta ska kunna uppnås.

Gör det själv, i den digitala tidsåldern

Idag fick jag ett (en?) tweet från en bekant som liksom jag är fascinerad av kartor. I mitt fall handlar det i synnerhet om tunnelbanekartor av olika slag. Trots att utmaningen är rimligt simpel finns det en uppskö av olika designlösningar, världen över, och de är intressanta ur perspektiv som informationsdesign, typografi och grafisk design men inte minst användbarhet – nyttan med kartan kan endast uppnås om den är begriplig!

Nå, platsen min bekant pekade på var The World’s Best Alternative Subway Maps, från Treehugger. Via den hittade jag en alternativ karta över New Yorks tunnelbana – KickMap.

Det intressanta med den är kanske inte i första hand utförandet. Inte heller det att Metropolitan Transport Authority, som kör tunnelbanan ifråga, avvisat den alternativa designen – sådant händer hela tiden. Nej, det speciella är att Eddie Jabbour, som gjort kartan, gjort den till en iPhone-applikation med utökad funktionalitet såsom att man kan välja att se kartan i nattutförande, med de linjer som då går och med kopplingar till Google Maps, med mera. Det betyder att det inte spelar så stor roll vad MTA tycker – de som har en iPhone kan använda kartan ändå.

Samma sak gäller Res i STHLM, som på ett tydligt sätt utmanar SL med en enkel och lättanvänd reseplanerare.

Klarar trafikutövarna av att möta denna nya tid?

Design utan tanke är också design. Tyvärr.

I början av denhär veckan var jag i Norrköping. För att ta mej dit skulle jag boka en tågbiljett. Hur enkelt som helst, eller hur? Men nej.

Nu ska inte tro det är SJ jag ska klaga på. SJ:s biljettbokning är ett under av användbarhet jämfört med vad jag nu ska beskriva.

Logica är ett stort företag, och många så stora företag har särskilda avtal med reseförmedlare. Vi har avtal med Carlson Wagonlit. För att det ska bli så billigt som möjligt för företaget krävs att vi bokar alla våra resor via en särskild reseportal. Den är riktigt rikigt dålig. Tekniskt sett förmodligen felfri, men mer eller mindre omöjlig att begripa – dåliga instruktioner, ologiska flöden och fält som inte fungerar som man kan förvänta sej att de gör. Och så vidare.

Men det är inte ens det jag ska prata om här. Trots att det tog mej 40 minuter och ett samtal med vår reseansvariga här i Sverige för att kunna boka en tur och retur till Norrköping.

Nej, istället är det dethär – mitt enda alternativ vad gäller den faktiska biljetten är att hämta ut den i en biljettautomat.
Bokningsbekräftelsen kommer i ett långt mail, och innehåller ett bokningsnummer. I absolut sista sekunden bestämmer jag mej för att skriva ut den fil som bifogades mailet. Jag viker ihop pappret och lägger det i min väska.

Det är sommartidtabell på bussarna, så jag kommer till Centralen redan före 7, trots att tåget ska gå först 07:21. Jag går fram till en ledig automat, använder telefonen för att läsa mailet med bokningsnumret, slår in bokningsnumret…. FEL FEL FEL!!! Detta är inte ett giltigt bokningsnummer, tyvärr!!! OK, tänker jag, och öppnar den bifogade filen. Samma bokningsnummer där.

Så jag tar fram pappret. När jag tittar noga finns ett ANDRA bokningsnummer. DETTA är SJ:s nummer – anger det, och allt är frid och fröjd. För säkerhets skull kollar jag om jag hade kunnat se detta nummer via telefonen. Men nej. Det finns ingenstans i mailet, och den bifogade filen är en pdf och den går INTE att förstora, inte i min iPhone i alla fall. Vilket betyder att bokningsnumret är cirka 2 pixlar högt – dvs inte läsbart.

Designat, ja. Feldesignat? Också ja.