Excel, tabelki i empatia – cała prawda o Enterprise UX

Okej, dobra. To w takim razie już od tego roku przestaje liczyć swój czas. No i tak naprawdę właśnie nie mieliśmy okazji współpracować razem w jakimś jednym projekcie, więc bardzo mi miło ciebie powitać i cieszę się, że będziemy mieć okazję właśnie porozmawiania na takie tematy zawodowe i myślę, że dzisiejszym tematem, który będzie się skupiał na Enterprise UX, czyli rozwiązaniach UX-owych, ale bardziej nastawionych na aplikacje korporacyjne. Dużych firm, tak, dokładnie. Tak, dużych firm, dokładnie. Przede wszystkim, Ania, powiedz mi, w jaki sposób ty byś zdefiniowała, jakbyś właśnie wyróżniła tego typu rozwiązania od typowego UX?

W ogóle bardzo się cieszę, że mamy właśnie okazję o tym porozmawiać, tak? No bo to są takie tematy, które tyczą i mnie i ciebie, a tak naprawdę jakoś nie było okazji, więc chętnie też usłyszę, jakie ty masz przeżycia związane z tym tematem. Ale jeśli chodzi o samą definicję, mamy pojęcie Enterprise UX. No czym jest UX? Ja może tak dla osób, które mnie w pełni kojarzą, powiedzmy czym jest UX. W takiej powiedzmy najbardziej standardowej definicji jest to po prostu taki zbiór wszystkich doświadczeń, przeżyć, emocji użytkownika, który korzysta z danego produktu cyfrowego bądź też na przykład usługi. Więc my też będziemy tutaj mówić oczywiście w kontekście też trochę UI, czyli User Interface Design, ale jeśli chodzi o samo pojęcie Enterprise, no to tutaj już troszeczkę wyjaśniłeś, są to po prostu też w takim tłumaczeniu po prostu przedsiębiorstwa.

Czyli to są firmy, są to organizacje, które działają po prostu na dużą skalę, mają duże zasoby technologiczne, duże zasoby ludzkie i też bardzo często działają na wielu rynkach, w wielu krajach. Więc tutaj po prostu skala tej złożoności jest bardzo duża, no i siłą rzeczy ma swoją jakąś tam charakterystyczną specyfikę. Wydaje mi się, że tak w opozycji do tego, Tutaj mówimy o takim UX-ie, który jest UX-em tzw. B2C, czyli po prostu konsumenckim. Ja nie jestem oczywiście fanką tworzenia nowych podziałów w branży, bo tych podziałów już mamy bardzo dużo. Mamy np. Product Designera w kontekście ról, UX Designera, Interaction Designera. Nie chodzi tutaj trochę o to, aby tworzyć nowy podział, czyli powiedzmy ten standardowy UX i Enterprise UX, ale troszeczkę myślę, że na tyle jest to charakterystyczna gdzieś tam dziedzina, plus ja sama powiem, że

Ja przychodząc do Capgemini, ja wcześniej miałam doświadczenia bardziej z tym takim typowym, powiedzmy standardowym UX-em konsumenckim powiedzmy, chętnie też bym się czegoś dowiedziała. Nie chcę nazywać tego może tematem tabu jako tako, ale po prostu jest to może troszeczkę mniej zaopiekowana dziedzina, chociaż też mi się wydaje, że to się zmienia. Tak i tutaj właśnie my mamy bardzo podobny background tak naprawdę, bo oboje jesteśmy po Akademii Sztuk Pięknych. Później przez kilka lat pracowaliśmy na takim rynku myślę, że bardziej reklamowym, wizualnym, właśnie skierowanym na klienta końcowego i tutaj pojawiamy się w świecie korporacyjnym w Capgemini. Mówię jakby od strony czysto zawodowej projektów, które prowadzimy i rzeczywiście jeżeli chodzi o taki Enterprise UX, o te rozwiązania właśnie dla dużych firm,

One mocno się różnią od tego, do czego przywykliśmy i na pewne inne kwestie po prostu jest nakładany nacisk. Jak byś mogła zdefiniować użytkowników? To jest dla nas istotne. Cała nasza praca opiera się o użytkownika. Jakie widzisz różnice tutaj? Różnic jest trochę. Mimo wszystko, oczywiście my jako UX designerzy projektujemy dla użytkowników i my jesteśmy tak zwanymi adwokatami użytkownika, ale najważniejsze jest to, że sam typ tego użytkownika to jest osoba, która używa tych narzędzi w pracy. Czyli to nie jest osoba, która powiedzmy z ulicy wejdzie sobie do jakiegoś narzędzia, chociaż oczywiście są wyjątki, bo są aplikacje, które są powiedzmy tak z pogranicza troszeczkę Enterprise, a też takich komercyjnych narzędzi, ale głównie to, co my robimy w pracy i duże firmy, dla których my pracujemy, no to tutaj grupa użytkowników są to osoby, które są po prostu na przykład zatrudnione przez klienta albo są klientami naszego klienta też.

Są to osoby, które na co dzień też, użytkownicy to są osoby, które na co dzień często pracują też z wieloma innymi aplikacjami i mają przez to też dosyć niską tolerancję na błędy i tutaj oczywiście wszyscy użytkownicy mają niską tolerancję na błędy bez względu na to czy jest to Enterprise czy nie, ale te błędy mają sporo wydaje mi się większą trochę Names mentioned in English. No to tutaj konsekwencje mogą być znacznie większe, tak? No bo może to mieć wpływ albo na biznes, albo na jego reputację, albo na jakąś personalną ocenę tego użytkownika. Więc jakby ta tolerancja może jest podobna, ale po prostu wpływ tego jest inny.

On po prostu musi korzystać z tych narzędzi bardzo często. I nie mówię tutaj oczywiście, że jego zdanie nie ma znaczenia kompletnie, bo jednak mierzy się też takie metryki jak zadowolenie pracowników, prawda, są jakieś ankiety wysyłane gdzieś i jakieś narzędzie jest naprawdę problematyczne, to ten użytkownik, miejmy nadzieję, że ma szansę się wypowiedzieć. Ale w dużej mierze to nie jest jego decyzja. Dlatego też wydaje mi się, że tutaj bardzo mocno też leży sedno tych różnic. Dlatego, że w przypadku aplikacji komercyjnych ten UX i doświadczenia tego użytkownika są bardzo blisko powiązane z biznesem i z tym, jakie wyniki finansowe ma dana aplikacja. Z kolei, jeśli patrzymy na Enterprise UX, oczywiście, że wydajność tych użytkowników i sposób w jaki pracują i szybkość tej pracy jest ważna, ale jednak są też inne czynniki, które są brane pod uwagę podczas zakupu danej aplikacji.

Są to kwestie, właśnie to o czym powiedziałeś Krzysiu, związane z bezpieczeństwem. Czyli na przykład z tym, gdzie są trzymane dane, czy to są serwery w Europie, czy ilość funkcjonalności, jak jest dostępna w konkretnym narzędziu. Więc wydaje mi się, że tutaj tak, ta decyzyjność tego użytkownika jest dosyć istotna. Tak, już wyłuskałem, że tak powiem, kilka takich istotnych tych kwestii. Czas spędzony w aplikacji to nie jest kwestia pięciu, dziesięciu minut, można powiedzieć. Właśnie to, czy możemy sobie wybrać aplikację konkurencyjną w Enterprise, często właśnie nie mamy tak naprawdę wyboru. I kolejnym takim czynnikiem jest efektywność i minimalizacja jakichś błędów popełnianych w aplikacji. Czyli kwestia sprawności wykonywania pewnych zadań cyklicznych.

I ja pamiętam, że to był taki moment, kiedy były dyskusje w projekcie, czy powinny być karty czy tabele, czy mamy wyświetlać dane jako karty czy tabele. To była taka bardzo zaostrzona dyskusja, że tak powiem. No ja oczywiście dosyć szybko byłam za tym, żeby to były po prostu tabele, ale potem jeszcze sam ten kontekst używania wielu danych. Ja przyznam też, że trafiłam na użytkowników, którzy pomimo tego, że byli w stanie coś zrobić w aplikacji webowej, oni i tak korzystali z Excela. Oni mieli tak silne przywiązanie do Excela, Że po prostu woleli to zrobić tam. I wydaje mi się, że to też jest taka charakterystyka użytkowników enterprise'owych. Oni się bardzo boją ryzyka. Oni, jak mają wygodne kapcie, wygodne rozwiązania, to oni niechętnie z nich wyjdą. Ja się też nie dziwię, dlatego mówiliśmy o tym. Konsekwencje zmian, te zmiany też muszą zachodzić, wydaje mi się, że raczej stopniowo.

Jeśli dokonujemy jakiejś po prostu rewolucji, a nie ewolucji, To często też te aplikacje są wdrażane pilotażowo na niektóre rynki. Ale tak, ta różnica, o której ty powiedziałeś Krzysiu, też a propos właśnie white space'ów, czyli tej białej przestrzeni, oddechu, to jest w ogóle też mi się wydaje jedna z takich większych różnic pomiędzy tym UX-em, o którym często słyszymy Na YouTube, Instagramie, te wszystkie rolki, a tym UX-em Enterprise'owym, bo większość tych rad, które są dawane początkującym designerom czy w ogóle designerom, to one są właśnie bardzo często skrojone pod ten taki konsumencki UX. A ja kiedyś widziałam w ogóle świetne wystąpienie i to było na konferencji FIGMY. Ja niestety, przygotowując się do naszej rozmowy, próbowałam odnaleźć, uwierz mi, na wszelakie sposoby, więc możliwe, że też mi się to przyśniło, ale próbowałam odnaleźć to nagranie.

Ja je pamiętam bardzo dobrze, dobre wrażenie na mnie zrobiło, dlatego że prezentowała designerka taki case, gdzie przeprojektowała FIGMY, interfejs FIGMY, zgodnie ze wszystkimi złotymi radami UX i UI. I no przysięgam, jakby wyglądało to komicznie. A dlaczego? No dlatego, że te złote rady właśnie bardzo często nie mają zastosowania w środowisku takim zawodowym, bo jest też coś takiego jak krzywa poznania, tak? I w przypadku aplikacji konsumenckich, takich komercyjnych, bardzo często my chcemy ograniczyć po prostu do minimum, żeby ten użytkownik w ogóle on nie musiał, żeby samo się klikało praktycznie, tak? Żeby on nic nie musiał myśleć. I to jest okej, jakby to jest taki kontekst, tak? Ale w przypadku tych enterprise'owych Ta krzywa uczenia się jest okej.

I w tym kontekście my jako User Experience Designerzy musimy pamiętać, to jest nasz użytkownik, on o to prosi tak naprawdę, więc do niego się dostosujmy, a nie do jakichś tam prawideł, mądrości z YouTube, ze szkoleń itd. I to jest też kolejny ciekawy wątek, który poruszyłeś, że tak naprawdę ta wiedza o Enterprise UX jest, nie chciałbym powiedzieć unikalna, ale na pewno trudniej dostępna na rynku. Ja nie widzę zbyt wielu szkoleń tak naprawdę, które by tym się zajmowały. To prawda, to wydaje mi się, że to też nie chodzi o to, żeby kompletnie odchodzić od tego, co zostało powiedziane, bo to jest dobry punkt wyjścia, ale też mieć ten właśnie zdroworozsądkowe podejście do tego i co najważniejsze, no rozmawiać z tymi użytkownikami, tak?

I tu jest prawdziwa ta istota tej empatii, o której tak dużo się mówi w tym zawodzie projektowania doświadczeń, że tak, to zempatyzuj z użytkownikiem, porozmawiaj z nim, zrozum go, co też jeszcze a propos empatii tylko powiem, że ta empatia w przypadku projektowania dla Enterprise, ona też powinna mieć troszeczkę szerszy zakres. I co mam tutaj na myśli? My też bardzo mocno pracujemy w środowisku biznesowym i tworzymy też rozwiązania dla biznesu. I wydaje mi się, że ta empatyzacja też z osobami takimi jak managerzy, project managerzy, product ownerzy, ona też jest ważna. Dlatego, że oczywiście my jesteśmy w pierwszej, ja przynajmniej wychodzę z takiego założenia, że ja w pierwszej kolejności jestem adwokatką użytkownika. Ale też muszę zrozumieć, wydaje mi się, że to też jest taki gdzieś tam krok przełomowy, kiedy designerzy zrozumieją, że my pomagamy bardzo często osobom takim jak project managerzy czy product ownerzy stworzyć jakieś rozwiązanie, jakąś funkcjonalność i musimy tutaj pogodzić te wszystkie aspekty.

No i nagle okazało się, że przy spotkaniu z użytkownikami, że tak naprawdę Oni używają wręcz innej nomenklatury. Coś, co było tam nazwane jakimś poziomem w układzie, całkowicie inaczej interpretowali niż my. I musieliśmy sobie uzmysłowić i też ustalić tą wspólną nomenklaturę, żeby rozumieć się dalej w całym tym procesie. Więc tak, ta empatia, zrozumienie użytkownika jest na pewno kluczowa. Ale też dodam, że to jest też ciekawy temat, który poruszyłeś a propos właśnie nomenklatury, a propos w ogóle funkcjonowania designera w środowisku takim enterprise'owym, w środowisku, które jest naprawdę trudne do wgryzienia się.

No tutaj akurat Capgemini wprowadza właśnie te szkolenia domenowe, co też jest fajnym krokiem tak naprawdę właśnie, żebyśmy zgłębiali wiedzę, powtórzę się, domenową, która lepiej nas przygotowuje do rozumienia całego kontekstu danej branży, w jakiej się obracamy i w jakiej pracujemy. Jeżeli byłabyś w stanie wskazać, co w tych aplikacjach Enterprise UX jest ważne? Ważne jest bardzo wiele rzeczy, ale jakie rozwiązania? Ja myślę, że to, co trochę widzę i kierunek, w którym wydaje mi się fajnie, jak tego typu rozwiązania idą, jest to personalizacja, dlatego że bardzo często, moje doświadczenie jest takie i aplikacje, z którymi ja pracowałam, że często te rozwiązania to są duże firmy i one pracują na przykład na różnych rynkach.

Użytkownik może sobie wybrać, czy ma ten cozy, comfortable, czy tam właśnie tight, czy minimal ten interfejs. I właśnie tutaj sobie sam steruje tym zagęszczeniem danych. Tak, to prawda. Ja też lubię rozwiązanie. Ty pewnie kojarzysz takie narzędzie jak Adobe InDesign. I nie kojarzę, czy to jest w innych aplikacjach Adobe, ale tam jest opcja, aby zmienić sobie właśnie układ tych wszystkich jakby informacji i funkcji. I tam jest właśnie Essential, jest Advanced. I może tam jakby szczerze mówiąc nie czujesz takiej wielkiej różnicy. Też mi się wydaje, że to akurat z tych wszystkich programów Adobe jest dosyć taki już bardziej właśnie enterprise'owy, powiedzmy profesjonalny. Ale wydaje mi się, że to też jest szczególnie w przypadku produktów Znowu, jak tu dopasować?

Żeby to pasowało wszystkim przy jednoczesnym zachowaniu jakiegoś takiego zdrowego rozsądku przy projektowaniu. I wydaje mi się, że gdzieś tam właśnie ta personalizacja to jest przyszłość. A twoja sytuacja też właśnie bardzo ciekawa z tymi użytkownikami, że grupa jakaś jedna i to jest też mi się wydaje duża różnica w Enterprise UX, że te grupy w ogóle do researchu są szersze. To jest dosyć duża różnica. Normalnie ta rekomendacja, tak sześć użytkowników, odkryjesz po prostu tam 80 czy 90% błędów, wszystko będzie super. No tutaj mamy różne rynki, właśnie różne procesy, różne konteksty i tego researchu po prostu ta grupa musi być większa. Więc tak, to też jest jakaś taka istotna różnica. My jeszcze w projekcie mamy to, że obsługujemy kilka kraj i każdy z nich ma inne procesy, a że tak powiem takie procesy papierowe, jeszcze stare, tak?

Różnica, przynajmniej z mojego doświadczenia, jest taka, że konkretne etapy trwają albo trochę dłużej, albo trochę krócej. Bo na przykład, jeśli mamy ten pierwszy etap, gdzieś tam zdefiniowania, empatyzacji, my chcemy zrozumieć, co my w ogóle mamy robić, zbieramy, analizujemy, rozmawiamy z użytkownikami, to ten etap potrafi być bardzo długi. I znowu, to wynika po prostu ze złożoności konkretnych tematów, jakichś biznesowych problemów. Jeśli chodzi o etap samego researchu, To tutaj też dodam, i to jest duży plus Enterprise'a, że łatwiej jesteśmy w stanie pozyskać tych użytkowników, dlatego że tak długo jak to są użytkownicy, którzy po prostu pracują dla tego klienta, to jest kwestia pogadania z nimi na Teams'ach często. I oczywiście ja jestem zawsze za tym, żeby to było robione nie tam ej, hej, co myślisz o tym, tylko to są normalne sesje z wywiadami, odbywa się to według tej samej struktury, według tego samego planu.

Jak w przypadku wywiadów takich z użytkownikami, którzy nie pracują w firmie. Ale tak, tutaj na pewno jest ta różnica w zbieraniu tych danych. Oczywiście, to też generalizuję tutaj, mogą być bardzo proste aplikacje też enterprise'owe, ale raczej doświadczenie moje jest takie, że to wymaga dobrej też dokumentacji. W ogóle ten pierwszy krok, kiedy ja faktycznie sobie mapuję to, co wiem, albo to, czego nie wiem, albo to, czego chce się dowiedzieć. Nie skakanie i nie przeskakiwanie od razu, to ja już taki szybki wireframe zrobię, chociaż mnie nieraz kusiło, bo znowu, ja mam te nawyki, miałam jeszcze, myślę, że już staram się niwelować je coraz bardziej, albo do zera, ale miałam te nawyki, ja chcę projektować, ja już chcę, żeby to wyglądało. I to była taka lekcja pokory też dla mnie.

Więc tutaj znowu gdzieś są te różnice. Dla mnie ten proces, tak jak mówię, jako designera jest gdzieś tam bazowo podobny, ale różni się w kwestiach nacisku na konkretne etapy. To znowu poruszam ten wątek z początku rozmowy, że tutaj mamy przywiązanie do aplikacji z wyboru i musimy jakby tutaj działać troszeczkę też na dopaminę użytkownika, podsycać ją i cały czas starać się, żeby On miał to poczucie zadowolenia. Niestety w Enterprise'ie no tutaj jest przymus użytkowania tej aplikacji. Ale czy niestety, czy niestety? Zastanów się też, znaczy ja gdzieś tam miałam takie przemyślenie, że my przynajmniej jako designerzy nie musimy lawirować powiedzmy dookoła tych dark patternów, że nie ma czegoś takiego, my nie wciskamy komuś czegoś, nie chcę demonizować tutaj, że cały e-commerce jest po prostu zły i paskudny.

W sumie nie zastanawiałem się nad tym od tej strony, ale... Ciekawe, ciekawe. Mówiłaś tak naprawdę o tym, że taką próbką badawczą powiedzmy, że jest sześć użytkowników. Co jeżeli mamy jeszcze mniejszą tak naprawdę ilość tych użytkowników, którzy potrzebują konkretnej funkcjonalności? Tutaj wszystko tyczy się proporcji, tak? I gdzieś tam tej skali. W zależności od tego bardzo często te enterprise'owe rozwiązania to nie jest wcale setki, dziesiątki, gdzieś tam tysięcy użytkowników, to potrafią być małe grupy. I tutaj wszystko to jest kwestia proporcji. No ta liczba sześciu użytkowników, z którymi powinniśmy rozmawiać, to jest... Też taka wartość z gwiazdką i to nawet Nielsen Norman Group mówił, że ok, to jest 6 jeśli masz bardzo jednolitą grupę.

Jeśli masz tę grupę niejednolitą, no to oczywiście będzie to więcej. Ale mało kto czyta te gwiazdki często, dlatego znowu, te zasady są takie bardzo dla komercyjnego UX-a często i takie ogólne. Ja bym w miarę możliwości zbadała, jaką w ogóle jest grupa użytkowników, jaka to jest proporcja, bo jeśli to jest na tyle mała grupa, to możemy z nim po prostu porozmawiać i zrozumieć, i znaleźć jakieś rozwiązanie. Ale wszystko to jest kwestia skali, myślę. I zbadania tego, jaka tam jest faktycznie aktywność, ilu tych użytkowników jest i na ile to się zmienia. Aczkolwiek to jest też takie typowo enterprise'owe, mi się wydaje. Ja miałam taki projekt, w którym pracowałam kiedyś i to było... Narzędzie, które było jednocześnie wewnętrzne, to znaczy tam pracowali wewnętrzni internalowi, tak zwani operacyjni użytkownicy, którzy powiedzmy zarządzali tam jakimiś zamówieniami.

Wywalamy, tak? Szkoda tego utrzymywać, to kosztuje. W przypadku Enterprise'owych może być ten jeden klient, który sobie wynegocjował, że on tego chce używać i to ma na przykład w umowie i to ma w kontrakcie i to już jest kwestia trochę jakby planowania całego produktu i że nie dało się może tego klienta troszeczkę przekonać i narzucić mimo wszystko jakiś pewien proces, ale często tak jest i to też jest taka... Odwrotność i tworzą się takie kombajny, tak? Jakby ten klient chciał to, ten to i po prostu to też jest bardzo ważna rola, myślę, tutaj project managera, żeby jakoś to pogodzić. To jest właśnie też taka ciekawa zależność, że tutaj, jeżeli mówimy o jednym kliencie, To za tym, w rozwiązaniach B2B, to często za tym jednym klientem, jednym użytkownikiem stoi ogromny biznes tak naprawdę i nie możemy jakby stwierdzić, a nie, to nas nie interesuje i nie dostosujemy się do ciebie.

Tak, dokładnie. A propos tego jeszcze projektu miałam taką ciekawą historię. Trochę to się tyczy różnicy, trochę to się tyczy specyfiki Enterprise. Został zaprojektowany nowy feature, nowa funkcjonalność na życzenie akurat tego jednego klienta. I to kosztowało dużo pieniędzy, ale też to był bardzo duży klient, bardzo duża skala, bardzo duży jakby tutaj zysk jeśli ten klient i to był jego warunek. No więc wszyscy, całe ręce na pokład, wszyscy się zabieramy za ten feature i to miało bardzo szybko. Im szybciej tego klienta po prostu będą w stanie obsługiwać w systemie, tym szybciej zaczną zarabiać duże pieniądze. Akurat ja nie projektowałam tej funkcjonalności, ale później byłam odpowiedzialna za przeprowadzenie researchu i badań już na zaimplementowanym produkcie.

No i wszystko było ugrane, wszystko było gotowe, już praktycznie zaproszenia powysyłane, użytkownicy znalezieni. I nagle dostałam informację od account ownera, że Ania, jednak nie robimy tych testów, nie robimy tych wywiadów. A ja taka zdziwiona, jakby dlaczego? No jakby to chyba tak, jakby fajnie opiekujemy się tym klientem, tak? Chcę mu słyszeć, co on ma do powiedzenia. I on mi zwrócił uwagę, że jeśli coś, my będziemy dokładnie pytać, jeśli coś pójdzie nie tak, jeśli oni coś znajdą, bo już dali taki pierwszy akcept, to oni po prostu nie wygrają tego kontraktu. Czy tam nie przeciągną tak szybko tego klienta i trzeba będzie znowu naprawiać. No i to jest taka kuriozalna sytuacja, tak? No bo normalnie w takim B2C jest tak, że Boże, ten użytkownik, on jest najważniejszy, jak on, jak jemu się nie spodoba, no to przecież on do nas nie przyjdzie. A tutaj sytuacja była taka, nie grzebcie tam tak mocno, później zrobimy, oczywiście nie zrobili, ale to też taka specyficzna chyba wydaje mi się, akurat negatywna enterprise'owa sytuacja i też z niej można lekcję wyciągnąć, tak?