User eXperience

Gdybym miał w największym skrócie wyjaśnić, czym jest User eXperience (UX), to powiedziałbym, że to odczucia, które towarzyszą osobie użytkowniczej w trakcie interakcji z naszą stroną WWW. A te mogą być pozytywne albo negatywne. Naszym zadaniem, jako osób webdeveloperskich, jest upewnienie się, że tych pierwszych będzie zdecydowanie więcej. A najlepszym sposobem na to jest stworzenie strony w jak najbardziej użyteczny sposób. Ale co to znaczy “użyteczny”? Steve Krug w swojej książce Don’t Make Me Think, Revisited we wstępie proponuje następującą definicję:

A person of average (or even below average) ability and experience can figure out how to use the thing to accomplish something without it being more trouble than it’s worth.

[Osoba o przeciętnych (lub poniżej przeciętnych) umiejętnościach i doświadczeniu jest w stanie zrozumieć, w jaki sposób użyć danej rzeczy do osiągnięcia swojego celu bez poczucia, że jest to warte mniej, niż wysiłek włożony w to zrozumienie.]

Innymi słowy: dobry UX jest powiązany z wysokim poziomem intuicyjności strony WWW. Ale można też rozpatrywać tę kwestię niejako na poziomie niżej: samego zapewnienia usługi. Jeśli strona jest niewydajna albo nieresponsywna, to UX będzie zdecydowanie gorszy, niż na wydajnej, responsywnej stronie. A równocześnie: bardzo wolna strona, ale wciąż spełniająca swoje zadanie, będzie lepsza od strony, która najzwyczajniej w świecie nie działa. UX to spektrum doświadczenia, nie stan binarny. I prawie zawsze jest coś, co można zrobić lepiej. Np. poprawić UX poprzez zadbanie o dostępność i celowość animacji na stronie. Takie rzeczy, choć mogą wydawać się drobnymi szczegółami, są w stanie sprawić, że niektóre osoby użytkownicze w ogóle będą mogły skorzystać z naszej strony WWW.

Nie można przy tym zapominać, że UX dotyka wszystkich sfer interakcji ze stroną WWW. Zatem sam wizualny design i zadbanie o jego łatwość użycia to często za mało. Zwłaszcza obecnie, gdy istnieje tak wiele sposobów interakcji z urządzeniami. Dobrym przykładem może być interfejs głosowy. UX powiązany jest także z samą treścią i jej planowaniem. Wchodzi też mocno w obszar designu i decydować może m.in. o doborze kolorów, typografii czy wielkości elementów interaktywnych. Słowem: wszystko to, co jest widoczne dla osoby użytkowniczej, może być rozpatrywane z perspektywy UX-u. W końcu skoro coś jest dostępne dla osoby użytkowniczej, to stanowi część jej doświadczenia.

Zasady

UX jest już dziedziną dosyć dojrzałą, a to oznacza, że powstały dobre praktyki i zasady pomagające nam w tworzeniu jak najbardziej użytecznych rozwiązań. Takim zbiorem podstawowych dobrych praktyk jest 10 heurystyk Nielsena:

  1. Widoczność statusu systemu.
  2. Powiązanie między systemem a światem rzeczywistym.
  3. Kontrola po stronie osoby użytkowniczej oraz wolność wyboru.
  4. Spójność i standardy.
  5. Zapobieganie błędom.
  6. Umożliwienie rozpoznawania informacji zamiast ich zapamiętywania.
  7. Elastyczność i efektywność używania interfejsu.
  8. Estetyka i minimalistyczny design.
  9. Pomaganie osobom użytkowniczym rozpoznawać, diagnozować i poprawiać błędy.
  10. Pomoc i dokumentacja.

Często w projektowaniu użytecznych interfejsów stosuje się także prawa lokalności:

  1. Umieść element kontrolujący daną akcję w miejscu, w którym ta akcja zachodzi.
  2. Jeśli akcja obejmuje cały obszar, umieść element kontrolujący daną akcję nad tym obszarem.
  3. Im dalej jest element kontrolujący daną akcję od miejsca, w którym ta akcja zachodzi, tym bardziej ten element powinien się wyróżniać.

Istnieją też inne zbiory zasad, jak np. ACTION:

  1. Appeal – wygląd,
  2. Clarity – czytelność,
  3. Typography – typografia,
  4. Interaction – interakcja,
  5. Order – porządek,
  6. Navigation – nawigacja.

Warto też przytoczyć zasadę proponowaną przez Steve’a Kruga, czyli: “Nie każ mi myśleć”. Interfejs strony powinien być jak najprostszy – tak, aby posługiwanie się nim było intuicyjne i przychodziło osobie użytkowniczej wręcz naturalnie. Często oznacza to ograniczenie kreatywności na rzecz przewidywalności. Innowacyjne interfejsy są wizualnie przyciągające, ale często stanowią wyzwanie w trakcie używania ich. Osoba użytkownicza bowiem styka się z danymi wzorcami po raz pierwszy i musi się ich nauczyć. Warto przy tym też zauważyć, że interfejs powinien być prosty, ale równocześnie – nie za prosty. Czasami osoba użytkownicza powinna mieć możliwość pomyślenia. Zwłaszcza, jeśli za jakimś elementem interfejsu kryje się funkcja dotykająca jej prywatności.

Research

Jednym z najważniejszych elementów dbania o dobry UX jest odpowiedni research. Najważniejszym jego elementem bez wątpienia są testy z osobami użytkowniczymi, które pozwalają zweryfikować, czy dobrze rozumiemy ich potrzeby. To oczywiście pociąga za sobą zaplanowanie całego przebiegu i celu badania oraz konieczność doboru odpowiedniej grupy badanych. Skoro już bowiem prosimy osoby użytkownicze o poświęcenie nam czasu na podzielenie się z nami ich doświadczeniami z naszym produktem, to powinniśmy szanować ten czas i wykorzystać go jak najbardziej produktywnie. Takie badania pozwalają zebrać potrzebne dane, na podstawie których można następnie decydować, w którą stronę produkt powinien skręcić.

Dane są zresztą najistotniejszą częścią całego researchu. To one pozwalają nam w pełni zrozumieć, w jaki sposób osoby użytkownicze używają naszej aplikacji i po co to robią. I dopiero mając te informacje, możemy decydować, jak rozwijać produkt tak, aby wciąż dostarczał odpowiednio wysoki UX. A równocześnie nie należy zapominać, że dane nie są wszystkim. Często zamiast skupiać się wyłącznie na suchych informacjach warto też zdać się na doświadczenie czy intuicję. Tego typu “odstępstwa” czasami pozwalają na wprowadzenie jakiegoś innowacyjnego rozwiązania, którego nie da się wyczytać z dostępnych danych. Zwłaszcza, że te niekoniecznie muszą oddawać rzeczywistość – a przynajmniej nie jej pełnię. W zależności od tego, jak zdobywamy informacje o naszych osobach użytkowniczych, część z nich może być w nich niereprezentowana. A tym samym: nigdy nie dowiemy się o tym, jakie potrzeby ma jakaś grupa naszych osób użytkowniczych. Tutaj z pomocą mogą przyjść persony – czyli niejako syntetyczne osoby użytkownicze, które mają pewne cechy i cele, dla których korzystają z naszej aplikacji. Persony to ciekawy eksperyment myślowy, który pozwala zasymulować interakcję konkretnej osoby użytkowniczej z naszą stroną i przewidzieć, w jaki sposób taka osoba będzie się zachowywać i co można poprawić, żeby lepiej się jej pracowało z naszym produktem. Obecnie często zauważa się, że persony zbytnio upraszczają rzeczywistość, dlatego proponuje się alternatywne rozwiązania, takie jak spektrum person, które do symulacji dorzucają m.in. informacje o możliwych niepełnosprawnościach danej osoby użytkowniczej. Dzięki temu research od razu odpowiada na pytanie, w jaki sposób usunąć bariery, które przeszkadzają różnych osobom korzystać z naszej aplikacji.

Warto pamiętać, że research UX-owy nie może sprowadzać się wyłącznie do testowania z osobami użytkowniczymi i opierania się na danych. To nieustanny cykl wymyślania, wdrażania i testowania nowych rozwiązań, których zadaniem ma być poprawianie UX.

UX a UI

Gdyby nad tym nieco pomyśleć, to Sieć jest dziwną platformą. Ot, weźmy taką osobę developerską, która tworzy aplikacje mobilne. Owszem, istnieje zbiór jakichś uznanych ogólnie praktyk, których wypada przestrzegać. Ale te praktyki najczęściej są na tyle ogólne, że można podejść do nich na wiele spososów. Ostatecznie to osoba developerska decyduje o tym, jak wygląda aplikacja. W przypadku Sieci jest jednak inaczej. Najczęściej osoba użytkownicza widzi naszą stronę wczytaną w przeglądarce. To ona jest niejako filtrem, który nie pozwala osobie użytkowniczej dotknąć strony bezpośrednio. A to oznacza, ze jako osoby webdeveloperskie nie mamy pełnej kontroli nad wyglądem strony. Zawsze będzie ona wepchnięta w ramy przeglądarki, która ma swój własny UI. Co więcej, strona powinna współpracować z funkcjami, które przeglądarka udostępnia – jak choćby przyciskami do sterowania historią przeglądania. Strona musi być niejako posłuszna przeglądarce, a tym samym – także i osobie użytkowniczej, która wchodzi w interakcję z naszą stroną właśnie przy pomocy przeglądarki. Nawet w przypadku PWA, przy których można wyeliminować UI przeglądarki, wciąż przecież działa ona pod spodem, ograniczając to, jak zaprojektować można doświadczenie osoby użytkowniczej.

Jest jeszcze jeden element strony, który istnieje z powodu czysto technicznego, ale równocześnie – dobrze zrobiony może podnieść UX. To URL – czyli unikalny adres pozwalający odwiedzić dowolną stronę WWW. Choć wielokrotnie przymierzano się już do jego eliminacji, wciąż ma się świetnie i prawdopodobnie jeszcze przez lata będzie się dobrze trzymał. Dlatego warto się z nim zaprzyjaźnić i sprawić, żeby wyglądał ładnie. W końcu osoba użytkownicza zdecydowanie łatwiej zapamięta https://example.com/contact niż https://example.com/?page=ftg4Q.

Developer eXperience

Warto pochylić się nad jeszcze jedną kwestią. Dotąd mówiliśmy o doświadczeniu osoby użytkowniczej. Ale nie można zapomnieć, że istnieje druga strona. Dlatego istnieje też pojęcie Developer eXperience (DX) – doświadczenie osoby developerskiej. Dotyczy ona sfery developmentu i tego, jak przyjemne i intuicyjne jest używanie narzędzi pozwalających na stworzenie strony WWW. Nie da się ukryć, że im te doświadczenia są lepsze, tym większa szansa, że produkt końcowy też będzie lepszy. W końcu nie ma nic gorszego, niż nieustanna walka z używanymi narzędziami.

Problem pojawia się wtedy, gdy DX zaczyna przesłaniać UX. Ten argument jest w centrum obecnej krytyki sporych frameworków JS-owych, z Reactem na czele. Frameworki te bowiem często wymagają od przeglądarki osoby użytkowniczej, żeby ta ściągnęła sporą ilość JS-a, która jest potrzebna frameworkowi do działania. A większa ilość JS-a to większe zużycie transferu. Większa ilość JS-a sugeruje też, że bebechy frameworka są dość złożone, co może przekładać się na większe zużycie energii, tym samym – krótszą pracę na baterii albo spowolnienie pracy urządzenia. Obecne frameworki JS-owe ułatwiają osobom developerskim pracę na przeróżne sposoby, często uciekając się do magii, które ostatecznie generuje działający kod dla przeglądarki. Ale niekoniecznie osoba developerska ma pełną kontrolę nad tym, co i w jakiej ilości trafia do przeglądarki. Warstwy abstrakcji frameworka często bowiem jedynie pomagają w łatwiejszym developmencie, nie przekładając się zbytnio na doświadczenie osoby użytkowniczej, czy wręcz je obniżając.

Dlatego być może nadeszła pora, żeby nieco zredefiniować DX. Żeby przesunąć focus z samego procesu developmentu na jego wynik. Dobre DX to takie, które dostarcza narzędzia pomagające dowieźć produkt, który zapewnia jak najlepszy UX i jest inkluzywny. A jeśli do tego takie narzędzia będą przyjemne w użyciu dla osoby developerskiej, to w końcu zaczniemy żyć w świecie, w którym wszyscy są szczęśliwi.

Źródła

Dodatkowe materiały