2. Agila manifestet
Vi finner bäFre säF aF utveckla programvara
genom aF utveckla själva och hjälpa andra aF utveckla.
Genom deFa arbete har vi kommit aF värdesäFa:
Individer och interak/oner framför processer och verktyg
Fungerande programvara framför omfaFande dokumenta/on
Kundsamarbete framför kontraktsförhandling
Anpassning /ll förändring framför aF följa en plan
Det vill säga, medan det finns värde i punkterna /ll höger,
värdesäFer vi punkterna /ll vänster mer.
Agile UX = True | Mar/n Christensen | 2010‐10‐21
3. 12 principer
Vår högsta prioritet är aF /llfredställa kunden Fungerande programvara är främsta måFet på framsteg.
genom /dig och kon/nuerlig leverans Agila metoder verkar för uthållighet.
av värdefull programvara. Sponsorer, utvecklare och användare skall kunna
Välkomna förändrade krav, även sent under utvecklingen. hålla jämn utvecklingstakt under obegränsad /d.
Agila metoder utnyFjar förändring /ll kundens Kon/nuerlig uppmärksamhet på förstklassig teknik
konkurrensfördel. och bra design stärker anpassningsförmågan.
Leverera fungerande programvara oWa, med Enkelhet – konsten aF maximera mängden arbete
eF par veckors /ll eF par månaders mellanrum, som inte görs – är grundläggande.
ju oWare desto bäFre. Bäst arkitektur, krav och design
Verksamhetskunniga och utvecklare måste arbeta växer fram med självorganiserande team.
/llsammans dagligen under hela projektet. Med jämna mellanrum reflekterar teamet över
Bygg projekt kring mo/verade individer. hur det kan bli mer effek/vt och justerar
Ge dem den miljö och det stöd de behöver, siF beteende däreWer.
och lita på aF de får jobbet gjort.
Kommunika/on ansikte mot ansikte är det bästa ‐ AgileManifesto.org
och effek/vaste säFet aF förmedla informa/on,
både /ll och inom utvecklingsteamet.
Agile UX = True | Mar/n Christensen | 2010‐10‐21
4. Stories & Epics
As a
[stakeholder]
I want [feature]
so that [benefit]
Agile UX = True | Mar/n Christensen | 2010‐10‐21
5. Stories & Epics
As a customer
As a
I [stakeholder]
want to control
my account from
I want [feature]
so that [benefit]
an ATM so life
Agile UX = True | Mar/n Christensen | 2010‐10‐21
6. Stories & Epics
As a customer
As a
I [stakeholder]
want to control
my account from
I want [feature]
so that [benefit]
an ATM so life
As a customer
I want to deposit
money
so that it feels quick
and safe
Agile UX = True | Mar/n Christensen | 2010‐10‐21
7. Stories & Epics
As a customer
As a
I [stakeholder]
want to control
my account from
I want [feature]
so that [benefit]
an ATM so life
As a customer As a customer
I want to deposit I want to see my
money transaction story
so that it feels quick so that I feel in
and safe control
Agile UX = True | Mar/n Christensen | 2010‐10‐21
8. Product Backlog
ID Story Importance Estimate Demo Notes
As a customer Log in, open deposit Need an UML
I want to deposit page, deposit €10, go sequence diagram.
1 money 30 5 to my balance, check No need to worry
so that it feels quick that it has increased about encryption
and safe by €10. right now.
Log in, click on
As a customer
transactions. See Use paging to avoid
I want to see my
transactions. Do a large DB queries.
2 transaction story 28 8
deposit. Go back to Design similar as the
so that I feel in
transactions. Check view users page.
control
that the new deposit
Agile UX = True | Mar/n Christensen | 2010‐10‐21
11. Scrum
Sprint planning
Del av Product Backlog
skapar en Sprint Backlog
Sprint
1-5 veckor
Agile UX = True | Mar/n Christensen | 2010‐10‐21
12. Scrum
Sprint planning
Del av Product Backlog
skapar en Sprint Backlog
Sprint
1-5 veckor
Daily Scrum
En kort projektöversikt
en gång per dygn
Agile UX = True | Mar/n Christensen | 2010‐10‐21
13. Scrum
Sprint planning
Del av Product Backlog
skapar en Sprint Backlog
Sprint
1-5 veckor
Sprint review Daily Scrum
Något körbart En kort projektöversikt
presenteras en gång per dygn
Agile UX = True | Mar/n Christensen | 2010‐10‐21
14. Scrum
Sprint retrospective Sprint planning
?
Kontinuerlig Del av Product Backlog
processförbättring skapar en Sprint Backlog
Sprint
1-5 veckor
Sprint review Daily Scrum
Något körbart En kort projektöversikt
presenteras en gång per dygn
Agile UX = True | Mar/n Christensen | 2010‐10‐21
15. Risk Värde
Risk
Hög
Undvik Gör först
Lågt Högt
Värde
Gör sist Gör sedan
Låg
Agile UX = True | Mar/n Christensen | 2010‐10‐21
18. Effektkartläggning
Effekt
Varför ska vi
göra detta?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
19. Effektkartläggning
Mål-
grupp
Effekt
Mål-
grupp
Mål-
grupp
Varför ska vi
göra detta?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
20. Effektkartläggning
Vilka är de
som ska skapa
effekterna? Mål-
grupp
Effekt
Mål-
grupp
Mål-
grupp
Varför ska vi
göra detta?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
21. Effektkartläggning
Mål
Vilka är de
som ska skapa
effekterna? Mål-
grupp
Mål
Mål
Effekt
Mål-
grupp
Mål-
grupp
Mål
Mål
Varför ska vi
göra detta?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
22. Effektkartläggning
Mål
Vilka är de
som ska skapa
effekterna? Mål-
grupp
Mål
Mål
Effekt
Mål-
grupp
Mål-
grupp
Mål
Mål
Varför ska vi
göra detta?
Vad vill/behöver
målgruppen?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
23. Effektkartläggning
Åtgärd
Åtgärd
Åtgärd
Åtgärd Mål
Åtgärd
Vilka är de
som ska skapa
effekterna? Mål-
Åtgärd
grupp
Mål
Mål
Effekt
Mål- Åtgärd
grupp
Mål-
Åtgärd grupp
Mål
Mål
Varför ska vi
göra detta?
Åtgärd
Åtgärd
Vad vill/behöver
målgruppen?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
24. Effektkartläggning
Åtgärd
Åtgärd Hur ska produkten Åtgärd
utformas?
Åtgärd Mål
Åtgärd
Vilka är de
som ska skapa
effekterna? Mål-
Åtgärd
grupp
Mål
Mål
Effekt
Mål- Åtgärd
grupp
Mål-
Åtgärd grupp
Mål
Mål
Varför ska vi
göra detta?
Åtgärd
Åtgärd
Vad vill/behöver
målgruppen?
Agile UX = True | Mar/n Christensen | 2010‐10‐21
25. Effektkartläggning
Effekt
Attrahera fler
kunder
Målgrupp
Familjer Affärsmän Ungdomar
Användbarhetmål
Vill känna sig Behöver spara
trygga pengar
Åtgärd
Hotellrumsdörrar Hotellrumsdörren Billigare rum, även
låsbara från öppnas utåt (för de större
insidan paniksituationer) familjerummen
Agile UX = True | Mar/n Christensen | 2010‐10‐21
26. Effektbackloggen
Effekt Målgrupp Användbarhetsmål
ID (mätbar) (Persona) (mätbart) Story
Som en familj, vill vi
att hotelldörrarna
endast ska ha en
1
funktion som gör att
de endast kan låsas
På en skala från 1-7,
upp inifrån
hur trygga känner ni
er när ni bor i ett rum
på hotellet? Som en familj, vill vi
Familjer att dörren ska öppnas
Attrahera fler kunder
2 utåt så att vi vid en
(hur många?)
paniksituation lätt
kan utrymma rummet
2
Agile UX = True | Mar/n Christensen | 2010‐10‐21
31. UX Sprin/ng!
Enligt Nielsen‐Norman Group
Observation
Intervjuer
Forskning
Konkurrentstudier Kod ersätter
Storyskapande prototyp så fort som
möjligt
Storyboarding
Prototyping
Design
Användningstest
Rapportering
Kundsamarbete
Sprint 0 Sprint 1 Sprint 2 Sprint N Sprint + 1
Agile UX = True | Mar/n Christensen | 2010‐10‐21
32. UX Sprin/ng!
Enligt mig, Valtech, m.fl.
Sprint Retrospec/ve Sprint Planning
Sprint Review Start of Task 1
Start of
Task 2
Sprint N+1
Start of
Task 5
Start of Task 3
Start of Task 4
Design sessions
Usability tes/ng
Agile UX = True | Mar/n Christensen | 2010‐10‐21
33. UX Sprin/ng!
Enligt mig, Valtech, m.fl.
Sprint Retrospec/ve Sprint Planning
Sprint 0
Sprint Review Start of Task 1 Create effect map and backlog
Create basic design
Sprint 1
Start of Design sessions
Task 2 Usability testing & QA
Sprint N+1 Basic design for later sprints
Start of
Task 5 Sprint 2
Design sessions
Usability testing & QA
Basic design for later sprints
Start of Task 3
Start of Task 4
Sprint 3
Design sessions
Usability testing & QA
Design sessions Basic design for later sprints
Usability tes/ng
Agile UX = True | Mar/n Christensen | 2010‐10‐21
34. UX Sprin/ng!
Enligt AutoDesk
Sprint 0
Create backlog
Create basic design
Developer Sprint 1 Designer Sprint 1
Implement non-UI stories Design for sprint 2
Research for sprint 3
Co n
de sig
De
Developer Sprint 2 Designer Sprint 2
Implement design Test sprint 1 stories
Design for sprint 3
Co n
d sig Research for sprint 4
e De
Developer Sprint 3 Designer Sprint 3
Implement design Test sprint 2 stories
Design for sprint 4
Research for sprint 5
Agile UX = True | Mar/n Christensen | 2010‐10‐21
Ber om ursäkt för mycket svengelska i den här presentationen, men så är den agila världen :)
Oftast skippar man benefit, för det är för svårt att förstå.
Oftast skippar man benefit, för det är för svårt att förstå.
Oftast skippar man benefit, för det är för svårt att förstå.
Importance factor - vi återkommer till den
Var har vår Epic tagit vägen? I bästa fall är den sparad någonstans.
Sprint review - Produktägaren, dvs. någon med affärsperspektiv testar. Användbarhetstest sker i en testfas, som vanligt.
Sprint review - Produktägaren, dvs. någon med affärsperspektiv testar. Användbarhetstest sker i en testfas, som vanligt.
Sprint review - Produktägaren, dvs. någon med affärsperspektiv testar. Användbarhetstest sker i en testfas, som vanligt.
Sprint review - Produktägaren, dvs. någon med affärsperspektiv testar. Användbarhetstest sker i en testfas, som vanligt.
Istället för riskanalys och att försöka styra undan så ger man sig direkt på de risker som ger värde.
Vad är värde? Vem vet vad värde är? Jo, Produktägaren ...
Produktägaren skulle kunna vara en UX:are, eller UX:aren kan iallafall stort stöd för produktägaren.
UX:arens främsta jobb är att få mer substans i [benefit] och [user] i våra epics/stories.
Benefits är ju användbarhetsmål. Långsiktighet i kartläggning av mål och effekter
Det ger en annan långsiktighet än vanliga stories.
Det här formatet passar bra för Excel, som faktiskt är det verktyg som används mest för backloggen. Ett problem med den här approachen är att många agila projektverktyg inte har stöd för fler kolumner i backloggen än de vanliga.
Om man kör Scrum på riktigt, så har man ett sprintmål. Detta kan vara samma som användbarhetsmålet. Berätta om Stina.
Okej, det var planeringsfasen (som förvisso håller på kontinuerligt). Men kan inte UX:aren göra mer? Jodå!
Produktägaren skulle kunna vara en UX:are, eller UX:aren kan iallafall vara en del av teamet.
Detaljerade specar ersätts med handritade abstrakta modeller. Kommunikation framför dokumentation.
Hifi prototyper ersätts med lofi prototyper. Förlita er på människans fantasiförmåga.
Itererande och djup användaranalys ersätts med mod, mod att designa för behov (uppgifter) istället för förväntningar.
Basera design på enkla modeller, personas, istället.
Användbarhetsvalidering med många användare ersätts med ”revolving door”, en kontinuerlig ström användare, fast få.
Sprint zero tenderar att bli lååååång! Det är inte okej.
Bättre med översiktliga personas/skisser, som man kan fördjupa senare.