Lean UX i Agila Team
•Download as PPTX, PDF•
6 likes•35,652 views
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. Lean UX hjälper oss att bara bygga de 40% i stället. Mina nästa kurser inom ämnet Lean UX: https://crisp.se/kurser/kurstyper/product-discovery-med-lean-ux Jeff Gothelfs kurs för managers: https://crisp.se/kurser/kurstyper/lean-ux-in-the-enterprise Upphandling med Lean UX och Agila kontrakt för upphandling med minskad waste: https://crisp.se/kurser/kurstyper/certifierad-agil-bestallare
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Similar to Lean UX i Agila Team
Similar to Lean UX i Agila Team (20)
More from Mia Kolmodin
More from Mia Kolmodin (6)
Lean UX i Agila Team
- 1. mia.kolmodin@crisp.se Sluta bygga snabbt. Bygg rätt och snabbt! LEAN UX I AGILA TEAM
- 2. Det är tydligen inte lätt med stora IT projekt...
- 4. Även kallat förstudie… Jag har en plan!
- 5. Så, nu är det bara att bygga! När är ni klara?
- 6. En plan och sedan Agilt – hur går det? mia.kolmodin@crisp.se
- 9. Simple Complex Nya sätt att styra på
- 10. mia.kolmodin@crisp.se Vad ser vi i början?
- 14. Planera för vad du inte vet Vad vi faktiskt vet Vad vi vet att vi inte vet Vad vi inte vet att vi inte vet
- 16. Effektmål Något ska förändras när användaren använder systemet. • Mätbara – vi vet när vi är framme • Tidssatta – Vi vet hur mycket tid vi har och kan prioritera
- 19. PO • Varför ska vi göra det här? • Vad är visionen? • När har vi lyckats? • Vilka är effektmålen? Intressenter • Vem är användaren? • Vilka behov finns? • Vad ska vi bygga? • Hur ska det fungera? • Hur ska det kodas? • Hur blir det användbart? • Hur ska det se ut? PO + Team Tea m Användaren Användaren
- 23. Lean UX
- 25. Är det bra interaktionsdesign? Hjälper den användaren? Lösning.Målgrupp med behov Målet. mia.kolmodin@crisp.se Lean UX
- 26. Är det en bra lösning? Skapar den impact? Är det bra interaktionsdesign? Hjälper den användaren? Målgrupp med behov Målet. mia.kolmodin@crisp.se Lean UX
- 27. Är det en bra lösning? Skapar den impact? Är det bra interaktionsdesign? Hjälper den användaren? Är det rätt målgrupp? Hjälper den oss att uppnå impact? Målet. mia.kolmodin@crisp.se Lean UX
- 28. Är det en bra lösning? Skapar den impact? Är det bra interaktionsdesign? Hjälper den användaren? Är det en bra grafisk design? Skapar den rätt känsla och impact? Är det rätt målgrupp? Hjälper den oss att uppnå impact? Är målet rätt? -Får vi förväntad impact? Lean UX
- 29. Rätt lösning. Rätt interaktionsdesign Är det en bra grafisk design? Skapar den rätt känsla och ger effekt? Rätt målgrupp.Rätt mål. Lean UX
- 30. Experiment över noggrann planning Feedback från kunder över intuition Gemensamt arbete över en hjälte Vi värderar… Iterativ design över big up front design
- 32. ExperimentNya produkter Rätt målgrupp? - Intervjuer med triggermaterial Market fit – existerar behovet? - MVP – Minsta möjliga produkt för att lära oss - Landningssida och AdWords Rätt innehåll och lösningar? - Testa flöden och lösning på Lo-Fi prototyp - Bygg bara en del av tjänsten, gör resten manuellt Användbarhet - Testa på klickbar prototyp.
- 33. Experiment Befintliga produkter Är den användbar? - Utvärdera med användningstest Kan vi förbättra? - Skapa hypoteser och testa dessa genom A/B tester
- 34. mia.kolmodin@crisp.se • Specifikt • Mätbart • Accepterat • Realistiskt • Tidsbundet Effektmål
- 36. Entice Enter ExitEngage Extend mia.kolmodin@crisp.se Kundresa
- 37. User Story Map
- 38. Digitaliserad i Stories on Board
- 42. Mina kurser Beställa ny produkt Certifierad Agil Beställare Denna kurs lär ut hur man skapar grunden för ett väl fungerande samarbete redan i upphandlingsfasen, hur man behovsställer för att ge höjd för användbara lösningsförslag, hur man hittar rätt leverantör samt hur Agilt kan funka inom ramen för LOU. https://www.crisp.se/kurser/kurstyper/c ertifierad-agil-bestallare Ny produkt – från ide till backlog Product Discovery med Lean UX Lär dig jobba gemensamt i grupp för att snabbt gå från idé till skissad prototyp med användarcentrerade lösningar och validering av hypoteser löpande. Den här typen av agil kravställning, eller “behovsställning”, är ett arbetssätt som används mer och mer i moderna organisationer där man jobbar med agila utvecklingsmetoder. https://www.crisp.se/kurser/kurstyper/prod uct-discovery-med-lean-ux Lean UX I Agila Team – löpande arbete Lean Team – Continuous Discovery & Delivery med ett team På den här kursen lär sig det kors- funktionella Agila teamet hur dom snabbt kan leverera värde genom att samarbeta under sprinten utifrån hypoteser och med ett evidensbaserat arbetssätt upptäcka löpande vilka lösningar dom ska bygga. https://www.crisp.se/kurser/lean-team- continuous-product-discovery-och- delivery-med-ett-team-11-12-maj-2016 mia.kolmodin@crisp.se
Editor's Notes
- 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?
- 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.
- 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.
- 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.
- 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å.
- Vi ser lite till, men fortfarande inte lätt att få en överblick.
- 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.
- Storyn med Göteborg… planerar du hela resan i förväg?
- 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.
- Varför ska något göras? Vad är behoven? Hur ser det ut och fungerar?
- Så här kan den övergripande processen se ut när man jobbar i Agila team.
- 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.
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- Ä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.