Speaker: Arkadiusz Smółkowski
Language: Polish
Im dłużej pracujemy w branży UX, tym częściej dostrzegamy pułapki, jakie na nas zastawia nasz własny umysł.
Kto z nas nie zna stwierdzeń typu "jesteś adwokatem Klienta" czy "ja się pod tym nie podpiszę". Na takich właśnie sloganach zaburzających komunikację z klientem chciałbym się skupić.
Jak rozmawiać z klientem, zespołem developerów, działem marketingu, by przy tak rozbieżnych interesach udziałowców projektu nie zapomnieć o docelowym użytkowniku?
W szczególności chcę poruszyć aspekt pracy z różnymi klientami od Ministerstw Edukacji różnych krajów na świecie, poprzez polskie firmy ubezpieczeniowe, banki obecne na polskim rynku po pracę z Polskim Związkiem Piłki Nożnej.
Przywołam dogmaty jakimi się kieruję w swoim zawodzie i jak mi to ułatwia zachowanie dystansu do samego siebie i trzymanie się z dala od przywołanej w tytule własnej 'eksperckości'. Wyraz ten nie występuje w języku polskim. Zapożyczyłem go z jednej z firm produkującej oprogramowanie, która tak właśnie określiła swoją misję.
W wielkim skrócie wygląda to następująco:
dystans do samego siebie + szacunek do współpracowników + przestrzeganie ograniczeń budżetowych i ram czasowych = dostarczenie produktu gwarantującego satysfakcję.
4Developers: http://4developers.org.pl/pl/
2. Standardowy projekt
1. Klient jest najważniejszy
2. Zaczynamy projekt
3. ZBIERAMY wytyczne
4. KONSULTUJEMY z zespołem developerskim wykonalność projektu
5. Prezentujemy projekt klientowi
6. Prezentujemy poprawiony projekt
7. BRONIMY projektu - spotkanie
8. BRONIMY projektu – telefon
9. BRONIMY projektu - mail
10. Przekonaliśmy klienta
11. Implementujemy projekt
12. ROZMAWIAMY z zespołem developerów
13. Wprowadzamy korekty na bieżąco
14. Prezentujemy projekt i zbieramy laury
3. 1. Klient jest najważniejszy
Każdy w projekcie jest ważny.
Klient
UX
Developer
PM
Grafik
Front-end
4. 2. Zaczynamy projekt
Czy na pewno zaczynamy? Czy może już się rozpoczął
i dołączamy do niego.
Ustalone są koszty, terminy itd.
Projekt wdrożeniowy
Projekt utrzymaniowy
5. 2.1 Projekt wdrożeniowy już się rozpoczął
Terminy wdrożenia ustalone
Kosztorys i harmonogram przygotowane
Jak zgrać tempo wszystkich osób w projekcie?
6. 2.2 Dołączamy do projektu utrzymaniowego
Projekt jest już wdrożony
Wprowadzamy nowe funkcjonalności
Naprawiamy błędy
Uaktualniamy istniejące funkcjonalności
7. 3. Zbieramy wytyczne
Kto zbiera wytyczne?
Gdzie są spisane wytyczne?
Ograniczenia zewnętrzne
14. 4.3 UX – Programista
Pytanie do uczestników :)
15. 5. Prezentujemy projekt klientowi
Ważny jest kontakt bezpośredni
Ilość iteracji
Zakres zmian względem założeń
projektowych
Zadawanie pytań i uzyskiwanie odpowiedzi
Przykłady:
Grafika strony głównej
Zestaw makiet + RWD + Projekt koncepcyjny
16. 6. Prezentujemy poprawiony projekt
Od tego momentu nie powinno być radykalnych zmian
w zakresie projektu.
Jeśli tu się poddamy projekt na pewno wymknie się spod kontroli.
Przykładowe sposoby otrzymywania uwag / zgłoszeń błędów:
Skan wydrukowanej strony z naniesionymi na niej odręcznymi
poprawkami dostarczony mailowo.
Zestaw uwag na Jira / Google docs otrzymany od klienta
(warto poświęcić czas na edukację klienta w przypadku
dłuższych projektów)
17. 7. Bronimy projektu - na spotkaniu
Na spotkaniu odwołujemy się do pozytywnych
doświadczeń swoich i firmy oraz do prawidłowych
wzorców projektowych i trendów panujących na rynku.
Przykład:
Prezentacja działającego serwisu z benchmarku
18. 8. Bronimy projektu - przez telefon
Rozmawiamy z klientem tak długo aż zrozumie jak
niebezpieczny jest jego pomysł dla projektu.
Przedstawiamy jakie negatywne skutki niesie za sobą decyzja
o mało istotnej zmianie w projekcie.
Przykład:
„Jeśli Państwo nalegają, zrobimy to tak. Jednak nie
rekomendujemy takiego rozwiązania."
19. 9. Bronimy projektu - korespondencja mailowa
Wizualizujemy klientowi zmiany oraz mówimy o kierunku,
w którym zmierza projekt.
Należy wystrzegać się wizualizacji bardzo złych pomysłów,
gdyż mogą one być odebrane jako właściwe rozwiązanie i
ciężko będzie się z nich wycofać
Przykład:
Zastosowanie niepoprawnego wzorca projektowego
20. 10. Przekonaliśmy klienta
Klient przekonany o merytoryczności
naszych działań staje się naszym
sprzymierzeńcem.
O taki stan rzeczy należy dbać przez
cały czas trwania projektu
Zaangażowanie wszystkich
udziałowców projektu zwiększa jego
szanse na sukces.
21. 11. Implementujemy projekt
Nie zapominamy w tym momencie o projekcie. Wręcz
przeciwnie: dopytujemy się o niego, pokazujemy, iż nas
interesuje to co się dzieje.
Przykład:
"Nie mam dziś czasu. Przyjdź z tym do mnie jutro."
"Zrobimy, a potem się poprawi."
22. 12. Rozmawiamy z zespołem developerów
Dzień po dniu dzięki rozmowie wiemy jak idą sprawy
w projekcie, czy są jakieś problemy.
Rozwiązujemy na bieżąco problemy pojawiające się
w projekcie.
Przykład:
"To nie nasz problem tylko ludzi, co mają stare telefony."
"Tak będzie działało szybciej i użytkownikowi będzie
łatwiej."
23. 13. Wprowadzamy korekty na bieżąco
Optymalizacja projektu wymaga czasem konsultacji z
klientem.
Nie bójmy się ulepszać projekt podczas jego tworzenia.
Oczywiście, zmiany muszą być zaakceptowane przez klienta i
mieć wymierną korzyść dla projektu.
Przykład:
Nie róbmy nic. Klientowi się nie spodobają zmiany w grafice
jaką nam dostarczył.
Tak jest napisane w wytycznych.
Zastosujmy rozwiązania ułatwiające wprowadzenie RWD w
drugim etapie projektu (jeśli wygramy przetarg).
24. 14. Prezentujemy projekt i zbieramy laury
Uwaga powdrożeniowa, co jeszcze można poprawić. Jeśli nie
widzimy nic do poprawy, to bardzo źle.
Zawsze jest coś do poprawy, do zrobienia lepiej. I nie należy
się tego wstydzić. To wręcz pożądane, by być coraz lepszym.
Przykład:
Zaprzestanie prac nad projektem spowodowane
wykruszeniem się zespołu nieakceptującego metod pracy
przy projekcie (przejście pracowników do innych firm).
Sukces i celebracja projektu, premie itd.
25. Wdrożenie i co dalej?
O ile umowa przewiduje utrzymanie serwisu warto
dopytywać o statystyki, klientowi podpowiadać nowe
rozwiązania.
Podczas wprowadzania ulepszeń developerskich zawsze
należy służyć radą.
Przykład:
Nie zmieniajmy nic. Klientom się podoba, bo kupują.
Zaproponujemy klientowi listę funkcjonalności
rozwojowych, by mógł do nich powrócić, gdy serwis
odniesie sukces i będą środki na ich realizację.
26. Projektowanie to decyzje…
W ciągu całego projektu podejmujemy ich nieskończoną ilość i
nie możemy na końcu powiedzieć, że się pod tym nie
podpiszemy. Nie możemy unosić się honorem eksperta i
zapominać o adresatach projektu.
Przykład:
Przeczytać w miesięczniku Wprost, iż portal jest idealnym
przykładem jak można zmarnować środki.
Przeczytać artykuł, w którym dowiadujemy się, iż w trzy
miesiące od wdrożenia serwisu odwiedziło go 600 tys.
użytkowników, którzy wygenerowali prawie 3.5 mln odsłon.