Prezentacja z warsztatów dot. procesu Lean UX przygotowana dla Wyższej Szkoły Europejskiej w Krakowie.
“O randce projektanta i użytkownika - czyli jak projektować produkty, które pokochają użytkownicy? Kilka słów o Lean UX.”
Jak wygląda typowy proces tworzenia nowych produktów? Co zrobić, aby uniknąć niepowodzeń i marnotrastwa czasu i pracy projektantów? Jak projektować tak, by użytkownicy pokochali nasz projekt? Oraz co Lean Startup robi poza ekosystemem startupowym?
Czym właściwie jest Lean UX i dlaczego każdy projektant powinien go znać.
O randce projektanta i użytkownika, czyli jak projektować produkty, które pokochają użytkownicy
1. O randce projektanta
i użytkownika
Joanna Ostafin
@joannaostafin
WSE | Warsztat
Kraków, 13 lipca 2017
czyli jak projektować produkty, które pokochają użytkownicy
2. Joanna Ostafin
Lead UX designer & Co-founder Project: People
• Współzałożyciel Krakowskiej Inicjatywy
Designerskiej.
• Projektuję od 2008 roku
• Fanka leanowego podejścia do projektowania i
zarządzania
• Prowadząca zajęcia dot. Lean UX oraz Budowania
stron internetowych i aplikacji mobilnych na WSE
15. Ćwiczenie 1
Jak wyglądałby proces pracy nad tym projektem?
Opiszcie w kolejnych krokach i oceńcie, ile dni
zajęłyby Wam poszczególne etapy.
10 min.
16. …i wtedy okazuje się, że użytkownicy nie
rozumieją aplikacji/nie chcą z niej korzystać etc.
17. Po jakim czasie dowiadujecie się, że aplikacja
nie podoba się użytkownikom, nie rozumieją jej
i nie chcą z niej korzystać?
Ile czasu zajmie wprowadzenie jakiejś zmiany?
21. User Experience (UX)
Doświadczenia użytkownika (pozytywne lub negatywne)
towarzyszące mu podczas korzystania z danej usługi lub
produktu.
22. Lean UX
Podejście do projektowania opierające się na pracy
zespołowej, którego celem jest budowanie właściwych
produktów w krótszym czasie i bez marnotrawstwa zasobów.
23. Typowy proces projektowania (tzw. waterfall)
wygląda trochę jak randka w ciemno.
Discover
Define
Design
Develop
Deliver
40. Ćwiczenie 2
Wróćmy do naszego projektu i zróbmy proto-persony.
• Kto jest Waszym użytkownikiem?
• Jakie mają cele, problemy, co ich motywuje, co jest dla nich ważne?
• Jaki ich problem jest najważnieszy / chcecie go rozwiązać?
• Jaka zmiana w ich życiu/zachowaniu pokaże Wam, że rozwiązaliście
ich realny problem?
10 min.
41. Ćwiczenie 2
I dalej:
• Wylistujcie rozwiązania, które pomogą Wam osiągnąć cel Waszego
użytkownika / rozwiązać problem
• Jakie jest najbardziej ryzykowne rozwiązanie, ale jednocześnie
oferuje największą wartość?
• Jak je możecie przetestować?
10 min.
44. I znów:
Po jakim czasie dowiedzieliście się, że coś w
aplikacji nie gra?
Po jakim czasie dostaliście pierwszy feedback i mogliście
wprowadzić zmiany?
46. Podsumowując Lean UX:
• Współprojektowanie - cały zespół pracuje w jednym czasie
• Wszyscy rozumieją klientów (nie tylko UX designerzy)
• Nie ma design-hero
• Komunikacja zamiast dokumentacji
• Zdobywanie wiedzy
• Dostarczanie wartości, nie funkcjonalności
• Weryfikacja zamiast przeczucia
• Szybkość działania, czas
47. Czego chcieliście się dowiedzieć?
• czegoś o projektowaniu aplikacji
• związek designera z userem
• jak współpracować z programistami + jak dobrze przygotowywać projekt dla programisty
• jak ogólnie tworzyć projekt - proces UX?
• jak znaleźć pracę, jakie są wymagania na rynku pracy, jakie programy warto znać + jak
zacząć pracę jako UX + w jakim stopniu i co powinno znaleźć się w portfolio z punktu
widzenia pracodawcy
• jedno konkretne narzędzie w pracy UXa
• jak wpłynąć na użytkownika jako designer lub PM
• słaby przepływ informacji w firmie - jak temu przeciwdziałać?
• jak skłonić do testowania rozwiązań, zwłaszcza w małych projektach
49. Gdzie jest User Research /
Badania w Lean UX?
• Wszędzie! Ciągły kontakt z użytkownikiem jest podstawą Lean UX.
• Sprint researchowy - zrób go w myśl zasady “quick & dirty”
50. Jak “dopalić” tworzenie
MVP w procesie Lean UX?
• Design System może być baaaaaardzo pomocny.
Fajne przykłady Design Systemów:
• Salesforce: https://www.lightningdesignsystem.com/
• Atlassian: https://atlassian.design/
51. Pod koniec dnia, ani użytkowników, ani biznesu
nie będzie interesowało, ile dokumentacji
wyprodukowałeś, czy jakiej metody użyłeś, ale czy
Twój produkt działa i rozwiązuje ich problem.