Kolejny odcinek z serii - tym razem rozmowa z Marcinem Malickim (Dyrektorem Pionu Rozwoju Produktów i Usług) i Rafałem Drewnowskim (Kierownik UX) w Centralnym Ośrodku Informatyki Ministerstwa Spraw Wewnętrznych. Bardzo się cieszę z tej rozmowy, bo to wyjątkowa instytucja realizująca wyjątkowe projekty - "światełko w tunelu" podejścia user-centered design w polskich usługach rządowych 😉

Maciej Lipiec: Pracujecie w Centralnym Ośrodku Informatyki MSW. Czym jest COI i czym się na co dzień zajmujecie?

Marcin Malicki: Centralny Ośrodek Informatyki jest w sektorze publicznym czymś dość unikatowym. Chyba nie ma drugiej instytucji o takim charakterze – która świadczy pełen wachlarz usług IT – projektowanie, dewelopment, wdrożenia, utrzymanie, zachowanie SLA, doradztwo, audyty itp. Bardziej precyzyjnie COI jest instytucją gospodarki budżetowej, czyli niejako państwową firmą IT podległą ministrowi spraw wewnętrznych. To znaczy, że nie żyjemy z dotacji budżetowej, ale z tego, co zarobimy. Dlatego np. sprzedajemy rozwiązania (m.in. eDok – system obiegu dokumentów), normalnie konkurując z prywatnymi firmami. Jednocześnie realizujemy zadania IT, które zleca nam MSW. Obecnie są to dwa duże, kilkuletnie projekty dotyczące przebudowy centralnych rejestrów państwowych.

A zatem łączymy jednocześnie perspektywę biznesową, bo musimy się utrzymać i niejako misyjną, bo celem istnienia COI nie jest maksymalizacja zysku, ale realizowanie strategicznych zadań IT dla państwa.

ML: Jesteście odpowiedzialni za stworzenie pierwszego zespołu UX w sektorze publicznym w Polsce. Jak doszło do tego, że ktoś pomyślał, że taka komórka jest potrzebna?

MM: He, he – wszystko dzięki blogowi Maćka Lipca. I to nie całkiem żart. Z UX zetknąłem się po raz pierwszy, odpowiadając w Narodowym Archiwum Cyfrowym za redizajn serwisu udostępniającego kilka milionów dokumentów archiwalnych. Jako że nie wywodzę się z branży interaktywnej (wcześniej kilka lat zajmowałem się m.in. projektowaniem książek dla dzieci) i po kiepskich doświadczeniach tworzenia serwisów „na czuja” - szukałem jakiejś metody, sensownego klucza by zrobić to dobrze. Szukałem, szukałem i trafiłem na Twojego bloga, potem na kolejne, następnie doświadczenie badań robionych przez K2 i współpraca z doświadczonym UX-em przy projektowaniu serwisu. Przeżycie na własnej skórze skoku jakościowego, jaki przynosi projektowanie zorientowane na użytkownika, sprawiło, że nie było już odwrotu. Poczułem, że to dziedzina dla mnie, coś czego szukałem przez kilka lat.

Co ważniejsze dotarło do mnie, że sektor publiczny jest pod tym względem dziewiczym terytorium. Miejscem, w którym można budować niemal od zera, bo znaczna część projektów w ogóle nie nadaje się do użycia, a jednocześnie, gdzie niezwykle łatwo uzasadnić konieczność UX, jako że administracja jest przede wszystkim usługodawcą. Gdy mój dyrektor z NAC Nikodem Bończa Tomaszewski objął w 2012 roku prowadzenie COI, zaproponował mi przejście do niego. Zacząłem go wówczas namawiać by taki zespół UX w COI powstał. Mam szczęście, że mam naprawdę świetnego szefa, który nie tylko zrozumiał to i poparł, ale także dał ogromną swobodę w budowie tego zespołu. Początki były trudne, nikt z doświadczonych UX-ów nie garnął się do państwowego piekiełka, ale m.in. dzięki pomocy Pauliny Makuch i Agi Szóstek udało się zrobić wyłom – przyszedł Rafał Drewnowski, a potem już poszło. Dziś, po ponad roku istnienia, mamy 8-osobowy, coraz bardziej zgrany team i pierwsze widoczne efekty pracy na horyzoncie. A co ważniejsze, świadomość potrzeby UX zaczyna się w państwie przebijać. Np. niedawno dostaliśmy niespodziewany telefon z Kancelarii Premiera z prośbą o audyt użyteczności projektu serwisu do konsultacji społecznych z obywatelami.

Rafał Drewnowski: Przeszedłem na urzędową stronę mocy dzięki pomyślnemu zbiegowi okoliczności. Na jedno ze spotkań CHI Polska nieomal nie przyjechałem przez kolejny „asap”, który wpadł na koniec dnia. Zdążyłem jednak i dotarłem w ostatniej chwili na wystąpienie-niespodziankę. Nie było go w agendzie, ale okazało się interesujące i ważne. To Marcin mówił o UCD w administracji. Pomyślałem sobie „Chyba śnię! Gość opowiada o UX w polskich urzędach! Biznesy niechętnie wprowadzają UX-zmiany, a on chce przekonać urzędników…wchodzę w to!” Przypominając sobie formalności, jakie mozolnie załatwiałem w różnych instytucjach, poczułem, że to wyjątkowa szansa na zrobienie czegoś bardzo pożytecznego, że mógłbym mieć wpływ na te wszystkie zagmatwane procedury. Skoro optymalizowałem wcześniej flow zakupu kremów, wycieczek czy dekoderów, to przecież dam radę ze sprawami w urzędzie. Pierwszy zimny prysznic przeżyłem już w trakcie formalnej rekrutacji. Poza CV i listem motywacyjnym należało wysłać: trzy oświadczenia, kopie dokumentów potwierdzających doświadczenie zawodowe i świadectwo pracy. „WTF…no tak, administracja”. Obecnie rekrutacja do COI jest już zmieniona i nie odbiega zbytnio od procesów w firmach komercyjnych.

ML: Marcin: wow, czuję się doceniony 😉 Powiedzcie, ile osób liczy zespół UX w COI? Jak jest zorganizowany, jakie są w nim role? Czy w Waszym zespole dążycie do specjalizacji poszczególnych osób?

RD: Jak już Marcin powiedział jest nas ośmioro. Pracując zespołowo uczymy się nawzajem i nabieramy nowych umiejętności, ale jednoczenie zachowujemy i pielęgnujemy nasze główne role: architekt informacji, badacz UX, grafik, front-end developer, projektant usług. Na przykład Robert, front-endowiec jest specem od dostępności i w trakcie projektowania doradza w kwestii kontrastu, czy wielkości fontów, a projektant usług ma bzika na punkcie typografii i pilnuje, aby w gotowej aplikacji były zachowane linie bazowe. W naszym zespole doskonale sprawdza się więc kompetencyjny model T. Orientowanie się w wielu dyscyplinach jest bardzo cenne, ale według mnie równie ważne jest solidne wykształcenie i doświadczenie specjalistyczne.

ML: Muszę to powiedzieć: myślę, że większości osób w Polsce rządowe projekty informatyczne nie kojarzą się dobrze. To przetargi na setki milionów złotych realizowane przez firmy informatyczne, gdzie zupełnie nie dba się o design i potrzeby użytkowników. To powolność, biurokracja, język niezrozumiały dla przeciętnego Kowalskiego. Wydaje mi się też, że jednym z większych problemów rządowych projektów jest brak centralnej wizji: każda jednostka robi coś swojego, brakuje spójnego spojrzenia na cały ekosystem. Dlaczego tak jest i czy widzicie tu szanse na poprawę?

MM: Nic dziwnego, nam też się źle kojarzą. To trudne pytanie. Na pewno masz rację, że brak jest spójnej wizji. O głębi problemu jaki ma Polska, jako państwo, ze spójnością projektowania świadczy fakt, że nie mamy nawet kanonicznej, cyfrowej wersji godła RP i zasad jego użycia. Przeglądając 20 stron ministerstw, można dostrzec, że każde używa innego wariantu orła i to niemal we wszystkich kolorach tęczy.

Jednak nasza diagnoza jest nieco inna niż Twoja. Uznaliśmy, że w obecnych warunkach polskiej administracji trzeba zaczynać z pokorą. Budować iteracyjnie, klocek po klocku. Oddawać kawałki i weryfikować założenia. Np. spotkaliśmy się kilka miesięcy temu z ludźmi, którzy stworzyli na Śląsku platformę e-usług SEKAP. Wizualnie jest to obecnie dość paździerzowe i nie ma żadnych fajnych ficzerów, ale serwis jest naprawdę przydatny dla mieszkańców. Głównie dzięki temu, że w jednym miejscu, spójnie i przejrzyście opisano, jak załatwić każdą sprawę. Na czym polegała istota pracy twórców? Nie na wielkim projekcie informatycznym, ale na tym, że administracja na Śląsku dogadała się ze sobą i mozolnie, stopniowo ujednoliciła własne procedury, a dzięki temu mogły powstać opisowe karty usług. Legendarny www.gov.uk w dużej mierze składa się z tego samego – klarownie podanej informacji.

Chorobą wielu państwowych projektów IT była gigantomania i presja automatycznego sukcesu. Mamy ściernisko, nie mamy doświadczenia, mamy słabe kompetencje, ale w 2 lata wybudujemy San Francisco – wielkie systemy które zelektronizują całą administrację i kontakt z urzędem. Tak powstały chore, przerośnięte projekty-mutanty, których nikt nie chce używać. Do tego dołożyły się głośne ostatnio praktyki korupcyjne.

Drugim problemem jest fetyszyzacja systemów informatycznych w administracji. „Zróbmy system – on będzie przesyłał to, tam i problem się rozwiąże”. A właśnie, że się nie rozwiąże. System informatyczny jest zwieńczeniem dzieła. Ważniejsze są same procedury w administracji, działanie urzędu. Jeśli złe są procedury, to system będzie jeszcze gorszy.

Szansą na poprawę jesteśmy oczywiście my 🙂 A mówiąc serio, państwowe IT jest teraz trochę jak człowiek po ostrej imprezie. Wstaje i patrzy, że przepił pensję, zakupów nie zrobił, boli go głowa, a kolegów zawinęła policja. Myślę, że teraz może być tylko lepiej.

ML: Przez parę lat K2 wspólnie z fundacją FOR i Helsińską Fundację Praw Człowieka przygotowywało raporty na temat stron internetowych polskich sądów. Dzięki nagradzaniu najlepszych i wskazywaniu tych najsłabszych, myślę że udało nam się trochę poprawić jakość serwisów sądów w Polsce. Ale w trakcie pracy nad raportami doszliśmy do wniosku, że potrzeba tu tak naprawdę service designu. Bo internet to jedna sprawa, ale kiedy obywatel odwiedza budynek sądu w większości przypadków jest totalnie zagubiony. Nie wie gdzie iść, jak załatwić swoją sprawę, jak przebiegają różne procesy. Internet w tym nie pomaga, system informacji wizualnej nie istnieje: to masa wydrukowanych karteczek poprzyklejanych w różnych miejscach. Czy w Waszym myśleniu o usługach państwowych bierzecie pod uwagę kanały online i offline?

MM: Super inicjatywa! Im dłużej pracujemy, tym bardziej zdajemy sobie sprawę, że to, co niewidoczne online jest znacznie ważniejsze niż jakakolwiek strona czy aplikacja. Wszystko zaczyna się na poziomie prawa, czyli ustaw i rozporządzeń, bo to one definiują procesy i „programują” pracę urzędników. Potem oczywiście jest jakość samej obsługi w urzędzie i tu już backoffice’owe systemy IT mogą w czymś pomóc, ale na pewno nie załatwiają wszystkiego. Dopiero na końcu są serwisy online – one mogą zrobić tyle, na ile pozwoli im prawo, kompetencje urzędników oraz systemy działające z tyłu.

Właśnie dlatego staramy się angażować zarówno w tak fundamentalne sprawy, jak zmiany ustaw, jak i tak szczegółowe i „niecyfrowe” jak ujednolicenie i poprawienie użyteczności wzorów dokumentów urzędowych. Jednocześnie zakładamy, że wsparciem i zwieńczeniem tych rzeczy powinna być spójna, dobrze przemyślana usługowa platforma online, ale zaczynamy od podstaw.

ML: Co myślicie o serwisie Gov.uk? Dla mnie to rewelacja z wielu względów. Po pierwsze, to odwaga w upraszczaniu interfejsu do maksimum. Po drugie, centralizacja: państwo jako jeden interfejs i "brand" dla użytkownika. Uważam, że to świetnie, że taki projekt otrzymał Design of the Year Award.

RD: Jestem fanem gov.uk i regularnie podglądam co robią brytyjscy koledzy po fachu. W pełni zasłużyli na tę nagrodę. Stworzyli fantastyczny, czytelny i przyjemny w użytkowaniu serwis, który skutecznie spełnia swoją główną funkcję - informuje ludzi: jak załatwić najróżniejsze sprawy urzędowe, na co wydawane są ich pieniądze albo czym obecnie zajmują się różne instytucje. Zachęca też do zaangażowania się w prace rządu i samorządów. Bez problemu można w nim znaleźć informacje o inicjatywach, w które można się włączyć, albo o konsultacjach prowadzonych przez agendy rządowe. To ważny punkt styku między obywatelem i państwem. Nie trzeba zastanawiać się, jak i gdzie załatwić jakąś sprawę, wystarczy sprawdzić na gov.uk.

Chcę kiedyś móc powiedzieć, że brałem udział w budowaniu podobnego rozwiązania w Polsce. Kończymy właśnie prace nad pierwszą usługą, która pozwoli sprawdzić on-line historię pojazdu w oparciu o dane z Centralnej Ewidencji Pojazdów. Kolejne pomysły, w tym na usługi związane z dowodami osobistymi, czy też zawarciem małżeństwa już czekają na realizację.

Minimalistyczny, niemal ascetyczny interfejs gov.uk może się podobać lub nie, ale najważniejsza jest jego przejrzystość, która bardzo ułatwia odnalezienie szukanych informacji.

MM: Oczywiście trzeba jednocześnie pamiętać, że brytyjski Government Digital Service, który odpowiada za Gov.uk ma nieco inne umocowanie i inaczej zdefiniowaną rolę niż my. To zespół działający przy brytyjskim odpowiedniku Kancelarii Premiera o bardzo silnej pozycji – żadna komunikacja rządu online, ani żadne usługi cyfrowe nie wychodzą bez ich udziału, ponadto są oficjalnie wyznaczeni do realizacji rządowej strategii usług cyfrowych, mogą więc wpływać na wszystkie ministerstwa. Bardzo ciekawa jest ewolucja ich podejścia. Zaczynali od serwisu Direct.gov nieco podobnego w założeniu do polskiego ePUAP-u. Ponieśli kilka porażek także podobnych do polskich – wielkie projekty, sporo zmarnowanych pieniędzy i problem kilku wielkich firm IT które całkowicie zmonopolizowało zamówienia publiczne. Półtora roku temu wyciągnęli wnioski i zmienili podejście – postawili na zwinne metodyki i silną organizację zorientowaną nie tylko na budowę jednolitej, usługowej platformy internetowej rządu, ale mającą mandat do definiowania i upraszczania całych procesów w relacji obywatela z urzędem. Uznali także, że zamiast inwestować w promocję swojego serwisu, trzeba pozwolić by państwowe e-usługi były obecne tam, gdzie ludzie akurat są i dlatego szeroko otwierają API, co pozwala na implementowanie tych e-usług np. w komercyjnych aplikacjach i serwisach społecznościowych

ML: Gov.uk wyróżnia też proces projektowy: iteracyjny, szybki i zwinny, podejście prawie startupowe, gdzie jak najszybciej publikowana jest wersja alfa/beta, aby zebrać feedback od użytkowników, i ciągła optymalizacja. No i otwartość, dzielenie się informacjami o projekcie na blogu, Twitterze, itd. Czy w Polsce coś takiego jest możliwe? Dlaczego np. ePUAP nie może odpalić publicznego prototypu, po to tylko, żeby zebrać feedback na temat interfejsu od obywateli? Czy projekty rządowe muszą toczyć się "za zamkniętymi drzwiami", czy wyobrażacie sobie publiczną dyskusję o nich na etapie projektowym?

RD: Nie tylko wyobrażamy sobie, ale pracujemy w taki, zwinny sposób. Po kolejnych iteracjach spotykamy się z użytkownikami i klientami. Na tych spotkaniach prezentujemy efekty prac, słuchamy uwag, dyskutujemy i ustalamy wspólnie co trzeba poprawić. Znaczna część naszych projektów to systemy, których użytkownikami są urzędnicy, nierzadko osoby pracujące w administracji od dziesiątek lat. Mają swoje przyzwyczajenia, utarte schematy postępowania, a skomplikowane procedury znają na wylot. Rozmawiamy więc przede wszystkim z pracownikami urzędów: ministerstwa, gmin czy urzędów stanu cywilnego. Czujemy już nieźle atmosferę administracyjną, ale okazuje się każde spotkanie wnosi nową wiedzę i poznajemy kolejne niuanse, o których wcześniej nie mieliśmy pojęcia. Urzędnicy muszą na przykład potrafić opisać błahe sprawy w formalny sposób, licujący z powagą urzędu i Państwa, które reprezentują. Jak zapisałbyś powód wymiany dowodu osobistego: „bo zjadł go pies” albo „żona uprała dowód w pralce i się połamał”?

Zaprojektowane przez nas druki będą używane zarówno przez urzędników, jak i obywateli. W trakcie prac nad wzorami tych dokumentów zaprosiliśmy więc na testy także zwykłych ludzi i ich prosiliśmy o wypełnienie formularzy. Wyniki jednoznacznie pokazały, że nowy projekt jest lepszy. Wypełniając zaprojektowany w COI wniosek o wydanie dowodu osobistego respondenci popełniali 5 razy mniej błędów w porównaniu do wniosku używanego obecnie.. Podejście iteracyjne sprawdziło się i będziemy stosować je w kolejnych projektach.

ML: Nad jakimi projektami obecnie pracujecie w COI? Jakie są największe wyzwania, które się z tym wiążą?

MM: Obecnie budujemy niejako od nowa wielki system obsługujący ewidencję PESEL, urodzeń czy ślubów, wydawanie dowodów osobistych, paszportów itd. Nie wiem, czy wiesz, ale PESEL dotąd działa w dużej mierze na systemie napisanym w Assemblerze na początku lat 80-tych. Fascynująca żywotność, ale to powoduje, że administracja w praktyce nie wymienia się informacjami, które same posiada. W efekcie tysiące razy musimy jej podawać te same dane. W tym projekcie zespół UX projektuje m.in. aplikację, która służy do obsługi obywatela przez urzędników – wyrobienie dowodu, urodzenie dziecka, ślub, zmiana nazwiska itp. To system zamknięty, ale wyzwanie fajne, bo służy do pracy po 8 godzin dziennie, więc dizajn ma tu życiowe znaczenie dla blisko 20 tysięcy ludzi.

O projekcie można poczytać na stworzonej w całości przez nas stronie www.obywatel.gov.pl.

Drugi duży projekt to przebudowa wielkiego rejestru kierowców i aut (CEPiK). Tu także projektujemy aplikację dla urzędników, komorników, policji itd., ale co ważniejsze próbujemy zmieniać całe procesy obiegu danych by były bardziej sensowne i przydatne.

Pracując nad tymi projektami postawiliśmy sobie dodatkowy cel – chcemy by te ogromne zbiory aktualizowanych stale danych, które funkcjonowały dotąd tylko w zamkniętym obiegu administracji zaczęły służyć ludziom i biznesowi. Rozwijamy zatem e-usługi. W ciągu 3-4 miesięcy powinna wystartować pierwsza z nich „Historia Pojazdu”, pozwoli zweryfikować kluczowe fakty przed kupnem używanego samochodu. Od strony systemu jesteśmy gotowi, czekamy na wejście w życie zmiany ustawy, która na to pozwoli.

ML: Jak inicjowane są projekty, które robicie? Od kogo wychodzi początkowy pomysł? Jak współpracujecie z wszystkimi "interesariuszami" (domyślam się, że jest ich niemało), a także grafikami i IT w Waszych projektach?

MM: Te wielkie projekty dotyczące rejestrów zleca nam MSW. W ich obrębie szukamy miejsca na UX. A więc pracujemy z analitykami, którzy definiują procesy, rekomendujemy zmiany procedur prawnych, projektujemy interfejsy użytkownika dla urzędników, wreszcie zgodnie z wypracowaną wspólnie z MSW strategią szukamy możliwości rozwoju usług dla obywateli. Zdarza się, że w trakcie rodzą się pomysły mniejszych podprojektów. Tak było z projektowaniem wspomnianych przez Rafała wzorów dokumentów urzędowych.

W wypadku własnych produktów, takich jak system obiegu dokumentów eDok UX jest stale częścią zespołu, który go rozwija. Pracuje razem z product ownerem, który reprezentuje też biznes, architektem systemowym, analitykiem i szefem zespołu programistów.

Przykładamy bardzo dużą uwagę do riserczu, konsultacji i badań. Gadamy z urzędnikami, chodzimy do urzędów, spotykamy się z dziesiątkami różnych merytorycznych instytucji, NGO’sów, jak trzeba robimy kwerendę historyczną. Wszystko po to by zrozumieć potrzeby różnych grup odbiorców, które są często bardzo zróżnicowane. To czym się zajmujemy projektowo jest czasem nazywane we wzornictwie „universal design”, budujemy rozwiązania bardzo horyzontalne, które muszą obsłużyć często ogromny przekrój społeczny.

RD: Pierwsza usługa, którą stworzyliśmy, „Historia pojazdu”, może wydawać się mała i nieskomplikowana, ale wymagała zaangażowania całkiem sporego zespołu. Konsultowaliśmy się z ponad 30 instytucjami, firmami i osobami zawodowo zajmującymi się bezpieczeństwem na drogach, szkoleniem kierowców, produkcją pojazdów i części, czy handlem nimi.

Staraliśmy się ważyć i uwzględniać punkt widzenia każdej z nich, co nie było łatwe, szczególnie w porównaniu ze standardowymi działaniami UX-owymi, czyli odkrywaniem benchmarków, projektowaniem flow czy potem makietowaniem, projektowaniem grafiki, testami z użytkownikami, kolejną iteracją projektowania itd. Dla mnie osobiście najprzyjemniejsze były prace nad projektami graficznymi. Za wygląd „Historii pojazdu” odpowiadają Maciek i Filip. Maciej jako projektant usługi określił w pewnym sensie styl – oszczędny i przejrzysty. Makiety przygotował dopracowane wizualnie, wręcz tak dopracowane, że można było traktować je jako wstępne projekty layoutu. Wynikało to po części z nawyków i doświadczenia w projektowaniu grafiki użytkowej. Grafikowi Filipowi to odpowiadało i bardzo szybko się porozumieli. Ramię w ramię projektowali widoki online’owe i drukowane. Nie było kłótni, kreatywnych starć ani dramatycznych zwrotów akcji, ale ostateczny efekt jest moim zdaniem bardzo wysmakowany. Do innego projektu grafikę tworzyła Marta, której głównym zadaniem jest dbanie o architekturę informacji, ale po zaprojektowaniu AI odpaliła Photoshopa i stworzyła bardzo przyjemną szatę graficzną, którą wkrótce będziecie mogli zobaczyć w kolejnym serwisie www, który opublikujemy.

ML: Jakie narzędzia, metody, oprogramowanie wykorzystujecie w zespole UX COI?

RD: Oprogramowanie? Prawdziwemu UX’owi wystarczy papier i ołówek 😉 A na serio, to używamy pakietu Adobe, Camtasia Studio.

MM: Na początku próbowaliśmy cały proces projektowania zamknąć w narzędziach Adobe, ale okazało się, że prototypowanie jest wtedy zbyt wolne. Dlatego przenosimy się jednak na Axure. Camtasia daje radę i jest niedroga, ale dojrzeliśmy też do zakupu potwora Morae – liczymy, że pozwoli przyspieszyć ewaluację badań.

RD: Projekty zwykle zaczynamy od tzw. desk research i szukania benchmarków. Warto odrobić tę „pracę domową”. Dzięki temu, pracując nad wzorami dokumentów urzędowych, dowiedzieliśmy się na przykład, że w Polsce nigdy nie było jednolitych formularzy urzędowych i że nie możemy nawiązać do tradycji czy jakichś do dobrych wzorów. Przez dziesięciolecia stosowano najróżniejsze wzory, formaty, sposoby wyróżniania i kroje pism. Projektując nowe wzory musieliśmy więc wypracować zupełnie nową jakość, co było bardzo ciekawe, ale również, i nie boję się tego powiedzieć – doniosłe.

Organizujemy warsztaty z osobami zaangażowanymi w projekty w różnych rolach. W badaniach stosujemy takie narzędzia jak: wywiady indywidualne, grupy focusowe, testy zadaniowe, ankiety, dyferencjały semantyczne, karty emocji i oczywiście card sorting. Systemy, które budujemy będą umożliwiały podpięcie analityki i sprawdzanie, jak są używane w codziennej pracy.

Jak już mówiłem, pracujemy zwinnie, bierzemy udział w ceremoniach Scrumowych z programistami. Początkowo byli sceptycznie nastawieni do udziału nie-developerów, ale przekonali się, że nasza praca jest bardzo przydatna i teraz już nie musimy przepychać się łokciami i przekonywać, żeby z nami współpracowali. Życzę takiego traktowania wszystkim UX’om!