Lean UX i Agila Team

Editor's Notes

• #4: På grund av att många försöker få med “allt” I en IT-upphandling, är det endast 40% av det som byggs som gör nytta I digitala tjänster och produkter. Hur kan vi göra för att bara bygga de 40% I stället?
• #5: Man gör upp en jättenogran plan I förväg, en så kallad förstudie…. och man försöker få med så många krav som möjligt som man TROR måste finnas med.
• #7: Backloggen skapas i förväg, vi gör en plan – som vi sedan levererar på. Då kommer lärdommen inte förens i slutet av leveransen, och vi tar en enorm risk att misslyckas.
• #10: Metafor: gå och handla, samma väg varje dag. Complex, där man är I ny terräng och måste ta ut kompassriktning för att hitta.
• #11: Vi måste upptäcka vad det är vi ska bygga! Vi ser bara en liten del av bilden först. Men vi drar ofta förhastade slutsatser av det, och tror oss kunna göra en plan ändå.
• #12: Vi ser lite till, men fortfarande inte lätt att få en överblick.
• #14: Först när vi ser helheten förstår vi hur fel vi hade från början, men då är det ofta för sent att ändra.
• #16: Storyn med Göteborg… planerar du hela resan i förväg?
• #18: Vi måste få lärdomar tidigare I projekten, och löpande under hela utvecklingsprojektet. Vi behöver göra experiment både innan release, och efter release.
• #20: Varför ska något göras? Vad är behoven? Hur ser det ut och fungerar?
• #21: Så här kan den övergripande processen se ut när man jobbar i Agila team.
• #22: När vi aplicerar Lean UX så kan vi jobba i de Agila teamen med både att utforska vad vi ska bygga, och hur vi ska bygga det. Vi behöver involvera stakeholders, användare och alla kompetenser som behövs.
• #23: När teamet har varit delaktiga att bygga backloggen på ett utforskande sätt, tex som en user story map, så betyder det att teamet kan fortsätta att utforska mer I detalj I respektive sprint, och leverera lärdomar och nytta till användarna löpande. Att teamet jobbar fokuserat och utforskar så snabbt som möjligt vad som ska byggas och hur gör att lösningshöjden ökar, och vi bättre kan scopa utifrån nytta och minska risker. Fixa så att det är en user story map ist för en backlog
• #24: När teamet har varit delaktiga att bygga backloggen på ett utforskande sätt, tex som en user story map, så betyder det att teamet kan fortsätta att utforska mer I detalj I respektive sprint, och leverera lärdomar och nytta till användarna löpande. Att teamet jobbar fokuserat och utforskar så snabbt som möjligt vad som ska byggas och hur gör att lösningshöjden ökar, och vi bättre kan scopa utifrån nytta och minska risker. Fixa så att det är en user story map ist för en backlog
• #26: I Lean Ux så utvärderar vi löpande alla delar I våra antaganden och hypoteser. Många team itererar I oändligheten I interaktionsdesignen, utan att reflektera över att det kan vara fel på själva lösningen I sig, eller målgruppen. Det har nog hänt I de flesta produktorganisationer att man sent upptäcker att funktionen man har arbetat I flera veckor på att förfina och gjort jättebra användbarhetsmässigt, inte är någon funktion som användaren vill använda. Vi behöver testa tidigt om målgruppen är rätt, att löningsförslaget är rätt, att interaktionsdesignen och flöden är användarhetsmässigt bra, men också att målen är rätt satta.
• #27: I Lean Ux så utvärderar vi löpande alla delar I våra antaganden och hypoteser. Många team itererar I oändligheten I interaktionsdesignen, utan att reflektera över att det kan vara fel på själva lösningen I sig, eller målgruppen. Det har nog hänt I de flesta produktorganisationer att man sent upptäcker att funktionen man har arbetat I flera veckor på att förfina och gjort jättebra användbarhetsmässigt, inte är någon funktion som användaren vill använda. Vi behöver testa tidigt om målgruppen är rätt, att löningsförslaget är rätt, att interaktionsdesignen och flöden är användarhetsmässigt bra, men också att målen är rätt satta.
• #28: I Lean Ux så utvärderar vi löpande alla delar I våra antaganden och hypoteser. Många team itererar I oändligheten I interaktionsdesignen, utan att reflektera över att det kan vara fel på själva lösningen I sig, eller målgruppen. Det har nog hänt I de flesta produktorganisationer att man sent upptäcker att funktionen man har arbetat I flera veckor på att förfina och gjort jättebra användbarhetsmässigt, inte är någon funktion som användaren vill använda. Vi behöver testa tidigt om målgruppen är rätt, att löningsförslaget är rätt, att interaktionsdesignen och flöden är användarhetsmässigt bra, men också att målen är rätt satta.
• #29: I Lean Ux så utvärderar vi löpande alla delar I våra antaganden och hypoteser. Många team itererar I oändligheten I interaktionsdesignen, utan att reflektera över att det kan vara fel på själva lösningen I sig, eller målgruppen. Det har nog hänt I de flesta produktorganisationer att man sent upptäcker att funktionen man har arbetat I flera veckor på att förfina och gjort jättebra användbarhetsmässigt, inte är någon funktion som användaren vill använda. Vi behöver testa tidigt om målgruppen är rätt, att löningsförslaget är rätt, att interaktionsdesignen och flöden är användarhetsmässigt bra, men också att målen är rätt satta.
• #30: I Lean Ux så utvärderar vi löpande alla delar I våra antaganden och hypoteser. Många team itererar I oändligheten I interaktionsdesignen, utan att reflektera över att det kan vara fel på själva lösningen I sig, eller målgruppen. Det har nog hänt I de flesta produktorganisationer att man sent upptäcker att funktionen man har arbetat I flera veckor på att förfina och gjort jättebra användbarhetsmässigt, inte är någon funktion som användaren vill använda. Vi behöver testa tidigt om målgruppen är rätt, att löningsförslaget är rätt, att interaktionsdesignen och flöden är användarhetsmässigt bra, men också att målen är rätt satta.
• #31: Även den grafiska deisgnen är viktig att testa, men det gör vi oftast som kvalitativt som A/B tester och inte kvantitativt som användningstester.