Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółkowski

320 views

Published on

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/

  • Be the first to comment

  • Be the first to like this

4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółkowski

  1. 1. Arkadiusz Smółkowski „eksperckość” pułapka na UX Designera Warszawa 20.04.2015
  2. 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. 3. 1. Klient jest najważniejszy Każdy w projekcie jest ważny. Klient UX Developer PM Grafik Front-end
  4. 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. 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. 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. 7. 3. Zbieramy wytyczne  Kto zbiera wytyczne?  Gdzie są spisane wytyczne?  Ograniczenia zewnętrzne
  8. 8. 3.1 Kto zbiera wytyczne? PM Analityk UX
  9. 9. 3.2 Gdzie spisywane są wytyczne?  Projekt koncepcyjny  Specyfikacja  Wymagania funkcjonalne
  10. 10. 3.3 Ograniczenia zewnętrzne  Ustawy państwowe  Dyrektywy UE  Zalecenia organów zlecających projekt
  11. 11. 4. Konsultujemy z zespołem developerskim wykonalność projektu Brak komunikacji na linii:  UX – Grafik  UX – Front-end  UX – Programista
  12. 12. 4.1 UX - Grafik Pytanie do uczestników :)
  13. 13. 4.2 UX – Front-end Pytanie do uczestników :)
  14. 14. 4.3 UX – Programista Pytanie do uczestników :)
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  27. 27. Czas na pytania
  28. 28. Projektant UX nigdy się nie poddaje. uxactive.com Arkadiusz Smółkowski Dziękuję za uwagę

×