Empatia a programowanie, czyli jak pogodzić interesy badacza UX i programisty

Rola badań UX w procesie tworzenia innowacyjnych rozwiązań

Software Center, Capgemini Polska

Magdalena Czajkowska, UX Team Leader oraz Marcin Śliwa, Managing Enterprise Architect

Branża informatyczna jest jedną z tych, które za sprawą pandemii przeżywają wyjątkowo intensywny rozwój. Przeniesienie wielu aktywności i działań ze świata realnego do przestrzeni wirtualnej sprawia, że produkty cyfrowe zyskują jeszcze bardziej na znaczeniu.

Zakupy, usługi bankowe, rozrywka, nauka. Wszystkie te czynności odbywają się dziś zdalnie, przy użyciu różnego rodzaju aplikacji, systemów i platform. Większa częstotliwość korzystania z takich rozwiązań skutkuje większą świadomością odbiorców, ale także rosnącymi wymaganiami względem kolejnych narzędzi cyfrowych. Branża IT, próbując odpowiedzieć na oczekiwania rynku, mierzy się często z pytaniem, co określa oprogramowanie jako dobre i atrakcyjne. Nie ma prostej odpowiedzi na tak zdefiniowany problem, jako że istnieje wiele płaszczyzn oceny. Wraz z coraz większym wpływem oprogramowania na nasze życie, wytworzenie takiego produktu, który spełni oczekiwania biznesu i zrealizuje założone cele, staje się prawdziwym wyzwaniem.

Założone cele dotyczą trzech głównych obszarów. Pierwszym z nich jest opłacalność przedsięwzięcia, którą określa głównie analiza kosztowa. Drugim istotnym czynnikiem podlegającym ocenie jest techniczna wykonalność projektu, tj. możliwość i łatwość wytworzenia. Niebagatelną rolę odgrywa od kilku lat tak zwane rzemiosło oprogramowania, kładące szczególny nacisk na tworzenie dobrego kodu, który przekłada się na ogólną jakość rozwiązania. Trzeci ważny aspekt, który w procesie tworzenia oprogramowania ma kluczowe znaczenie to tzw. czynnik ludzki.

Podejście zorientowane na człowieka (z ang. human centric approach) wykorzystywane przy tworzeniu innowacji jest tym, które w równym stopniu traktuje wszystkie trzy perspektywy, zwiększając tym samym szanse na stworzenie dobrego oprogramowania – atrakcyjnego i użytecznego. Pisząc o synergii trzech perspektyw: biznesowej, technicznej i tej związanej z użytkownikiem, rzecz wydaje się oczywista. Czy jest jednak tak w praktyce? To już takie oczywiste nie jest.

W przypadku produktu adresowanego na rynek masowy, tendencja do tworzenia oprogramowania użytecznego, oprogramowania pozwalającego na wygodne z niego korzystanie jest obecna od lat. Dostawcy oprogramowania są tutaj zależni od liczby sprzedanych kopii swojego produktu, a dostosowanie do potrzeb użytkownika może być tym czynnikiem, który zadecyduje o sukcesie na rynku. W przypadku oprogramowania bardziej specjalistycznego, albo tworzonego na konkretne zamówienie z przeznaczeniem do użytku wewnętrznego, bywa różnie. Świadomość, że jednym z czynników sukcesu może być użyteczność nie jest tak powszechna. Tendencja jest jednak zauważalna i temat ten zaczyna znaczyć coraz więcej.

Co zrobić, aby nasze oprogramowanie było jak najlepsze?

Zatrudniamy specjalistów od projektowania interfejsu użytkownika, specjalistów UX (którzy zajmują się projektowaniem całościowo interakcji z użytkownikiem, a nie tylko samymi interfejsami). Taka strategia to na pewno dobry start, pozostaje jedynie pytanie, skąd nasi specjaliści mają czerpać wiedzę na temat potrzeb użytkowników oprogramowania, które właśnie tworzymy i w jaki sposób zweryfikować, że stworzyliśmy produkt faktycznie im odpowiadający.

Bardzo często opracowanie konceptu rozwiązania bazuje jedynie na założeniach dotyczących potrzeb i oczekiwań użytkowników, a po informację zwrotną z ich strony sięga się już po wdrożeniu. W takiej sytuacji ryzykujemy tym, że, rozwiązania będą słabo dostosowane, a opinie użytkowników na temat rezultatu prac, albo w ogóle nie będą brane pod uwagę, albo koszt zmian będzie tak duży, że mało kto się na nie zdecyduje. Czy kwestionujemy tutaj słuszność przyjętych założeń, umiejętności i wiedzę osób odpowiedzialnych za stworzenie konceptu? Niekoniecznie – warto po prostu zauważyć, że najlepsi specjaliści mogą mieć problem z przygotowaniem właściwego rozwiązania, gdy nie będą mieć z jednej strony odpowiedniej wiedzy na temat potrzeb konkretnie określonych użytkowników, a z drugiej nie będzie możliwości weryfikacji koncepcji czy rozwiązań na tyle wcześnie, aby zminimalizować koszt i ryzyko niewłaściwego rozwiązania.

Badania użytkowników, zarówno na etapie odkrywania potrzeb, jak i weryfikacji propozycji rozwiązań pozwalają na przygotowanie lepszych produktów i zmniejszenie prawdopodobieństwa wystąpienia wielu ryzyk projektowych. Nie każdy klient zna jednak takie podejście i na początku może mieć wątpliwości, czy warto inwestować czas i pieniądze w imię późniejszych korzyści. Dodatkowo uwzględnienie kolejnych aktywności w projekcie nie pozostaje bez wpływu na resztę zespołu i dobrze jest być przygotowanym na komplikacje, które w tym obszarze mogą się ujawnić.

Dlaczego badać na początku?

Powstało wiele barwnych anegdot, żartów czy internetowych filmików na temat tego, jak wygląda tworzenie nowych produktów. Klient, który nie wie, czego chce, albo wydaje się mu, że wie jest po jednej stronie, po drugiej są twórcy przyszłego oprogramowania, mający najczęściej wiedzę techniczną, ale z brakującą im wiedzą na temat biznesu, który prowadzi klient. Najczęściej sceny te są mocno przerysowane, ale istnieje obawa, że w spotkaniu uczestniczą osoby, którym z jednej strony wydaje się, że wiedzą czego potrzebują, a z drugiej, którym wydaje się, że znają rozwiązanie zaspokające te potrzeby.

Jak możemy temu przeciwdziałać? Pierwszą zasadniczą kwestią jest zrozumienie, że klient nie jest tożsamy z użytkownikiem systemu. Wydaje się, że jest to oczywiste, jednak życie pokazuje, że bardzo często spotykamy się z mieszaniem tych pojęć, co prowadzi do niewłaściwych wniosków. Gdy jednak dobrze określimy grupę docelową dla tworzonego oprogramowania, możemy zdiagnozować jej potrzeby oraz aktywnie wyjść im naprzeciw. Taka diagnoza to podstawa w badaniach UX.

Tworzenie innowacji w podejściu zorientowanym na użytkownika należy zacząć od fazy empatii. Badacz UX ma do wyboru szeroki wachlarz metod i technik badawczych, które umożliwiają trafne zidentyfikowanie właściwych potrzeb i problemów. Na tym etapie najczęściej stosowaną metodą jest indywidualny wywiad pogłębiony lub wzbogacone obserwacją badanie kontekstowe. Dopiero dobre zrozumienie perspektywy końcowego użytkownika, może być mocnym fundamentem w procesie projektowania docelowego rozwiązania.

Dlaczego badać w trakcie?

Gdy jesteśmy w trakcie rozwoju oprogramowania i korzystamy ze zwinnego podejścia, wówczas równolegle z samym tworzeniem, musimy doprecyzowywać i tworzyć nowe, niezdefiniowane wcześniej historie. W tym przypadku korzystne będzie ponowne wykorzystanie tych metod, które stosowane były na początku projektu. Właściwe zrozumienie poszczególnych zadań oraz określenie priorytetów, które wynikają z analizy potrzeb użytkowników przełożą się na skuteczną realizację kolejnych funkcjonalności.

Zgodnie z duchem zwinnego rozwoju każda z nowych opcji systemu powinna dodawać realną wartość dla użytkownika. O wartości tej decyduje nie tylko sam fakt realizacji konkretnego celu, ale także wrażenie i doświadczenie, jakie temu towarzyszą. Najlepszą metodą weryfikacji zaprojektowanych rozwiązań będzie przeprowadzenie testów użyteczności na faktycznych odbiorcach oprogramowania. Konfrontacja prototypu w realnym przypadku użycia przez docelowego odbiorcę pozwoli nam być może uniknąć (a na pewno zmniejszyć ryzyko wystąpienia) nieprzyjemnego zaskoczenia przy ostatecznym wdrożeniu oprogramowania.

Szczególną uwagę należy zwrócić na wymagania niefunkcjonalne. Aby mieć pełną jasność celów biznesowych, bardzo często twórcy oprogramowania oczekują zdefiniowania przez klienta wielu takich wymogów. Odpowiedzi na takie pytania często nie są poparte twardymi danymi, ani też nie identyfikują mierzalnych wskaźników. To na przykład często dotyka czasów reakcji systemu na zdarzenia. Realizacja takiego wymagania często jest trudna lub bardzo kosztowna. Dobra weryfikacja rzeczywistych potrzeb i celów użytkownika, a kolejno dostosowanie wymagań i rozwiązania do tychże oczekiwań, może być kluczem sukcesu projektu – nie skupiamy się na dążeniu do trudno osiągalnego ideału tam, gdzie jest to zbyt kosztowne, a zdiagnozowane jako niepotrzebne.

Dodatkowo nawet jeśli mamy ten komfort i współpracujemy z (przyszłymi) użytkownikami w kolejnych etapach rozwoju produktu, to musimy pamiętać, że jeśli chcemy stworzyć produkt „przyjazny” czy „intuicyjny”, to tym współpracującym użytkownikom może być ciężko krytycznie spojrzeć na efekt pracy. Ich trwałe uczestnictwo w projekcie powoduje, że mają znacznie większą wiedzę na temat tego, jak i dlaczego powstały pewne koncepcje, a zatem wszystko staje się dla nich „oczywiste”. Tej wiedzy użytkownicy nie zaangażowani w postawanie produktu mieć nie będą, zatem warto zbadać, jak oni będą go odbierać.

Dlaczego badać na końcu?

Każdy projekt kiedyś się kończy. Między innymi tym właśnie odróżnia się od procesu, który może trwać teoretycznie „wiecznie”. Warto zwrócić na ten niuans uwagę, gdy śledzi się popularne praktyki dotyczące tworzenia oprogramowania. Bardzo popularne jest podejście do tworzenia rozwiązań informatycznych, zarówno od strony technologicznej, jak i samego procesu na wzór popularnych dostawców usług internetowych. Podążając za nimi, trzeba pamiętać, że tworzą oni oprogramowanie głównie na własne potrzeby i jest ono immanentnie związane z ich działalnością. W przypadku tych firm oprogramowanie jest rozwijane w procesie (choć oczywiście może składać się on z projektów). Jeśli zaś pracuje się w projektach np. na zlecenie klientów, to czas, kiedy prace się kończą jest znacznie wyraźniejszy.

Tę różnicę widać także przy podejściu do badań – w przypadku procesu, gdy nie ma zdefiniowanego końca, cały czas jesteśmy „w trakcie prac” i postępujemy tak, aby ustawicznie uwzględniać, zmieniające się również w czasie, potrzeby użytkowników. W projekcie, kiedy pewna wersja oprogramowania jest zamknięta, wówczas można przygotować rozwiązania, które pozwolą klientowi w pewnym stopniu monitorować odbiór wdrożonego produktu i pozwolą zweryfikować, czy założenia faktycznie przełożyły się na zadowolenie użytkowników.

Dodatkowo, pomimo, że testy użytkowników przeprowadzamy na potencjalnych lub faktycznych użytkownikach systemu, to jednak może się okazać, że w większym gronie osób korzystających z naszego produktu pojawią się problemy, bądź spostrzeżenia, których wcześniej nie mieliśmy okazji poznać. Z jednej strony korzystne jest w takim przypadku skorzystanie z badań użytkowników w grupie/grupach faktycznych, niezwiązanych wcześniej z projektem. Potencjalnym problemem może być (jeśli jest to na przykład produkt przeznaczony na rynek konsumencki) dotarcie do odpowiedniej grupy oraz koszt przeprowadzenia takich badań. Tu możemy skorzystać z popularnych w wielu branżach metod badania doświadczeń użytkowników bazujących na zbieranym feedbacku (np. NPS, CES, CSI).

Innym rozwiązaniem jest monitorowanie sposobu korzystania z oprogramowania przez użytkowników. Metody te są stosunkowo proste w przypadku rozwiązań webowych czy mobilnych, mogą jednak nastręczać większych problemów w przypadku oprogramowania do instalowania na komputerach użytkowników. Nie każdy użytkownik chce być „śledzony”, a dodatkowo nagminny proceder nadużywania tego typu działań w celach profilowania osób, bądź też wykorzystywania pozyskanych w ten sposób danych do prowadzenia działań na granicy legalności, powoduje, że wiele osób reaguje negatywnie na tego typu propozycje ze strony oprogramowania. Dotyczy to zarówno raportów z błędów, jak i okresowego przesyłania danych o sposobie korzystania z aplikacji.

Wytworzenie dobrego oprogramowania to nie tylko wyzwanie technologiczne. Całościowe spojrzenie na problem dotyka także obszaru zrozumienia potrzeb jego przyszłego użytkownika. Synergia tych spojrzeń z pewnością przełoży się na dostarczenie lepszego rozwiązania. Nie oznacza to oczywiście, że takie podejście nie stanowi wyzwania samego w sobie – o tym, jaki jest wpływ różnych spojrzeń na ten sam problem i jak stworzyć dobrą organizację pracy opowiada nasza prezentacja dostępna pod linkiem.