För några veckor sedan var jag och två av Aftonbladets produktägare på en kurs om produktägarrollen i Scrum. Kursledare var Jeff Patton, Scrum coach och usability expert. Jag förväntade mig en djupdykning i Scrum och produktägar-rollen men det avhandlades ganska snabbt. Kursen handlade till största del om ett moment  som inte finns definierat  i Scrum, fasen innan man har user stories till en Product backlog. Denna fas, från ide till backlog, kallar Patton m.fl. för  Product Discovery och tanken är att på ett strukturerat sätt ta en ide om en produkt
och stegvis bryta ner och förädla iden till något som Scrum-teamet kan använda för att bygga produkten.

Idea backlog

Arbetet börjar med en ide om en produkt eller en produktförbättring eller ett problem som behöver lösas. Runt denna ide ställer man följande frågor:

• Vad är det? En kort beskrivning av produkten eller produktegenskapen.
• För vem? Vem är användaren/köparen?
• Varför? Vad finns det för fördel för vår organisation att bygga denna produkt?

Produktmål

För att formulera ett mål börjar man med nuläge och önskat läge samt vad som skiljer dessa åt. Tex kan nuläge vara att användarna är missnöjda med produkten för att det är för krångligt att göra det man vill. Önskat läge är då att användarna är nöjda och att de upplever det enkelt att göra det som de vill. Detta är mätbart och testbart genom tester/intervjuer.

Enkla personas

Genom att fördjupa sig i ”För vem” kan vi skapa enkla personas som beskriver användarna. Förmodligen finns stor kunskap och erfarenhet om användarna i den egna organisationen. Eventuellt behöver denna kunskap förädlas genom observationer, intervjuer, fokusgrupper och tester. Därefter kan enkla personas tas fram. De personas vi använde på kursen bestod av detta:

• En bild
• Kort beskrivning; namn, ålder, yrke osv
• Beteende; beskriv en situation som är typisk för personen
• Följder; vilka produktegenskaper är viktiga för att stötta personens beteende?

User story map

Personas är en viktig input till User stories. Vem, vad och varför finns i båda ”verktygen”. Med en user story map organiseras user stories runt en användare eller ett värde. Stories är ”sub-tasks” som grupperas under ”user-tasks”. User-tasks grupperas in under user-activity.

Planera produktreleaser

När man har en story map blir nästa steg att dela mängden av stories i olika releaser. Detta gör man genom att dra horisontella linjer över sin story map. Dessa linjer avgränsar innehållet i olika releaser av produkten. Hur ska man sedan avgöra vad som ska med i vilken release? Ett sätt är att sätta en eller flera personas vid varje release. Fyll sedan releasen med funktionalitet för dessa personas. Den första releasen blir speciell då uppgiften är att utveckla endast det viktigaste. Patton hänvisar till Marty Cagans ide om en minimal gångbar produkt (MVP-Minimal Viable Product). Vad är den minsta mängd funktionalitet som ska med för att vi ska kunna uppfylla ett delmål med produkten?

Resultatet av detta arbete blir en beskrivning av produkten på user-story nivå med en releaseplan. Samtidigt med detta arbete bör man arbeta med övergripande UI design, tex enkla pappersskisser på storyboards som sedan ligger till grund för mer detaljerad UI design. Med hjälp av denna plan skapas en product backlog och därefter kan det iterativa arbetet med sprintar börja.

Roller

Patton föreslår två grupper:

• Product Discovery Team – Detta är det team som genomför fasen product discovery. Teamet består av produktägare, utvecklare (tex. lead developer) samt user experience expert
• Delivery Team- Utvecklingsteamet, ett Scrum team där utvecklaren i product discovery team ingår.

Sammanfattning

Product discovery är en metod för att ta nya ideer och förbättringar av produkter till implementationsarbetet på ett strukturerat sätt. Genom att ”vem” är i fokus samt att man använder personas som ett stöd i prioriteringsarbetet får man användarfokus hela vägen. På Aftonbladet testar vi detta arbetssätt i redesign-projektet.

Länktips:

Jeff Patton’s Agile product design: http://www.agileproductdesign.com/

Jeff Patton twitter: https://twitter.com/#!/jeffpatton

Marty Cagan, Inspired – How to create products customers love: http://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408/

Scrum: http://www.mountaingoatsoftware.com/topics/scrum

Personas: http://www.omwebb.se/personas-gor-webbplatsens-malgrupper-levande/

Dropbox som Minimal Viable Product: http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/

Det grymma med att vara på en bred utvecklarkonferens som Øredev är ju att det är lätt att gå lite utanför den vanliga fåran, där man brukar vara.

Jag har gått på några UX presentationer idag som varit rätt bra. Om man ska vara riktigt generös med tolkningen av användare så var jag på en igår också på temat ”API the hidden UI”. Tanken är att den som kommer använda ditt API också är någon form av användare, en stor skillnad är dock att ett GUI kan ändras efter att det börjat användas, ett API kan däremot inte ändras utan att saker verkligen går sönder för användare. I princip kan man säga (ok, lite hårddraget) att man bara har en chans att göra API:t rätt. När det publicerats är det användarna som äger det. Inte själva implementationen, men du kan inte ändra hur som helst längre.

Flera av lärdomarna där har jag hört upprepas idag på mer traditionella UX presentationer t ex:

• När man får förfrågningar om nya funktioner får man det oftast i form av ett halvfärdigt lösningsförslag. Försök att fokusera på det underliggande problemet istället. En princip som kan användas är att det inte ska bli bättre bara för en användare utan för många. Beställaren ska kunna motivera varför, för vilka den löser vilket problem.
• Använd konventioner som är utbredda. Analogt med att användare spenderar mest tid på andra webbplatser än din egen, så spenderar API-användare mest tid med andra API:er än ditt. Ett exempel är att en relation mellan brukar benämnas parent-child. Om man i sitt API kallar det för father kommer det bli förvirrande.

Jeff Patton presenterade två klassiska ”failure modes” när man utvecklar och jobbar (mindre bra) med UX:

1. Man antar att ”om jag gillar det så kommer användarna också göra det”
2. Man frågar användare direkt vad de vill ha och ger användare skulden om det inte blir bra.

Talare: Nate Bolt (Bolt|Peters)
http://www.web2expo.com/webexny2011/public/schedule/detail/21258

Hur bygger vi bra saker för våra användare? Nate pratar om enkelheten i att använda olika verktyg i researcharbetet för att få feedback och kommunicera med testgrupper och besökare i utvecklingsprocessen.

Research and Creativity
Det pratas ofta om research inom marknad men vi bör fokusera ännu mer på research inom User Experience. Det finn flera olika verktyg som hjälper oss i analysarbetet och dessa ger oss bättre beslutsunderlag i utvecklingsprocessen. Arbeta med prototyper, Wireframes & Sketches.

2 principer
#1 Kombinera online metoder – det finns många bra
#2 Tid är allt

Man kan skapa och mäta upplevelsen på olika sätt och med olika verktyg.
Insikt, statistik, betraktelse. Olika verktyg för olika syften. Definiera ditt behov! Heatmaps för att fånga beteenden kopplat till frågeformulär.

Vem testar vi på?
Hur hittar vi en grupp med personer som vi kan testa på i reseaarchsyfte?
– Någon utanför, vänner, riktiga kunder, panelundersökningar, gruppmaillistor
usertesting.com tillhandahåller testpersoner. Det finns många bra alternativ.

Hur kan vi använda det här?
Hitta ett verktyg som passar för behovet och börja testa det tidigt i planerings- och designfasen. Det kommer förhoppningsvis ge oss bättre beslutsunderlag och trygghet i att vi utvecklar applikationer som våra användare vill ha, förstår och kan använda.

Det här låter som ett intressant verktyg http://www.dscout.com/
Anpasssat för App driven research
”capture user experiences in context and in the moment, describe, design, invite”

Tips på fler verktyg: http://remoteresearch.ch/tools
Automatiserade remote research tools (Usabilla, Loop11, Plainframe)
Usability tests: Låt användaren klicka runt, mät, följ upp med heatmap. Verktygen tillåter feedback kopplat till händelser.

Talare: Nick Disabato – Interaktionsdesigner från Chicago.

Nick berättar om ”Poor expectation management ” och olika negativa mönster som visar tydliga briser i design av webbapplikationer. Dessa mönster återfinns i allt från betaltjänster och annonser där tjänsten förmedlar fel information till besökaren.
Som användare är det ofta otydligt vad som händer med ex. min information i sociala medier och e-handelstjänster vid registrering och annonser som man klickar på.

Applikationer inger ofta falska intentioner och man får ofta något annat än vad man tror i ex. en kampanj som kan vara en inbjudningar till pyramidspel eller svårigheter att avregistrera sig från en webbtjänst. Tilliten för varumärket, produkten eller tjänsten påverkas mycket negativt vid dessa tillfällen.

Hur skulle vi då kunna undvika och förbättra för användaren och hur skulle då ett businesscase se ut? Vad kan vi mäta och hur kan vi skapa värde genom att börja använda bra design och UX?

Några användbara nyckeltal

• Besökarfrekvens
• Antal samtal från besökare
• Antal nya registreringar
• Antal problem på sociala medier

Hur kan vi bygga bättre design för att förhindra ”Poor expectation management”

• Hirarki – Vad vill vi att användaren ska göra på sidan ex. logga in, posta information, interagera etc.tydliggör förväntningar och intentionerna för besökaren.
• Timing – Presentera information i rätt sammanhang.
  Ex. i ett köpflöde kan man presentera flera produkter efter färdig betalning.
• Defaults – Var tydlig i vad man kan ändra på som användare
  Ex. i ett formulär eller editering av information.
• Simplicity – vs Complexity
  Ofta vanligt i sociala medier och här kan man jämför rättighetsinställningar för ex. Twitter och Facebook.
• Copy & Tone – Hur kommunicerar vi med våra användare, vilken ton använder vi?