Haffsjobb?

Man kan ju alltid bryta ner och analysera allt i atomer till absurdum – självklart! Och de mest fundamentala grundreglerna måste man hålla sig till vad det gäller utformning och hur element förhåller sig till varandra. Jag tycker personligen att de två mest grundläggande förfaranden att testa vid en framställning av en logotyp är hur den ter sig extermt uppförstorad och att den är tydlig i sin minsta storlek. Göran Söderström på Pangea hade några minuter över att analysera… Se och begrunda.

Konstiga instruktioner

Igår hämtade jag för första gången ut tågbiljetter i en av SJ:s automater. Normalt sett har jag haft så gott om tid på mej så att jag valt 'hemleverans', men för gårdagens resa var inte det en möjlighet.

Gott och väl. Jag anlände till Stockholms Central, letade upp automaterna, skrev in mitt bokningsnummer, mitt telefonnummer. Föredömligt enkelt och bra. Sen skulle jag välja Fortsätt/Enter, och jag läste instruktionen - "använd tangentbordet för att navigera" (eller liknande). Hm. Det fanns en navigeringskula, och något som såg ut som en touchpad.
Jag försökte använda dem, utan framgång.
Jag försökte trycka Enter (tangenten).
Till slut resignerade jag och tryckte på skärmen.
Det funkade.

Man kan ju undra hur de tänkte när de skrev instruktionen... Fast efter att ha läst Monas inlägg om att använder inte läser instruktioner tänker jag att kanske stod det något sist i den där långa meningen, något som jag borde ha läst.

Hur det nu än är med den saken så funkar det dåligt.

Användare läser inte instruktioner

Jag har idag fått ännu ett bevis för att människor oftast inte läser instruktioner.

Dagens lunch intogs på ett fik. Då jag kom in på fiket kände jag igen vattenkranen från ett blogginlägg på inuseful. Blogginlägget handlade om att det krävdes en instruktion för att kunna använda kranen.

Eftersom jag läst blogginlägget visste jag nu redan innan att jag skulle stampa med foten på en knapp för att få vatten. Kände mig till och med lite duktig som kände till hur denna kran skulle manövreras.

Då jag är nöjd med mängden vatten i glaset börjar jag förtvivlat försöka stänga av vattnet. Jag provar att stampa några gånger på golv-knappen, men utan resultat. Glaset är sedan länge fullt, men vattnet fortsätter strömma ut ut kranen.

Tjejjen i kassan ser min förtvivlan och säger att vattnet stänger av sig självt. Jaha säger jag ser efter ett tag att vattnet mycket riktigt stänger av sig självt. Jag går till mitt bord och muttrar lite över vattenkranen. Då påpekar mitt lunchsällskap att det stod tydligt på instruktionen att vattnet stannar av sig självt..... Den delen av instruktionen hade jag helt missat....

Vad kan vi dra för slutsatser av detta då? Jo, att människan är extremt målfokuserade i det hon gör. Då mitt mål var att få vatten i glaset läste jag bara fram till den delen på instruktionstexten. Resten läste jag inte....

Det är ju väldigt lätt att överföra dessa lärdomar till hur människor använder IT-produkter. Man läser inte instruktioner om man tror att man kan lösa uppgiften ändå.

Är agila utvecklingsmetoder av ondo för användbarhetsperspektivet?

Alla har bråttom, och om man dessutom betalar så vill man att det ska kosta så lite pengar som möjligt. Känns det igen? Jag tror det gäller oavsett om man insett att man behöver en ny diskmaskin, ska bygga om köket, eller bestämmer sig för att bygga en ny webbplats eller applikation.
Funkar det?
Tja, det beror väl på vad man accepterar. Har diskmaskinen kraschat och det är bråttom med en ny, då får man ta vad som finns.
Ska man bygga om köket kanske man är lite mera noga, och kan tänka sig att skjuta på tidplanen lite för att få det som man vill ha det, till rätt pris.
Webbplatser och applikationer... av någon anledning tror många att de är som diskmaskinen - bara att köpa och köra - när de i själva verket är som köket; man måste fundera lite på hur man vill jobba i det, vad som är nyttan, med vilka lösningar.

För det syftet fungerar agila metoder bra. Du har en idé om vad du vill åstadkomma, men du behöver flera kompetenser än din egen för att kunna kunna hitta den rätta lösningen.
För att det ska fungera bra måste du ha en klar bild av målet, nyttan, och de praktiska förutsättningarna, men det borde vara självklart.
Ett problem här är förstås att många tror att man agil utveckling betyder att man kan börja utveckla utan att ha en aning om vart man ska, och till råga på allt tror man att det ska bli bättre än om man jobbar på något annat sätt. Ursäkta, men var tappade du hjärnan nånstans? Börjar man bygga köket genom att säga till en snickare "jag behöver ett nytt kök, sätt igång"?
Nähä. Tänkte väl inte det.
;-)
För precis som med köket måste systemen specas, åtminstone vad gäller omfattning, syfte, mål, nytta, ekonomi, och allt det andra. Sedan måste man våga låta detaljbesluten vänta till senare. Ett exempel är att i definitionen av projektet kan det vara lämpligt att ta reda exakt på vilka användarna är, mappa deras vardag och behov, liksom att noggrant dokumentera system/produktägarens mål och syften. Man behöver förstå omfattningen, och kanske testa fram ett generellt navigationsramverk. Men den praktiska gränssnittsdesignen, den tas fram iterativt, sprint för sprint, gärna med kontinuerlig feedback från användare och ägare.

Det är inte klassisk användarcentrerad design. Men det är nytto- och användarcentrerat så det skriker om det, om vi vill det, om vi finns där och ser till att det är interaktionsdesigners och inte utvecklare som gör gränssnitten.

Därför blir jag lite irriterad när jag läser Steve Batys kolumn Bite Sized UX research på UX Matters. I inledningen står det -

It’s not uncommon for projects to lack the time, money, or resources to conduct ideal user research activities. There are many reasons why this occurs:

• Sometimes we’re brought onto a project late.
• Perhaps we’re new to an organization that doesn’t really get UX.
• Maybe a company is rushing to bring a product to market for some reason—and there are plenty of good and bad reasons this might be so—and there simply isn’t time to “go big”.
• Perhaps your client or organization is following an Agile development methodology.

“As UX professionals, we can always add value, at any stage in a project.”

At such times, it can be tempting to just throw up our hands in dismay and do nothing or lament the fact that everything isn’t perfect.

WTF?!?!?! Extrem tidbrist, bristande planering, bristande förståelse för vår kompetens... kan likställas med att man använder en agil utvecklingsmetod?!?!
Jag kanske ska säga också att det är enda gången konceptet agila metoder överhuvudtaget nämns i hans text, så det känns som om han har slängt in det, lite slentrianmässigt.

Jag vet att han inte är ensam om att känna skepsis inför användandet av agila metoder. Men om man jämför med klassisk RUP eller 'vattenfall' så är det tveklöst så att rätt genomfört ökar chansen att den slutliga tjänsten eller applikationen tillför nytta, på ett för användarna tillräckligt bra sätt om man använder en agil metod.
Även om det innebär att vi måste förändra våra arbetssätt. Men det är ett mycket litet offer i relation till helheten... och det borde inte vara något offer alls, eftersom vad vi strävar efter är att göra lättanvända och ändamålsenliga lösningar.
Eller?

Kartor i kubik och kvadrat!

Tillhör du dem som har längtat efter ett verktyg där du kan lägga kartor på varandra och se valda delar av dem samtidigt?


Då ska du testa Map Cruncher (Beta), från Microsoft. Inte online - det är en programvara, men det gör den inte mindre intressant för oss kart- och visualiseringsnördar!