Bygga en användarcentrerad designkultur

Under tiden jag filade på det här postade Christopher McCann på EPiServer den här texten på samma ämne. Jag tyckte den var bra, så läs gärna den också 🙂

Som UX designer brottas man ofta med att förändra en organisations designkultur till att bli mer användarcentrerad. Att ta med användarna mer i processen, basera beslut på vad man vet om användarna, öka kunskapen om användarnas behov och kommunicera utifrån ett användarperspektiv. Det kan vara svårt.

Process

Alla UX designers har nog en bild av hur den ultimata processen ser ut. Men alla som försökt jobba enligt sin ”drömprocess” vet att det är svårt. Vi är alltid begränsade till trista saker som budget och tid.

Jag tror man ska vara tuff, följa drömprocessen men banta ned den. Göra alla moment. Om det inte finns tid eller budget så kompromissa inte genom att ta bort moment. Gör momenten kortare, enklare, snabbare. En djupintervju med en kompis mamma är bättre än ingen alls. Ett användningstest med en kollega är bättre än inget alls. Om man gör alla moment så kommer folk runt omkring börja förstå processen, även om det kan kännas futtigt och löjligt ibland.

Inkludera andra i processen så mycket det bara går. Det är energikrävande och tar tid men folk som jobbar tillsammans förstår varandra så mycket bättre. Att ensam få till en förändring är snudd på omöjligt. Man måste skaffa sig allierade och då gäller det att få folk att förstå, på riktigt. Speciellt beslutsfattare vill man ha som allierade. Om en beslutsfattare högre upp fattar så kan det få riktigt bra ringar på vattnet.

Beslutsfattande

Beslut om vad som ska utvecklas och när sker oftast i flera nivåer. Någon i ledningsgruppen kanske beslutar om att en tjänst ens ska börja utvecklas. Mindre beslut kring utformning tas oftast längre led, t.ex. av en utvecklare eller UX designer.

Det är vanligt att designbeslut bygger på magkänsla eller personliga tyckanden. Eller i alldeles för hög grad utgår ifrån tekniska förutsättningar. För att besluten på alla nivåer ska bli mer användarcentrerade och leda till tjänster som folk faktiskt gillar måste man förstås jobba användarcentrerat på alla nivåer. För att det ska hända måste man sprida kunskapen om användarcenterad design i alla led. Och för att det i sin tur ska hända måste folk förstå värdet.

I en liten eller platt organisation tror jag helt enkelt olika kompetenser ska börja jobba tillsammans så man förstår varandra bättre. En utvecklare/arkitekt och en UX:are kanske ska vara aktiv i ledningsgruppen. Eller ledningen kanske ska besöka projekten regelbundet och vara med på användarundersökningar.

När detta inte går får man missionera. Att få utvecklare att förstå är oftast enkelt, speciellt om man jobbar agilt, eftersom man har ett tight samarbete. För beslutsfattare ”högre upp” kan man försöka dra paralleller mellan användarcentrerad design och nytta. Jag har ibland använt effektkartan, som jag skrivit en massa om. Den kan funka bra för att visa kopplingen mellan affärsnytta, kunskap om användare och designbeslut på ett tydligt sätt.

Konkreta goda exempel och framgångssagor kan också funka bra. Men det är viktigt att fokusera på varför man jobbar som man gör och hela tiden relatera till nyttan så den som lyssnar inte får känslan av att man bara gör en massa onödigt extrajobb.

Lästips

Boken Subject To Change av Merholz och Wilkens handlar om precis det här och är svinbra

Applied UX Strategy Part 1: Maturity Models på UXMatters handlar om UX-mognad i organisationer

Mapping Business Value to UX på UXMatters handlar om att mappa UX till affärsnytta

Steget från utvecklare till UX designer

Jag blev glad när jag läste den här artikeln om hur författaren gick från att vara utvecklare till UX designer. Känner igen mig i mycket och vet att det finns många utvecklare där ute som drömmer om att göra användningstester, skapa personas och pitcha wireframes för projektledare som står redo med fogsvansen i högsta hugg. Så jag plankar Boon Chew och skriver om hur jag började med UX/användbarhet, kanske är någon där ute intresserad.

Till skillnad från artikelförfattaren hade jag läst en del högskolekurser på området ”Människa-Dator Interaktion”, men min examen är i datavetenskap. Vad jag kommer ihåg fick man lära sig om kognition, alltså hur hjärnan jobbar med information, och en hel del om tekniker som kunde användas för att beskriva hur människor arbetar med system. De hade ofta tre- eller fyrstaviga förkortningar som HTA eller GOMS.

På kurserna fick vi också öva på att rita användbara gränssnitt, vilket var kul. Så när jag och en vän fick våra första jobb som Javautvecklare på ett litet spelföretag gjorde vi prototyper för spelet med papper, pennor och post-its. När jag bytte jobb och började utveckla webbapplikationer på ett litet företag inom telekomtjänster med 5 utvecklare fortsatte jag med det.

Jag gillade verkligen att utveckla men en dag köpte jag en bok som heter Användbarhet i praktiken (nu finns den som wikibok) som förklarade hur man kan arbeta för att uppnå användbarhet på ett hyfsat lättbegripligt sätt. Det finns bättre böcker på ämnet men den här är på svenska vilket hjälper, kort sagt gjorde den jobbet för mig. Jag insåg hur användbarhetsarbete kan gå till rent praktiskt, vilket universitetskurserna inte lyckats förmedla.

Användbarhetsarbete verkade jätteintressant och det fanns en del utrymme för att påverka utvecklingsarbetet på jobbet så jag började jobba mer med design, prototyputveckling och användningstester. Efter ett tag fanns det tyvärr inte så mycket användbarhetsarbete kvar att göra, bara utveckling, så jag bytte jobb för att ta steget fullt ut.

Min nya roll, vad den nu kallas, är både roligare och jobbigare än att vara utvecklare.

Roligare eftersom man kommer närmare kvalitetsaspekterna hos en tjänst. Man känner att man gjort en skillnad i högre grad och det man gjort syns mer, det finns inget skönare än en användare som gillar ens design. Man får också jobba mer med olika typer av människor, det är kul att få intervjua en aktiemäklare eller en mekaniker och förstå hur de arbetar och tänker. Sedan är det mer kreativt, vilket kanske är roligast av allt.

Jobbigare eftersom man oftare får stå till svars för sitt arbete. Vilken chef som helst kan ha åsikter om placeringen av en knapp men få kan förstå och kritisera programkod, och jag är ofta ensam ansvarig för placeringen av knappen. Detta gör att jag känner större ansvar för det jag gör men också mer press.

Jag skrev för ett tag sedan om vilka fördelar och nackdelar som finns med att ha utvecklarbakgrund så det behöver vi inte ta igen.