Najskuteczniejsze języki w RPA, integracjach API oraz aplikacjach mobilnych

Tego suchara chyba jeszcze Karol Strasburger nie opowiedział:
– Jaki język jest najczęściej używany przez programistów?

– Wulgarny.

Nie jesteśmy święci, zdarza nam się… Najważniejsze jednak jest dla nas używanie innych dwóch języków: Na początku języka klienta, a potem języka użytkownika. I w efekcie końcowym doprowadzenie do sytuacji pełnego zadowolenia, w której język użytkownika i język zleceniodawcy jest wspólny.

Na etapie briefu czy to rozwiązania klasy RPA, czy aplikacji mobilnej najważniejsze jest dla nas znaleźć wspólny język z klientem. Im lepiej, szybciej i precyzyjniej się dogadamy, tym szybciej i lepszych efektów możemy się spodziewać. O ile w robotyzacji procesów biznesowych oraz w integracjach API możemy więcej podpowiadać, bo znamy możliwe rozwiązania, to w przypadku aplikacji mobilnych najważniejsza jest wizja zleceniodawcy. Nadstawiamy uszu, wytężamy słuch, robimy wszystko, żeby jak najlepiej tę wizję i oczekiwania zleceniodawców poznać i bardzo sobie cenimy, gdy zleceniodawcy chcą poznać uwarunkowania poszczególnych metod. Wizję mamy bowiem wspólną, ale innymi oczami na nią patrzymy. I tu chyba ma być jak z prawdziwą miłością, w której nie chodzi o to, by patrzeć na siebie, ale by patrzeć w tym samym kierunku. Może to i banalne powiedzenie, ale jakże prawdziwe, co piszę z perspektywy osoby, która miesiąc temu zmieniła nazwisko (wraz ze zmianą stanu cywilnego).

Wspólny język biznesu i developerów

Dogłębne poznanie celu, wizji, potrzeb i determinantów istotnych dla zleceniodawcy pozwala nam maksymalnie wyeliminować z naszej komunikacji zwrot „to zależy”, który przecież nie odpowiada na żadne pytanie.

Niezależnie od charakteru aplikacji i grupy docelowej potrzeby poznania są równie istotne. Czy będziemy tworzyć aplikację, której użytkownikiem końcowym będzie grupa bardzo szeroka, czy tylko kilkunastu współpracowników, musimy wiedzieć, jakie ich potrzeby ma zaspokoić i jakie korzyści im przynieść. Bo to ich zadowolenie i chęć korzystania z aplikacji przełożą się na korzyści klienta. Piszę o czymś, co może wydawać się oczywistym, żeby podkreślić wspólnotę celów klientów i developerów – zadowolenie użytkownika. Powinnam może wymyślić jakąś maksymę na ten temat, żeby mieć ją nad biurkiem i wklejać w prezentację. Coś w rodzaju: „Łączy nas user”. Byle nie łączył nas tak, jak z niewychodzeniem z grupy „Łączy nas piłka”.

Łączy nas user

Niestety, już na etapie ustalania usera – najważniejszego łącznika – pojawiają się rozbieżności w podejściu do jego opisywania. Zleceniodawca często uważa, że wie najlepiej, kim jest jego klient/użytkownik i czego potrzebuje. Uprzejmie przyznam, że często jest to prawda. Jednak nauka i doświadczenie nie pozostawiają wątpliwości: Profil klienta/użytkownika lepiej zbudować na podstawie zebranych informacji, a nie na podstawie nawet głęboko przemyślanych wyobrażeń, bo te często będą bliskie tworzeniu „na swój obraz i podobieństwo”. A diabeł tkwi w szczegółach. Na szczęście możemy dać diabłu postać persony. Ponieważ persona jest obrazem naszego przyszłego użytkownika, musimy ją możliwie szczegółowo namalować oczywiście w ścisłej współpracy z protoplastą-zleceniodawcą. Prosty szkic węglem to zdecydowanie za mało. Razem z hasłem „Łączy nas user” nad biurkiem (albo nawet łóżkiem) powinniśmy sobie powiesić portret persony charakteryzujący się głębią kolorów i perspektywy oraz detalami widocznymi także w półcieniach. No odmalujmy go najlepiej jak to możliwe.

Persona reprezentantem segmentu rynku

Nie chciałabym dziś wgłębiać się w dywagacje związane z zestawieniem pojęć personifikacja i segmentacja. Najważniejsze jest, żeby przyszłego usera naszej aplikacji – reprezentanta segmentu rynku, poznać najlepiej jak się da, żeby – też najlepiej jak się da – spełniać jego oczekiwania.

Jakimi danymi opisać? Można zacząć od najprostszych – od płci. Hm, ledwo to napisałam, to pożałowałam. Bo według jakiej płci? Hormonalnej, psychologicznej, społecznej, gonadalnej, somatycznej, czy metabolicznej? Czy może jeszcze jakiejś innej, którą pominęłam? Wbrew pierwszej reakcji, wskazania na płeć, jako najprostszy z wyróżników cech persony, przestałam już żałować. Bo na tym „najprostszym” przykładzie widzimy, jak skomplikowany może być proces tworzenia persony. A skoro skomplikowany, to drogi i czasochłonny, prawda? Prawda, ale to inwestycja, która najpewniej się zwraca. Bo tworzenie aplikacji dla niezidentyfikowanego obiektu latającego po rynku sprzedaży jest jak łapanie klienta na lasso, którego pętla się nie zaciska albo jak zamieszczanie przez Polską Grupę Zbrojeniową reklam transporterów opancerzonych w miesięczniku ewangelizacyjnym „Miłujcie się!”.

Cel marketingowy

Przykład z reklamą PGZ, która absolutnie nie trafiała do grupy docelowej, nie jest wcale oderwany od rzeczywistości. Ale my – tak klienci, jak i developerzy – dla których liczy się rachunek ekonomiczny i zwrot z inwestycji („Łączy nas ROI”), już na etapie projektowania aplikacji, a nie w procesie opracowywania strategii reklamowej powinniśmy kształtować lejek sprzedażowy. Oczywistą oczywistością jest, że jeśli aplikacja ma charakter komercyjny, to od czasu inkubacji musi mieć strategię marketingową. A jeśli nie ma charakteru komercyjnego, bo ma służyć tylko pracownikom firmy, to musi być dla nich user-friendly. Do tego służy nam tworzenie person i analiza wzorców zachowań. I do tego służy nam UX designer. On ma przewidzieć (na podstawie analiz) oczekiwania użytkowania i zaprojektować jego doznania. Zamiast kropki powinien być wykrzyknik: zaprojektować doznania użytkownika!

Adwokat użytkownika końcowego

Napisałam o tym, ponieważ zdarza nam się czasem (czasem, ale i tak zbyt często), że musimy rozwiewać wątpliwości klientów dotyczące zakresu pracy UX designera. Czasem zleceniodawcom wydaje się, że o UX-ie trzeba myśleć na etapie doskonalenia interfejsu. Dlatego proponujemy już na początku przyjąć, że projektant UX będzie adwokatem przyszłego użytkownika aplikacji w całym procesie jej powstawania. To on jako pierwszy ma znaleźć wspólny język z klientem, żeby móc potem mówić (jak adwokat) językiem użytkownika. Bo najskuteczniejsze języki w RPA, integracjach API oraz aplikacjach mobilnych to języki wspólne. Unikajmy sytuacji, w której najpierw pociągniemy sprawę sami, a dopiero w wypadku przegranej w pierwszej instancji zdecydujemy się na adwokata do apelacji. Bo na takim rozwiązaniu trudno wygrać. Ja natomiast muszę w następnym wpisie zostać adwokatem obszaru UX.