Case-study redesignu pogoda.wp.pl

Serwis miał już swoje lata, coraz bardziej odstawał funkcjonalnie od konkurencji. Nie zachwycała też grafika. To wszystko przekładało się na coraz gorsze statystyki — 8. miejsce w Megapanelu (RU) wśród serwisów pogodowych.

Początkowo mieliśmy w planach tylko “przemalowanie” serwisu, czyli zmianę grafiki i poprawienie najbardziej irytujących problemów z użytecznością. Grafika była jednak tylko wierzchołkiem góry lodowej.

Problem leżał też w samej prognozie. Informacje w serwisie nie zawsze przekładały się na rzeczywistość. To właściwie dyskwalifikujące dla serwisu pogodowego.

Część konkurencji mogła pochwalić się też większą ilością szczegółowych informacji.

Wreszcie — interfejs. Mało przejrzysty i średnio intuicyjny.

Nasz wniosek był jeden: jeśli chcemy mieć dobry serwis, to przemalowanie w niczym nie pomoże — trzeba stworzyć go od nowa.

“Postawmy na UX”

To jednak problem. Projekt zakładający pełen redesign jest oczywiście dłuższy, droższy i zaangażuje więcej osób. Żeby zyskać akceptację na tak dużą zmianę, potrzebowaliśmy atutu, który podniesie atrakcyjność serwisu w oczach użytkownika.

Pierwsza myśl — trafniejsza prognoza. To trzeba było koniecznie poprawić (zawarliśmy nową umowę na dostarczane treści), ale trafne informacje to minimum, które musi spełniać serwis pogodowy, a nie atut pozwalający wyprzedzić konkurencję.

Kolejny pomysł — więcej informacji. Dodaliśmy wiele nowych funkcjonalności (pogoda dla narciarzy i kierowców, artykuły i galerie itd.), lecz interesują one niewielką liczbę ludzi. Nie sprawią one, że zdobędziemy rzeszę nowych użytkowników.

Więc co dalej?

Zauważyliśmy, że użytkownicy korzystający z serwisów pogodowych, swój wybór tłumaczyli głównie trafnością prognozy lub przyzwyczajeniami. Właściwie nikt nie wspomniał o tym, żeby jego ulubiony serwis był wygodny, przejrzysty czy ładny.

Sytuacja wyglądała odwrotnie w przypadku aplikacji na smartfony — dobre wrażenia były głównym kryterium wyboru.

Stwierdziliśmy, że to nasza droga: zadbać o User Experience tak, aby korzystanie z naszej aplikacji było wygodne, intuicyjne i dostarczało pozytywnych wrażeń. To miał być nasz główny oręż w walce o użytkownika.

Prowadzenie projektu

Jak to często w dużych firmach bywa, większość projektów prowadzi się w modelu kaskadowym: najpierw projektowanie, później grafika i na końcu wytwarzanie. Tak miało być i tym razem.

Szybko okazało się jednak, że ten model się nie sprawdzi. Dobre UX (przynajmniej w tym przypadku) wymaga częstej weryfikacji pomysłów, ciągłych poprawek, zrobienia czasem kroku w tył, aby zrobić dwa kroki do przodu. Postanowiliśmy spróbować innego podejścia.

Podzieliliśmy projekt na części. Skupiliśmy się na najważniejszych funkcjach, resztę zostawiliśmy na później. Nie mieliśmy deadline’u kończącego prace projektowe. Spotkania trwały właściwie do wypuszczenia serwisu (a także już po) i angażowały cały zespół pracujący nad projektem.

To podejście — mocno w duchu Lean UX — przyniosło nam dużo zysków.

Nie trzeba produkować ton dokumentacji.

Łatwiej poprawić błędy — w podejściu typu Waterfall ciężko powrócić do zakończonej fazy, gdy np. testy wykażą, że jakaś funkcjonalność wymaga przeprojektowania. Albo ktoś weźmie odpowiedzialność za powrót i opóźnienia, albo problem jest lekceważony.

Łatwiej zmiejszyć zakres projektu — po prostu “wycinamy” najmniej istotne funkcjonalności bez dużej szkody dla całego produktu.

Większa kontrola nad projektem — projektant jest cały czas zaangażowany, na bieżąco śledzi zmiany. Nie ma sytuacji, w której serwis idzie do IT i wraca po kilku miesiącach w innej formie z “drobnymi” zmianami, które wyraźnie wpływają na UX.

Większe zaangażowanie zespołu — jakość pracy programistów/grafików etc. diametralnie rośnie, bo czują się oni bardziej odpowiedzialni za projekt.

W pracach popełniliśmy jednak poważny błąd — zespół projektowy liczył 10 osób.

To rozmyło odpowiedzialność, pogorszyło komunikację w zespole, a także negatywnie wpłynęło na zaangażowanie. W rezultacie przyczyniło się to do spowolnienia prac i paru błędów.

Wyciągnęliśmy jednak wnioski — w ostatnich dwóch miesiącach prac, główny zespół biorący udział w projektowaniu zmniejszył się o połowę. To znacznie podniosło szybkość i jakość pracy.

Funkcjonalności ważniejsze i mniej ważne

Naszym największym wyzwaniem projektowym było dodanie wielu nowych funkcjonalności i jednocześnie stworzenie serwisu czystego i przejrzystego.

Jak to zrobiliśmy? Problem rozwiązało podejście w duchu Lean UX.

Mieliśmy już wytypowane najważniejsze dla użytkownika funkcjonalności — sprawdzić ogólną prognozę na dziś i kilka następnych dni. Właśnie te informacje użytkownik powinien otrzymać od razu. Cała reszta informacji jest dla większości mniej istotna, te opcje można ukryć. Wystarczy, aby były stosunkowo łatwe do odnalezienia.

Jak testowaliśmy?

W tym przypadku główny sposób weryfikacji naszych pomysłów mógł być jeden — testy z użytkownikami.

Przeprowadziliśmy trzy sesje testów — na szczegółowej makiecie (ograniczonej jednak do głównych funkcjonalności), prototypie HTML z gotową grafiką i gotowym do wypuszczenia serwisie.

Testy pozwoliły wykryć wiele błędów i znacznie poprawiły jakość naszego produktu.

Premiera

Serwis został wypuszczony w grudniu, po sześciu miesiącach prac.

Oczywiście, to nie był koniec. W kolejnych miesiącach analizowaliśmy statystyki oraz przeprowadzaliśmy testy clicktrackingowe i testy AB. To zaowocowało zmianami i poprawkami serwisu — zmieniliśmy m.in. sposób nawigacji po głównych informacjach pogodowych.

Efekty

RU wg Megapanelu: czerwony — pogoda.wp.pl, żółty — pogoda.onet.pl, niebieski — twojapogoda.pl

Te przerosły wszelkie nasze oczekiwania.

Awans z ósmego na pierwsze miejsce w Megapanelu zajął nam tylko dwa miesiące. Liczba użytkowników wzrosła sześciokrotnie. Najnowsze statystyki też pozwalają na optymizm — nadal utrzymujemy pierwsze miejsce, a statystyki wciąż rosną.

Oczywiście, wynik nie byłby możliwy, gdyby nie ogromne możliwości Wirtualnej Polski, jeśli chodzi o promocję. Szukaliśmy więc statystyk, które pokazałaby, na ile sukces zawdzięczamy sprawnej promocji serwisu, a na ile jego jakości.

Wejścia bezpośrednie — są to wejścia wykonane poprzez wpisanie adresu serwisu internetowego w przeglądarce, wybranie adresu serwisu z listy ulubionych, wejścia w wyniku ustawienia adresu strony jako strony startowej, a także np. kliknięcia na link w klientach pocztowych, komunikatorach.

Takim wskaźnikiem może być liczba wejść bezpośrednich. Listopad 2012 — niecałe 400 tys. odwiedzin, styczeń 2013 — ponad 1,7 mln. Użytkownicy czterokrotnie częściej bezpośrednio odwiedzają naszą pogodę.

Udało nam się stworzyć produkt, który po dwóch miesiącach stał się najpopularniejszym serwisem pogodowym w Polsce. Ten wynik nie byłby możliwy, gdyby nie postawienie na dobre User Experience.

24.04.2013