UX skulle inte vara någonting …

Postades denLämna en kommentar

… om det inte funnit en massa människor, män och kvinnor, och faktiskt oftast kvinnor som utvecklat området. Men vilka kommer man ihåg, tror ni? En plansch som denna gör mig så förbannad.

stardux

Whitney Hess såg denna plansch och svarade prompt:

Christina Wodtke lackade också och klagade högljutt:

Och om någon tycker att ”det här var väl inte så farligt”, så har UX-världen förlorat Janice Fraser på grund av detta.

Och nu kanske ni inte vet vem Janice Fraser här. Låt mig berätta.

Någonstans runt 2010 skapade Janice ett företag vid namn LUXR i Kalifornien, hon konsultade hos startups och kombinerade Lean Startup med design i någon hon kallade Lean UX. Hon listade 10 principer för Lean UX. Originalsajten finns inte kvar, men här är DesignPrinciples kopia av LeanUX-principerna. Jag tror ni känner igen alla, även om en del fått nya namn.

Andra personer som utvecklade Lean UX-metodik före det kom en bok i ämnet var Kate Rutter, Laura Klein och Anders Ramsay (den sistnämnda förvisso en man).

Det här är bara ett exempel, ett delområde till UX. Ett annat exempel är Hoa Loranger, som arbetat med Jakob Nielsen sen han blev känd. Varför inte Joann Hackos och Janice Redish är mer kända förstår jag inte heller, deras bok om användarstudier är oslagbar.

Skäms världen!

0

Stockholms UX community 101

Postades denLämna en kommentar

Min vän Maryam tänkte att det kunde behövas en liten informationssnutt för UX:are som vill komma med i gänget, för hon är snäll och omtänksam. Så, det här är våra rekommendationer, i Maryams ordalag. Har ni fler så lägger jag gärna till.

Third Thursday
Här brukar man posta inför Third thursday, en UX AW som sker en gång i månaden, på tredje torsdagen uppenbarligen. Vi brukar ses på Sue Ellen vid Tulegatan vid ca 17.30.

STIMDI
Sveriges tvärvetenskapliga intresseförening för människa-datorinteraktion – de har egna seminarier och workshops men samlar också ihop andras i sin tidslinje, exempelvis från företag eller Dataföreningen. De har också ett trevligt mentorskapsprogram.

UX open
OK, här är jag lite partisk som medarrangör, men UX open är det roligaste eventet inom UX i Stockholm. Det är en knytkonferens där alla får vara med och presentera, hålla workshop och starta diskussionsgrupper. 16 oktober i år.

Chatten
Här kan man anmäla sig att vara med i en chat. Prata med branschen om vad som helst, närsomhelst. Jättekul!

Häng med!

0

Ett lackmustest för agilitet

Postades denLämna en kommentar

Jag hör många som säger att deras projekt är agila. Vad jag har lärt mig av det är när man säger att man jobbar agilt så jobbar man oftast inte agilt. Jag brukar ställa tre frågor för att avgöra hur förändringsbenägen och effektiv man egentligen är i sitt projekt.

  1. Vet ni vad alla andra i teamet och utanför gör? – Kommunikation är a och o. Visualisering på olika typer av boards är det minsta man kan göra. Se till att muntligen kommunicera med varandra tämligen konstant är vad man borde göra.
  2. Jobbar ni tillsammans för att lösa problem? – Samarbete, inte bara samverkan eller koordination, är vad som krävs för att bli effektiv. När hela teamet arbetar på en och samma user story och hjälper varandra att slutföra den, då samarbetar man. Mob programming är ett bra exempel.
  3. Försöker ni att hela tiden navelskåda er process och förbättra den? – Kontinuerlig förbättring krävs för att man som team ska kunna bli bättre på det man gör. Det är faktiskt så att det till och med krävs för att bibehålla sin mognadsnivå. De team som saknar en förbättringsprocess, där man analyserar, experimenterar och följer upp (allra minst en timme i veckan), blir mer och mer omogna med tiden.

Vad svarar ni på de här frågorna?

p.s. min kollega Per Lundholm lade till frågan ”Itererar ni över det ni levererat till produktion så att ni lär er från riktig användning av produkten och förbättrar den, eller, bygger ni i varje sprint ett inkrement av en sedan tidigare bestämd produkt?”. Högst rimligt att ställa den frågan då alternativ ett är en stor faktor till förändringsbenägenhet och till att man överhuvudtaget bygger rätt sak.

0

Brist på medmänsklighet

Postades den2 Kommentarer

Mina kollegor publicerade ett blogginlägg för en tid sedan om att det är omöjligt att kombinera agilt arbetssätt med PM3, vilket är en populär förvaltningsmodell. Mina kollegors poäng är att PM3 och Agile har två olika värdegrunder, därför går de inte att kombinera. Detta har lett till långa diskussioner i diverse forum, såklart. Det finns naturligtvis två tydliga läger i debatten.

För mig symboliserar PM3 det gamla tänket i att man vet precis vad man vill ha och tror att världen och människorna inte förändras under projektets gång. De personer jag känner som har denna inställning (och de som förespråkar PM3 i alla ovan nämnda diskussioner) kallar sina medarbetare för resurser och inte människor. Det tycker jag visar på pricken att man är fast i ett tayloristiskt tänk där en grupp ”smarta” planerar och de ”korkade” producerar. Där och endast där kan man likställa människor med andra råvaror och inte se att det är individerna i produktionen som är basen för att ett projekt ska lyckas.

Jag är ingen jävla skrivare. 🙂

No-Printer-300x300

0

The biggest lie in software development is phase 2 

Postades denLämna en kommentar

Jag tror att första gången jag hörde citatet i titeln var det antingen Jeff Patton eller Jeff Gothelf som yppade det, men det är säkerligen äldre än så.

Jag har egentligen endast jobbat i ett regelrätt vattenfallsprojekt (dvs. hårt strukturerad produktframtagning uppdelad i diskreta enheter) så jag har svårt att uttala mig om hur produktledningsspelet såg ut före den agila rörelsen klev in på banan. Baserat på min lilla erfarenhet, en massa läroböcker samt vetskapen att de flesta tog Winston Royce beskrivning av en trasig modell som en rekommendation, så tänker jag mig att förbättringsarbete pågick inom varje versionsarbete och man lade till funktionalitet för varje funktion. Det som förbättrades var att man eliminerade buggar. Jag tror att fas 2 verkligen fanns, om än bristfälligt.

När bl.a. Agile äntrar banan, en massa år efter Royce essä, ligger fokus på att få till en kontinuerlig feedbackcykel med så kort tid mellan varje steg som möjligt. Detta ger upphov till att det faktiskt kan och får ske förbättring även mellan versioner. Man får en möjlighet att ha en mer kreativ och utforskande process där det är helt okej (nåja) att sikta fel i första versionen för att det går att sikta mer rätt i efterföljande versioner. Man brukar säga att man inte tänkte på UX när det agila manifestet togs fram, men man möjliggjorde ett tätare samarbete mellan designavdelningen och utvecklingsavdelningen som var få förunnat innan dess.

Jag hittade ett par bilder på Internet, som jag inte vet var de kommer ifrån. Den första illustrerar varför man bör iterera.

iteration

Men ett antal år senare försvinner fas 2. När de gamla projektledarna inser att de med agil metodik (inte nödvändigtvis med agilt tänk) kan snabbare leverera funktionalitet, blir utvecklingen rent inkrementell. Man bygger på det man tidigare gjort och kallar det förbättring, fastän man egentligen inte rör redan färdigbyggda funktioner om de inte är uppenbart funktionellt trasiga. Om de inte matchar målgruppen eller marknaden, well, då lägger man till fler funktioner för att råda bot på det problemet. Ju snabbare man jobbar i kortare och kortare sprintar, desto mindre hinns det med någon typ av iterativt arbete varken under tiden eller mellan versioner. Man tappar fullkomligt den egentliga styrningen och kreativiteten.

Den andra bilden visar var bristen ligger i det som vanligtvis går under namnet agile, men definitivt inte är det.

AndersRamsays

Här råder en stor frustration och ilska mellan designers och utvecklare.

Här är vi idag.

Eller rättare sagt igår, för med Lean Startup-metodik i allmänhet och LeanUX i synnerhet, har vi fått ett verktyg som mer matchar agilisternas gamla slagdänga om iterativ och inkrementell utveckling.

Nu gäller det bara att vi lär de gamla projektledarna detta också.

6

Service design vs. User experience

Postades denLämna en kommentar

Jag har den senaste tiden läst en mängd blogginlägg som målar upp Service design och User experience design som motparter i någon form av krig. Jag ser dem som kompletterande.

Service design har ett holistiskt angreppssätt, det innebär att man inte bryr sig om vilken typ av gränssnitt man behandlar. Människa – maskin, människa – omgivning, människa – människa, det är helt egalt för en service designer. Inom Service design har man metoder för att dels förstå människors behov och dels strategiskt definiera vad som behöver göras för att förbättra upplevelsen.

User experience design har ett mer snävt angreppsätt. Man fokuserar nästan uteslutande på gränssnittet mellan människor och maskiner, och idag betyder det att det i de allra flesta fall är människans möte med internetbaserade tjänster och applikationer. Inom User experience design har man metoder för att dels förstå människors behov (ex. användarstudier), dels strategiskt definiera vad som behöver göras för att förbättra upplevelsen (ex. effektkartläggning och upplevelsekartläggning) och dels skapa den nya upplevelsen (ex. interaktionsdesign).

sdvsux

Service design har en del sköna insiktsmetoder som User experience designers kan lära av. User experience design har en hel del framställningsmetoder (ex. prototyping) som service designers kan lära av. Service design lider av bristen att inte ta en produkt från idé till färdigt skick och User experience design lider av att inte se helheten.

Hur dessa ämnen kan vara något annat än kompletterande har jag svårt att förstå, om man inte tolkar Service design som bara applicerbart på kundtjänst eller User experience design som bara design utan användarmöten …

4

5 tips för bäst långsiktig användarupplevelse

Postades denLämna en kommentar

Det är egentligen inte så mycket som man behöver komma ihåg som UX:are för att göra ett bra jobb. Enligt mig är det endast de här fem punkterna. 😉

  • Träffa riktiga användare. Jeffrey Liker säger, i boken The Toyota Way: ”In my Toyota interviews, when I asked what distinguishes the Toyota Way from other management approaches, the most common first response was genchi gembutsu [go and see] […] You cannot be sure you really understand any part of any business problem unless you go and see fo yourself firsthand.” Det här torde vara en självklarhet för en UX:are, men vi tenderar att slå på stort och göra kostsamma användarstudier samt inte så ofta. Mitt förslag är att bestämma en dag varje vecka som man ser till att träffa användare på. Detta även fast man kanske inte har något specifikt att ta reda på, det är värt att bara sitta ner och småprata en stund. Gör inte en stor grej av det, gör det normalt.
  • Sluta leverera leverabler, leverera värde. Användarstudier och interaktionsdesign som kontinuerligt kommuniceras till team och kunder ger mycket mer värde än en detaljerad wireframe i ett worddokument. Följ Build-Measure-Learn-loopen från Lean Startup kontinuerligt för att alltid vara säker på att du är på rätt spår istället för bara verifiera med team/kunder och validera med användare när produkten är ”klar”. Du bör alltid se din produkt som en hypotes som behöver valideras så fort som möjligt för att minimera slöseri med tid och resurser. Att bygga en Minimum Viable Product som sedan kan slängas om man inser att man bygger på fel produkt, det är vad som ger förståelse och hjälper till att sikta rätt i nästa iteration. Som Eric Ries argumenterar: ”Success is not delivering a feature; success is learning how to solve the customer’s problem”.
  • Släpp sargen och skissa bums. Vi strävar efter så korta feedbackloopar som möjligt. Ju snabbare idéer visualiseras desto fortare får du feedback. Så, använd penna och papper. Håll dig borta ifrån trögjobbade Adobe-produkter. Eller som agila manifestet säger, ”Enkelhet – konsten att maximera mängden arbete som inte görs – är grundläggande.” Försök att alltid vara transparent gentemot din omgivning. Sätt kontinuerligt dina skisser på en vägg så kan du lättare få feedback. Isen är hal, men du kan göra det!
  • Samarbeta, samarbeta, samarbeta!!! Skapa möjligheter till samarbete överallt och hela tiden. Även fast det kanske inte känns så, så kommer detta göra dig snabbare och låta dig gå djupare på designen, samtidigt. Våga riva väggarna till din silo. Att pardesigna med utvecklare, att ta med dem och produktägaren på användarstudier, att involvera hela teamet i en design studio-session, m.m. Möjligheterna är många och de ger alltid mervärde.
  • Förbättra kontinuerligt. För att veta att vi alltid gör rätt sak, så måste vi kontinerligt kämpa, både för en bra process (exempelvis att se till att träffa användare frekvent) och för en bra design. Vi måste hela tiden utvärdera vad vi gör och anpassa oss. Vårt verktyg för detta kan vara att ha ett process-retrospektiv varje vecka (och agera på problem som dyker upp där). Som UX:are har vi en stor verktygslåda, men varje verktyg måste anpassas och slipas för att vara optimalt.

Se, det var väl inte så svårt. Nu är det din tur.

0