W paru poprzednich wpisach eksplorowałem konstrukcję modelu potrzeb użytkownika (user needs) i organizacji (business needs) wg. zaleceń Government Digital Services. W ostatnim artykule z tej serii spróbuję wyjaśnić, dlaczego warto inwestować w te wygibasy swój czas.
Wiesz już, jak zbudować listę, która zawiera informacje o tym, czego oczekują od obecnej (i przyszłej) strony internetowej użytkownicy i organizacja. No dobrze, ale co można zrobić z takim zestawem? Całkiem sporo.
- Można zacząć porządny content audit, czyli przyjrzeć się temu, co na stronie naprawdę powinno się znaleźć, które artykuły trzeba zmodyfikować, a które usunąć. Można też zdefiniować sensowne tytuły stron odpowiadających poszczególnym potrzebom, bo istnieje szansa, że te istniejące nie mają sensu. Arkusz, który skonstruowaliśmy jest bowiem bardzo przydatny w procesie content writing, czyli zbierania do kupy prawdziwej zawartości serwisu.
- Content writing to jedno, ale jeżeli zamierzasz – a powinieneś – zająć się co najmniej przejrzeniem, a nawet zreformowaniem tego, co klient rzeźbi w temacie swojego zarządzania przepływem treści (content governance), arkusz potrzeb pozwoli Ci na zdefiniowanie jasnego zakresu odpowiedzialności za indywidualne strony i elementy serwisu. Mietek robi to, Ziuta tamto.
- Ponieważ wiesz, na jakie potrzeby odpowiadać będzie strona, którą budujesz, wiesz też – albo czujesz – czego brakuje. Do tego potrzeba odrobiny ituicji, ale wiele informacji dostarczą wywiady z prawdziwymi użytkownikami. Udokumentowane w takim arkuszu, zebrane z wywiadów potrzeby dostarczają dobrego wsparcia wtedy, kiedy ktoś w organizacji twierdzi, że „my i tak wiemy lepiej”. Ponadto, arkusz jest kopalnią pomysłów; czasem popatrzenie na coś, co już wiemy może uświadomić nam, jak wiele zostało do eksploracji.
- Arkusz definiuje podstawy ulepszonej architektury informacji. Ty – lub koledzy i koleżanki odpowiedzialni za konstrukcję nowej mapy serwisu – możecie czerpać z niego garściami. W okamgnieniu zauważysz, które informacje powinny naprawdę znaleźć się na nowej stronie, a które to nic innego jak long tail. Jeżeli nie wiesz, co to long tail (długi ogon), to już spieszę wyjaśnić – to potrzeby niszowe, takie, których zaadresowanie nie powinno być twoim priorytetem. Napiszę o tym więcej kiedy indziej, bo temat jest ciekawy, ale w praktyce sprowadza się to do dostarczenia treści, na które jest zapotrzebowanie i zaprzestania zawracania sobie głowy tym, czego i tak (prawie) nikt nie potrzebuje. Jeden typ napisał o tym ciekawą książkę.
- Lista potrzeb, którą zdefiniowałeś – rozbudowywana i modyfikowana w czasie – tworzy dobrą metodę nie tylko kontynuowanego audytu, ale także dokumentacji tego, co dzieje się z zawartością serwisu. Posiadanie takiego dokumentu przyda się specom z działu marketingu, monitorowania wydajności i Tobie, jeśli kiedyś będziesz musiał przekazać projekt komuś innemu.
- Zgromadzenie wszystkiego w jednym miejscu pomoże Ci zaprojektować i dobrać listę content types – myśl o szablonach; zunifikowanych stronach prezentujących zawartość w określony sposób. Zrozumiesz na przykład, że skonstruować wystarczy jeden szkielet do pokrycia listy wszystkich artykułów, drugi do zbudowania głównych sekcji podstron i tak dalej. Przez to ćwiczenie i tak przejść będziesz musiał, projektując jakikolwiek interfejs, a więc zrobienie tego wcześniej zaoszczędzi Ci czasu.
- Jeden solidny rzuk oka na dobrze skonstruowaną listę pozwala dowiedzieć się bardzo dużo na temat obu stron barykady. Zrozumienie, czym zajmuje się organizacja i jakie oczekiwania wobec niej mają użytkownicy jest na tyle ważne, że oczywistych korzyści z niego wypływających nie muszę nawet przybliżać.
W swojej praktyce używam listy potrzeb wg. modelu GDS w zasadzie przy każdym większym projekcie. Naturalnie, czasem zaczynam od środka; na przykład, mogę nie mieć natychmiastowego dostępu do danych z Google Analytics, ale za to zacząłem wywiady z użytkownikami lub drużyną klienta. Czasem wiem sporo o strukturze istniejącej strony, ale niezbyt wiele o tym, czego mogą chcieć użytkownicy – choćby dlatego, że moja wiedza o tematyce, której dotyka działalność klienta jest nikła (dla przykładu, teraz projektuję nowy serwis dla bardzo dużej firmy zajmującej się analizą rynków eksploracji złóż paliw kopalnych. Mózg zagrzewa mi się co minutę!).
Ten model jest więc dla mnie swego rodzaju podwaliną dla poźniejszej pracy, dostarcza bowiem struktury i dobrej metody dokumentacji tego, co się dzieje, a raczej wydestylowanych wniosków z badań. Dostarcza uniwersalnego, inter-dyscyplinarnego frameworku dla mnie i moich kolegów. Goście z GDS mają łby na karku; warto zainteresować się tym, co oferują.
Masz pytania? Czy coś wydaje się niezrozumiałe? Chcesz wiedzieć więcej? Napisz do mnie, zostaw komentarz pod tym wpisem albo połącz się ze mną na Twitterze i Facebooku.
Dodaj komentarz