13 september 2007

Idealvärld eller pragmatism. En efterkommentar.

Del 3 dröjde lite - den fysiska verkligheten trängde sig på :-)
För de som inte läst del 1 & 2 rekommenderas att göra det innan man läser det följande.

Till syvende og sidst är vi som användbarhetsexperter beroende av de förutsättningar vi ges av beställare och projektledare.
Visst kan vi påverka en del, men ibland begränsas vi av verkligheten.

Exempel: "Vi har en första release om 8 veckor. Användbarhet är viktigt för oss, kan du hjälpa till".
Applikationen är då i princip färdig, den ska bara testas och rättas. Alternativt man har verkligen tänkt sig att en fullständig tjänst ska specas, designas, byggas, testas och implementeras på den tiden.

Orsakerna till dessa två scenarios skiljer sig något.

I det första fallet har någon kommit in sent i projektet och upptäckt att användargränssnittet ser för jävligt ut. Eller så har någon gått på en kort kurs och fått idéer. Det är också vanligt förekommande att man upplever sig ha specat hela applikationen/tjänsten/webben och bara vill ha feedback på detaljer när det i verkligheten är så att underlaget mer är att betrakta som en idé.

I det andra fallet har man fått för sig att IT-relaterade konsulter ska hållas kort, annars springer kostnaderna i väg. Så man lägger en stenhård projektplan och försöker kontrollera utförarna i minsta detalj.

I bägge fallen handlar det om god vilja och goda intentioner som slår fel.

Som projektledare eller beställare måste man försöka förstå att standardsystem INTE, som leverantörerna försöker påskina, innebär att det är "plug'n'play". För det är det inte. Jag har hittills inte sett ett standardsystem som inte behöver konfigureras noga, som inte kräver omfattande insatser. I vissa fall finns ett oändligt antal alternativa valmöjligheter som var och en påverkar hur resten av systemet kommer bete sig. I andra fall finns inga valmöjligheter alls utan verksamhet och organisation måste anpassa sig till hur systemet fungerar.

Och det gäller att planera projektet därefter. Annars kommer -

a) projektet dra över tidsmässigt
b) projektet kosta minst dubbelt så mycket som budgeterat
c) resultatet trots a & b inte motsvara förväntningarna

Och i utgångsläget handlar det förstås om att verkligen förstå det standardsystem man köper. Och den hjälpen kommer man i ärlighetens namn inte få från leverantören. För de säger bara att deras system kan allt. Och det kan det. Om man programmerar om alltihopa. Men det är det ingen som talar om.

Etiketter: , , ,

12 september 2007

Idealvärld eller pragmatism. Del 2.

I inlägget "Idealvärld eller pragmatism. Eller lite av båda?" skrev jag om vilka olika förhållningssätt man kan ha till standardsystem. Jag vill undvika upprepning och hoppar över sammanfattningen. Rakt på sak -

Självklart måste man bruka sunt förnuft. Det innebär att man som ansvarig för interaktionsdesignen måste ha god kännedom om det system som ska användas. Vilka delar är enkla att ändra? Hur kan systemets inbyggda beteende användas för att stödja en viss process?

WM-data anlitas ofta för tekniska projekt. Det innebär att i somliga av våra uppdrag består vår del i arbetet att antingen ta fram interaktionsdesign baserat på specifikationer gjorda av andra eller att verifiera interaktionsdesign andra har gjort. Oroande ofta är underlaget framtaget som om valet av standardsystem inte hade någon som helst påverkan på varesig processbeskrivningarna eller interaktionsdesignen.
(Andra är i det här fallet "andra än vi", både inom och utom WM-data.)

Att så är fallet beror såklart inte på illvilja. Faktum är att jag börjar misstänka att det beror på överdriven tro på att systemen ifråga är "generiska", eller på ett beslut om att "användandet måste styra" utan att ha funderat vidare på hur användandet ska styra.
Ska man verkligen lägga 120 utvecklingstimmar på att bygga om en menyfunktion på ett sådant sätt att den blir marginellt mer funktionell? När tester och erfarenhet visar att valet i detta fall mer handlar om designerns personliga preferenser än om påvisade kvaliteter? Timmar som kanske hade kunnat användas för att trimma sökmotorn på ett sådant sätt att sökresultaten blir mer relevanta.

Vi är användarnas fanbärare, men även måluppfyllelsen hamnar på vårt bord. Vi ska värna om användningssituationen OCH om effektnyttan. Att tro att man bäst gör det genom att designa det optimala gränssnittet är självbedrägeri men en trend i tiden - allt fler har börjat tro att det finns slutliga svar på alla frågor.
"Användbarhet" är större än så, och användarna är värda både mer och bättre.

Fortsättning följer!

Etiketter: , , ,

11 september 2007

När du gör intervjuer: råd

Steve Bay, Red Square, har skrivit en artikel med tips om vad man bör tänka på när man genomför intervjuer.
Min enda kommentar är - jag kunde inte ha sagt det bättre själv ;-)
Eller, det kunde jag ju, för jag kunde ha skrivit på svenska, men detta är gott nog.

Håll till godo.

Etiketter: , , , ,

10 september 2007

Idealvärld eller pragmatism. Eller lite av båda?

Vid varje enskilt tillfälle väljer man som interaktionsdesigner, medvetet eller inte, om man ska ta fram en idealdesign - den bästa möjliga designen för det aktuella tillfället - eller om man ska tillåta det av kunden valda verktyget att påverka arbetet.

Argument finns för båda förhållningssätten -
  • Idealdesign - "Som användbarhetsexpert ligger det på mitt ansvar att se till att systemets brukare får bästa möjliga gränssnitt att arbeta med. Tekniken får vika sig, måste man bygga om hela systemet så måste man; enda sättet att uppnå aktuell effekt/nytta är att utforma gränssnitt och flöden enligt vad jag föreslår."

  • Pragmatism - "Det valda verktyget är alltid en faktor. Bygger man om för mycket förlorar man nyttan av att ha köpt en standardlösning med allt vad det innebär av uppgraderingar och så vidare. Därför måste man i designfasen ta hänsyn till verktygets begränsningar."
Trenden att vilja välja standardsystem för sitt intranät eller sin externa tjänstedrivna webbplats har medfört att allt fler interaktionsdesigners ställs inför frågan om hur långt man egentligen ska gå; vid vilken punkt krockar de eftersträvade nyttorna med varandra? När får beställaren inte längre valuta för pengarna?

För frågan är inte om systemen går att anpassa - självklart är det möjligt! ALLT är möjligt, förutsatt att man har tillräckligt med tid och pengar. Men när valet har fallit på ett standardsystem är det för att man INTE anser sig ha obegränsat med resurser samt, förstås, för att man redan har andra system från samma leverantör och därför tror sig kunna göra synergivinster (ha!).

Frågan är istället vilka delar man ska fokusera på.
Eller?

(Fortsättning följer...!)

Etiketter: , , ,