Skróciak: ten wpis rozpocznie cykl artykułów wprowadzających do modelu pracy z potrzebami użytkownika (będę odwoływał się do angielskiej terminologi user needs ze względu na większą zgodność z kontekstem). Model ten, rozsławiony w Wielkiej Brytanii i świecie UX przez Government Digital Services (GDS), specjalną komórkę brytyjskiego rządu odpowiedzialną za projektowanie cyfrowych interakcji pomiędzy obywatelami a aparatem państwowym zyskał wielu fanów.
Po przeczytaniu serii moich artykułów będziesz wiedzieć:
- Co to jest GDS, a także jak zaprojektowany jest framework Design Principles (zasad projektowania), według którego powstają internetowe usługi rządu UK.
- Co to jest projektowanie zgodnie z user needs i dlaczego warto się tym zainteresować.
- Jak radzić sobie z user needs i pogłębiać ich zrozumienie na podstawie danych i obserwacji.
- Dlaczego trzeba pamiętać, że potrzeby organizacji – business needs – są równie ważne (wbrew powszechnemu i źle rozumianemu stwierdzeniu, że użytkownik ma zawsze rację).
- Co robić z gotowym modelem user needs i dlaczego jest to, moim zdaniem, uniwersalny framework do pracy z większością procesów UX.
Nie wiem, ile artykułów wejdzie w skład tego tekstu, ale postaram się nie rozciągać pisania w makaron. Zwłaszcza, że będę miał jeszcze okazję opowiedzieć o tym zagadnieniu więcej (ale to niespodzianka, a więc sza).
Jedziemy!
Wprowadzenie do metodologii GDS
Rys historyczny
Obecny na platformie internetowej system Directgov (nieistniejący już) był przez długie lata cyfrową bramą do wymiany większości ważnych informacji pomiędzy obywatelami a rządem Zjednoczonego Królestwa Wielkiej Brytanii i Irlandii Północnej. Istniejąca przez 12 lat strona internetowa pomagała wprawdzie nieco nawigować w zupie nieskończonej ilości tekstu i formularzy, jednak razem z ogromną liczbą pomniejszych serwisów różnych organizacji rządowych tworzyła las zarośnięty pokrzywami i mokrą paprocią. Krótko mówiąc, szeleściło liśćmi; wiadomo było, że ewolucja internetu odbywa się na tyle szybko, że nadeszła potrzeba czegoś lepszego.
Mądra pani lordzica (żałuję, że nie ma takiego słowa!) Martha Lane Fox napisała o tym raport zatytułowany „Directgov 2010 and beyond: revolution not evolution”, w którym jeszcze mądrzej stwierdziła, że drogą do wypełnienia założeń rządu komunikującego się z obywatelami jest tzw. digital by default, czyli metoda patrzenia na usługi dostarczane przez internet jak na podstawę interakcji. Reszta papierków, stempli i pocztowej korespondencji miała być tylko dodatkiem zapewniającym działanie usług elektronicznych. Kupiłbym lordzicy piwo, ale ona jest bogata i może pozwolić sobie na więcej piwa ode mnie, więc tylko podam jej grabulę, jeśli kiedyś spotkam na zakupach w Lidlu.
W kwietniu 2011 stworzony Digital Cabinet Office – komórkę rządową odpowiedzialną za propagację konceptu Government as a Platform, czyli “nowej wizji cyfrowego rządu; wspólnej infrastruktury systemów informatycznych, technologii i procesów, które umożliwią wybudowanie skupionych na potrzebach użytkownika stron dla obywateli” (luźne tłumaczenie z Tima O’Reilly). Government Digital Service – GDS – komórka odpowiedzialna bezpośrednio za stworzenie portalu GOV.UK – otrzymała prawo do weryfikacji i aprobowania każdego sposobu, w jaki rząd UK komunikuje się z obywatelami w cyberprzestrzeni. W praktyce oznacza to, że goście z GOV.UK mają kompletną kontrolę nad tym, w jaki sposób rząd Wielkiej Brytanii komunikuje się z Brytyjczykami poprzez Internet. Jeśli instytucja rządowa X wymyśli sobie jakieś kokodżambo i zapragnie stworzyć nową stronę internetową z niczego, pomysł ten musi przejść przez mądre głowy pań i panów z GDS. Nietrudno sobie wyobrazić, że jest to świetny pomysł, bo wreszcie specjaliści od service design starają się upewnić, że rzecz działa jak powinna.
Jeśli niczego z tego nie zrozumiałeś, to przyjmij po prostu, że GDS stworzyło GOV.UK, czyli wielką stronę internetową, na której obywatele UK mogą pozyskać informacje lub przeprowadzić wiele transakcji z organami publicznymi. Lista dostępnych usług wciąż rośnie.
To, że taka strona działa i ma się dobrze to wisienka na torcie; prawdziwa masa wiśniowo-kakaowo-czekoladowo-czosnkowo-kokosowa czai się pod powierzchnią. Sposób, w jaki pracuje GOV.UK jest bardzo dobrze zdefiniowany; procesy są wydajne, transparentne, a także zorientowane na potrzeby użytkownika i organizacji (w tym wypadku, rządu UK). Tu dochodzimy do Design Principles, czyli zasad projektowania, którymi kieruje się GDS.
Ażeby dobrze zrozumieć, o co będzie dalej latało, trzeba najpierw przyswoić sobie te zasady.
GDS Design Principles
Przetłumaczona na język polski, lista przedstawia się następująco:
- Projektuj dla potrzeb – potrzeb użytkownika, nie rządu. Prowadź badania i staraj się zrozumieć, czego potrzebuje twoja grupa docelowa. Nie strzelaj w ciemno i nie daj się ponieść.
- Rób mniej. Nie wynajduj koła na nowo. Koncentruj się na rdzeniu swojej działalności. Pozwól tym, którzy robią inne rzeczy lepiej od ciebie zająć się swoją pracą i czerp z tego korzyści, pomagając im w sposób, w jaki potrafisz.
- Projektuj z pomocą danych. Prowadź bezustanny monitoring swoich stron i aplikacji po tym, jak zaczną one prawdziwe życie. Optymalizuj na bieżąco.
- Pracuj ciężko dla prostych efektów. W GDS uważa się, że zrobienie czegoś naprawdę prostego w użyciu jest o wiele trudniejsze, niż zrobienie czegoś co tylko wydaje się proste. Krótko mówiąc, zawijaj rękawy i do roboty, bez wymówek.
- Projektuj na zasadzie krótkich iteracji i testuj na bieżąco. W GDS preferowany jest model MVP (minimum viable product – produkt podstawowy), Alfa, Beta, Live. Usuwaj te funkcje tworzonego serwisu, które nie działają i dopieszczaj wszystko zgodnie z tym, co mówią ci użytkownicy. W ten sposób oszczędzisz sobie wielkich kosztów i rozczarowań. Wyrzucaj prototypy do śmieci, jeśli nie działają; nie udawaj, że coś jest dobre tylko dlatego, że ty tak myślisz. Szukaj potwierdzenia!
- Projektuj dla wszystkich. Każdy – bez podziału na wiek, płeć czy stopień sprawności intelektualnej czy ruchowej – powinien móc użyć rozwiązania, które opracowujesz. Jest to nie tylko moralnie poprawne, ale i praktyczne, bo informacja powinna docierać do ludzi bez przeszkód. Projektuj dla potrzeb, nie dla typów użytkowników.
- Zrozum kontekst. Tworzysz rozwiązania dla ludzi – nie dla ekranów czy urządzeń. Gdzie znajdują się użytkownicy? Czy używają internetu na codzień? Jak dobrze radzą sobie z komputerem? Myśl o tym.
- Nie twórz stron internetowych czy aplikacji – twórz serwisy usług cyfrowych. Takie serwisy pomagają ludziom wykonywać zadania; myśl o kompleksowej obsłudze klienta, a nie tylko tym, co dzieje się w przeglądarce.
- Używaj wzorców projektowych i rób tak, żeby tworzone usługi mówiły jednym głosem. Nie bój się jednak odstępstw od normy; bezustannie poprawiaj metody pracy z użytkownikiem.
- Pracuj, otwarcie dzieląc się informacjami i rozwiązaniami, które opracowujesz. Udostępniaj kod, pomysły, koncepcje; mów o sukcesach, ale i o błędach.
W następnych artykułach z tej serii dowiesz się, jak praktyczne jest zastosowanie tych zasad i dlaczego tak wielu ekspertów UX projektuje według nich rozwiązania, które mają sens.
Dodaj komentarz