Jak to się robi z sensem, czyli wprowadzenie do metodologii GDS

Hipopotam, który nie może dotrzeć do jedzenia
Nawet hipopotam może dostać kota

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ć:

  1. 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.
  2. Co to jest projektowanie zgodnie z user needs i dlaczego warto się tym zainteresować.
  3. Jak radzić sobie z user needs i pogłębiać ich zrozumienie na podstawie danych i obserwacji.
  4. 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ę).
  5. 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:

  1. 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ść.
  2. 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.
  3. Projektuj z pomocą danych. Prowadź bezustanny monitoring swoich stron i aplikacji po tym, jak zaczną one prawdziwe życie. Optymalizuj na bieżąco.
  4. 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.
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.

Czy wiesz, że ten artykuł to nie wszystko?

Przeczytaj starsze wpisy, które być może też cię zainteresują.