Användbarhet och standardsystem – är det möjligt?

Spontant vill man svara ett rungande NEJ på den frågan och jag tror att de flesta som jobbat med den typen av lösningar är beredda att hålla med. Ändå köps de. Beslutet tas ofta av IS/IT och det baseras på att det passar ihop med IT-strategin, att man redan äger plattformen som en del i en licens man ändå betalar för och för att man har krav på sej att minska utvecklings- och förvaltningskostnaderna.

Men faktum är att detdär NEJ:et inte behöver vara så rungande. Nycklarna är tre -

1. Väl genomförd behovsanalys
Grunden anger förutsättningarna. Många projekt byggs på ett gungfly av lösa antaganden; antaganden om affärsnytta, om användarnas behov, om organisationens behov… Oavsett om du ska implementera ett handläggarstöd, en extern webb eller ett verksamhetsstödjande intranät måste du ha koll på följande faktorer -

• Affärsmål och de därmed sammanlänkade affärsstrategierna
• Verksamhetens och affärens nu och bör-lägen
• Kulturen internt, samt det interna politiska spelet
• Samtliga intressenters förväntan, både på företaget/organisationen och på ett eventuellt system

Förstår man ovanstående kan man koppla affärsmål, strategier, användarbehov, förväntningar och kultur till bör-läget varpå man kan börja ta fram en konkret åtgärdlista. Åtgärdslistan bildar sedan tillsammans med övriga faktorer underlag för effektmål och produktmål.

Nyttan av detta är tydlig i två olika lägen: dels när helt ny plattform ska väljas/köpas in – man vet helt enkelt vad plattformen måste kunna för att komma ifråga; dels när det redan finns en inköpt plattform (vanligare än man skulle önska) eftersom man då har ett bra underlag när den ska konfigureras för att fungera optimalt.

2. Dokumenterat stark produktkunskap aktivt tillgänglig
Majoriteten av standardprodukterna är väldigt flexibla… och oflexibla. Vissa saker kan konfigureras väldigt långt och kan fås att både fungera och uppträda mot användaren på olika sätt. Andra saker är oerhört stelbenta. Att ha en teknisk arkitekt som kan plattformen i sömnen är ett måste, och vet man redan i behovsanalysen vilken plattform det handlar om (som sagt – vanligare än man skulle önska) kan man löpande diskutera olika alternativa åtgärder/sätt att hantera behovet.
Att ha en sån person med är också en garant för att det som designas och implementeras faktiskt är optimalt både för användarna, ägarna och tekniken.

Jag brukar säga att vem som helst kan designa det perfekta tidrapporteringssystemet men bara några få kan ta fram ett som fungerar både tekniskt och för användarna – ALLA användarna. Det gäller särskilt när det gäller lösningar baserade på standardplattformar; för användarna kan det ibland vara mer eller mindre egalt om det är en dropplista eller kryssrutor men för systemet kan det vara skillnaden mellan att ställa om ett värde eller en veckas specialanpassning (som sedan gör att dedär vinsterna man ville göra i förvaltningsledet omintetgjordes).

3. Mikroanvändbarhet som en del i konfigurationsprocessen
Eftersom många av standardplattformarna är oflexibla på punkter som egentligen är avgörande för den vanliga användaren är det extra viktigt att de får hjälp i de små detaljerna. Här är enkla användningstester ett starkt kort. I praktiken betyder det att namngivning, visuella informationsstrukturer, placeringar och disposition/layout inte ska tas fram enbart av projektgruppen utan med stöd i kontinuerliga tester genomförda under själva implementeringen. Ska avdelningen/sektionen heta ”Om oss”, ”Om företaget” eller ”Om NAMNXYZ”? Gör enkla klicktester så ökar sannolikheten för att folk hittar rätt när de väl behöver vad-det-nu-är.

Undantaget är de fall när det finns starka skäl, kopplade till bör-läget, för centralt beslut, till exempel när namngivning, visuell informationsstruktur med mera är ett sätt att kommunicera identitet och riktning.

Medvetenheten om dessa tre nyckelpunkter innebär att sannolikheten att de nyttor man ursprungligen tänkt sej faktiskt kan realiseras, i tid och på budget, i ett system som faktiskt går att använda. Och inte minst det senare är ju vi UX och användbarhetsexperter intresserade av

Skit in, skit ut (och var och en är sig själv närmast)

Det är märkligt hur ofta fokus ligger på presentation istället för på insamling och inlämning av data. Många långa meningar har talats och skrivits om vikten av transparens, om att tillhandahålla den information som ”användaren” verkligen behöver, om kanaler för kommunikation.
Vad få talar om är hur informationen ska hamna där.

Normalanvändaren på företag A eller myndighet B eller vårdinrättning C har helt andra saker att fokusera på än att lära sig hur CMS:et funkar i MOSS eller EPi eller WebSphere eller allt vad de heter.
Ja, de går på kurs. Nej, de minns inte riktigt hur man skulle göra, sen när det väl är dags att skriva något. Nej, systemen är inte intuitiva. Särskilt inte för sällananvändare.
Resultatet blir låg kvalitet i informationen, vilket i sin tur resulterar i lågt användande.

Tyvärr har leverantörerna av sagda system ingen som helst insikt i att det huvudsakligen är backend som deras system fallerar. Istället pratar de om integration med funktionalitet X och Y, eller om möjligheterna att anpassa presentationsmallarna.

Lägg lite krut på att göra de gränssnitt som ska användas för informationslämning mer intuitiva, och inse att egennyttan regerar – ingen vill bara ge och ge, man vill ha något tillbaka också. Varför ska jag göra denna ansträngning om jag inte får något tillbaka också?

Dags för tillverkarna av standardsystemen att börja bry sig om användbarheten. På riktigt.

(Ett annat problem är att beställare, leverantörer, etc. fortfarande, år 2007, tror att ”intranät” är synonymt med ”personaltidning på nätet’. Pinsamt. Men det är en fråga för ett annat inlägg.)

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.

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!

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…!)

Inget system kan allt

Vi går i väntans och förändringens tider; det känns som om hälften av de svenska företagen står i begrepp att byta plattform för sina webblösningar.

Majoriteten av dem väljer ett standardsystem, och jag vill betona både ordet ETT och ordet STANDARDsystem.

Klagomålen på standardsystemen är många. De är visserligen billiga på pappret, men när de sedan ska användas upptäcker många att flera av de saker som de ska göra är oväntat krångliga – plötsligt måste man ”skapa” en sida innan man kan börja skriva in nyheten, och när man skrivit in den försöker man länka till ett dokument men hanmar i en serie fönster som man undrar vad man ska göra med.
Hur detta kommer sig berör jag i ett tidigare inlägg, men i korthet så kan man säga att få kunder har köpt på argument om användbarhet och relevans. Köparna av systemen sitter på ekonomiavdelningen eller i toppen på IT-enheten, eller så har vd badat bastu med nån chef hos leverantören.
Köpmönstret har inte direkt medverkat till att sätta användbarhet på dagordningen hos leverantörerna, och nu när frågorna är trendriktigt populära kommer det dröja innan något händer – de som fattar köpbesluten är fortfarande desamma, och dessutom har standardprodukter relativt långa utvecklingscykler. Så även om de vill designa om sina produkter så ser vi som konsumenter effekten först om några år.

Vad ska vi då göra istället? Många väljer att anpassa. Men gör man det försvinner ett av argumenten för standardsystemen – de enkla uppgraderingarna. Anpassningarna är dessutom ofta lika höga som kostnaderna för hanteringsproblemen som uppstår om man inte anpassar.

Min medicin är enkel, och borde vara självklar. Låt varje system göra det som det är bäst på. Kommunikation och nyhetsflöden i en WCM-lösning, låt nätverkande och projekthantering skötas av ett system som är bra på det, och låt dokumenthanteringen skötas av ett dokumenthanteringssystem.
Dokument- och nätverks/projektplatssystemen är de som är mest kostsamma att anpassa. Låt dem vara standard och låt det ofta enklare WCM-systemet vara ramverk.
Lägg på en bra sökmotor, tänk tjänsteorienterat så att alla systemen kan prata med varandra, och möjliggör för byggandet av folksonomier och byggandet av egna kunskapskluster.

Och sist men inte minst – våga ifrågasätta beslut som inte gynnar organisationen/affären, kräv korrelation med affärsmål vid val av produkt!