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

Arkadiusz Smółkowski

„eksperckość” pułapka na UX Designera

Warszawa

20.04.2015

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

1. Klient jest najważniejszy

Każdy w projekcie jest ważny.

Klient

UX

Developer

PM

Grafik

Front-end

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żeniowyProjekt utrzymaniowy

2.1 Projekt wdrożeniowy już się rozpoczął

Terminy wdrożenia ustalone Kosztorys i harmonogram przygotowane Jak zgrać tempo wszystkich osób w projekcie?

2.2 Dołączamy do projektu utrzymaniowego

Projekt jest już wdrożony Wprowadzamy nowe funkcjonalności Naprawiamy błędy Uaktualniamy istniejące funkcjonalności

3. Zbieramy wytyczne

Kto zbiera wytyczne? Gdzie są spisane wytyczne? Ograniczenia zewnętrzne

3.1 Kto zbiera wytyczne?

PMAnalitykUX

3.2 Gdzie spisywane są wytyczne?

Projekt koncepcyjny Specyfikacja Wymagania funkcjonalne

3.3 Ograniczenia zewnętrzne

Ustawy państwowe Dyrektywy UE Zalecenia organów zlecających projekt

4. Konsultujemy z zespołem developerskim wykonalność projektu

Brak komunikacji na linii: UX – Grafik UX – Front-end UX – Programista

4.1 UX - Grafik

Pytanie do uczestników :)

4.2 UX – Front-end

Pytanie do uczestników :)

4.3 UX – Programista

Pytanie do uczestników :)

5. Prezentujemy projekt klientowi

Ważny jest kontakt bezpośredni Ilość iteracji Zakres zmian względem założeń

projektowychZadawanie pytań i uzyskiwanie odpowiedzi

Przykłady:Grafika strony głównejZestaw makiet + RWD + Projekt koncepcyjny

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)

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

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."

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

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.

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."

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."

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).

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.

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ę.

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.

Czas na pytania

Projektant UX nigdy się nie poddaje.

uxactive.com

Arkadiusz Smółkowski

Dziękuję za uwagę