Najlepsze produkty nie biorą się z "dobrze zdefiniowanych wymagań", ale z głębokiego zrozumienia potrzeb użytkowników oraz ciągłego testowania nowych konceptów. Sukces produktu jest również wynikiem współpracy różnych grup interesariuszy.
Prezentacja z warsztatów przeprowadzonych w ramach WUD Silesia 2012 (www.wudsilesia.pl).
3. O czym w tym roku?
• Użytkownik
o Poziomy „User Experience”
o Modele mentalne
o Persony
• Produkt
o Minimum viable product
o Product backlog
o Product owner
• Proces
o Koncepcja
o Developement
o Post launch
3
12. Persony bywają różne
• Tworzone na bazie wiedzy o użytkownikach
o Zwieńczenie procesu badawczego
o Skuteczne narzędzie komunikacji
• Tworzone na bazie oczekiwań
o Unikajcie „radosnej twórczości”
• Szczegółowość opisu dobierana w
zależności od grupy odbiorców
12
16. Ćwiczenie #1
• Podzielcie się na grupy
• Stwórzcie profil persony
o Osoby starszej
o Osoby młodszej
• Uwzględnijcie stosunek persony do
płatności elektronicznych
• Piszcie wyraźnie! ;)
• Czas: 15 minut
16
20. Minimum viable product
The minimum viable product (MVP) is that version of
a new product which allows a team to collect the
maximum amount of validated learning about
customers with the least effort.
- Eric Ries
20
21. Minimum viable product
The minimum viable product (MVP) is that version of
a new product which allows a team to collect the
maximum amount of validated learning about
customers with the least effort.
- Eric Ries
An MVP is not a minimal product!
21
35. User stories
• Każde story składa się z trzech części
o roli użytkownika
o opisu celu
o opisu zysku
• Jako [użytkownik] chcę [cel] po to aby [zysk]
• Dobrze opisane story uwzględnia perspektywę
użytkownika
• Nie pomyl „co” (cel użytkownika) z „jak” (czynność,
którą musi wykonać)
35
36. Ćwiczenie #2
• Wymieńcie się personami
• Stwórzcie backlog dla
o Banku – strona internetowa
o Banku – aplikacja mobilna
• Usługa powinna zaspokajać podstawowe potrzeby
użytkownika (przelewy, historia płatności, etc.)
• Bank nie wie, jakie dodatkowe usługi zaoferować
• Inspirujcie się personą
• Czas: 20 minut
36
38. User-centered design
• Opisywanie produktu z perspektywy wykonawcy
ogranicza nasze myślenie o tym co jest najlepsze
dla użytkownika
• Zły opis problemu może utrudnić znalezienie
optymalnego rozwiązania
• http://bronikowski.com/1572/prawda-dostepu-
wymagaja-podstepu
38
47. Definiowanie wymagań
• Czasami wybór kolejności dla user stories jest
trudny
• Nie ma sensu pytać co jest ważniejsze dla
konstrukcji samochodu: koła czy silnik
• Samochód nie ruszy bez jednego ani drugiego
• … ale może się okazać, że rozpoczęcie od kół
obniży koszt montażu silnika (lub odwrotnie)
47
50. Definiowanie wymagań
• Rolą PO jest definiowanie wymagań
• Trzeba jak najszybciej dowiedzieć się w co warto
zainwestować czas zespołu
• Cała zabawa rozpoczyna się w momencie
weryfikacji hipotez biznesowych
• Zespół ma prawo pytać „dlaczego?”
50
53. Ćwiczenie #3
• Przeróbcie product backlog do postaci
modelu mentalnego
• Uzupełnijcie brakujące miejsca
• Pamiętajcie o odpowiednim
nazewnictwie
• Czas: 20 minut
53
64. Testować można zawsze
• Koncepcja
o Modele mentalne
o Desk research
o Testy MVP (np. landingi)
• Developement
o Paper prototyping
o Lo-fi mockups
o Wywiady
64
65. Testować można zawsze
• Koncepcja
o Modele mentalne
o Desk research
o Testy MVP (np. landingi)
• Developement
o Paper prototyping
o Lo-fi mockups
o Wywiady
65
66.
67. Testować można zawsze
• Koncepcja
o Modele mentalne
o Desk research
o Testy MVP (np. landingi)
• Developement
o Paper prototyping
o Lo-fi mockups
o Wywiady
• Post Launch
o Testy usability
o Remote testing
o Analiza konwersji
67
68. Testować można zawsze
• Koncepcja
o Modele mentalne
o Desk research
o Testy MVP (np. landingi)
• Developement
o Paper prototyping
o Lo-fi mockups
o Wywiady
• Post Launch
o Testy usability
o Remote testing
o Analiza konwersji
68