Ładniejszy interfejs nie naprawi błędnej logiki produktu

Testowanie użyteczności to jedna z najważniejszych metod badawczych w obszarze user experience. Pozwala wykryć realne problemy z użytecznością produktu, zanim staną się kosztowne. Ale co zrobić, gdy wyniki testów pokazują symptomy, a nie przyczyny? Właśnie z taką sytuacją mieliśmy do czynienia podczas pracy nad konfiguratorem pierścionka zaręczynowego.

„Nie mam zielonego pojęcia, co oznaczają te skróty”, „Nic z tego nie rozumiem” – to tylko niektóre ze zdań, które padły podczas testów użyteczności konfiguratora pierścionka zaręczynowego.

Na pierwszy rzut oka sprawa wydawała się prosta: klienci nie rozumieli parametrów kamieni, nie wiedzieli, za co dopłacają i gubili się w procesie personalizacji. Konfigurator oferował użytkownikowi wiele możliwości, ale sposób ich prezentacji zwiększał obciążenie poznawcze.

Ale im dłużej analizowałam wyniki, tym wyraźniej widziałam, że pod spodem kryje się coś więcej. Testy pokazały nam, co nie działa. Nie odpowiedziały jednak na pytanie, dlaczego konfigurator działa właśnie tak.

I tu zaczyna się właściwa historia tego wpisu – bez odpowiedzi na pytanie “dlaczego” nie mogliśmy go sensownie przeprojektować.

Kiedy testy użyteczności to za mało?

Projekt, w ramach którego prowadziłam to badanie, to pełny redesign strony internetowej. Zaczęliśmy od audytu CRO, a testy użyteczności były częścią dużo szerszych badań user experience obejmujących całą ścieżkę zakupową klienta – od discovery, przez kartę produktu i konfigurator, aż po koszyk i checkout. Badaliśmy interakcje użytkowników zarówno na desktop, jak i na mobile.

W trakcie pracy natrafiłam na krytyczny problem dla konwersji – konfigurator pierścionka zaręczynowego nie działał. I to na kilku poziomach jednocześnie.

Jeden z respondentów, próbując zrozumieć parametry kamieni bocznych, powiedział:

„Co to są te numery, nie mam zielonego pojęcia, o co chodzi – tu też zmienia się centralny kamień, mimo że to inna kategoria… nie wiem, co to za skróty.”

Inny, patrząc na dwa identycznie opisane warianty jakości z zupełnie różną ceną, zapytał:

„No i za co ja mam dopłacać prawie dwa razy tyle, skoro to jest ten sam szlif, ta sama przejrzystość […] Bo ja nie wiem, na przykład.”

Nie chodziło więc o nazewnictwo. Z jednej strony mieliśmy żargon jubilerski, którego klienci nie rozumieli. A z drugiej – funkcjonalność konfiguratora, która pozwalała im wejść w sytuacje, które z punktu widzenia oferty nie powinny być możliwe.

Klient mógł wybrać coś, czego w rzeczywistości nie dało się zamówić. Przy personalizacji jego wcześniejsze wybory mogły zostać automatycznie zmienione. W innym miejscu konfigurator pokazywał parametr, który w danym wariancie w ogóle nie powinien być dostępny.

Te błędy prowadziły do wielu porzuceń już na poziomie karty produktu. Co gorsze mogły spowodować, że klient nieświadomie zamówił inny wariant pierścionka niż zamierzał.

Wiedziałam już, co boli użytkownika, ale nadal nie wiedziałam, dlaczego system działa w ten sposób.

Problemy z użytecznością sięgały głębiej niż interfejs

Żeby naprawić konfigurator, musieliśmy najpierw zrozumieć logikę produktu, która za nim stała.

I tutaj pojawił się problem. Okazało się, że nie do końca rozumiał ją nawet zespół produktowy. Każdy miał pewne wyobrażenie o tym, które parametry są od siebie zależne, co jest wyborem klienta, a co wynika automatycznie z wcześniejszych decyzji. Ale te zasady nie były zebrane w jednym miejscu.

To był sygnał, że zanim zaczniemy projektować, potrzebny jest wspólny model tego, jak konfigurator powinien działać. Bez niego trudno zaprojektować nowy interfejs.

Dlatego jako badaczka podjęłam się tego wyzwania. Możemy przecież poprawić nazwy, zmienić kolejność pól i uprościć ekran, ale jeśli nie rozumiemy reguł, według których działa produkt, bardzo łatwo przenieść stare problemy do nowego designu.

Analiza zależności – zamiast zgadywać, zbudowaliśmy model

Aby rozwiązać zagadkę i odpowiedzieć na pytanie „dlaczego„, zaczęłam od warsztatów z zespołem klienta i rozmowy z osobą, która na co dzień zarządzała tą częścią katalogu produktów.

Najpierw wspólnie zmapowaliśmy scenariusze użycia i to, co wiedzieliśmy. Potem zaczęliśmy zadawać pytania np. co jest rzeczywistym wyborem klienta, a co jest tylko informacją.

Po kilku godzinach pracy powstał diagram zależności – wizualna mapa logiki konfiguratora. Pokazywał dostępne opcje i zależności pomiędzy nimi. To był nasz wspólny model produktu.

Co ważne, nie był to dokument, który stworzyliśmy raz i odłożyliśmy na bok.

W miarę zadawania kolejnych pytań dopisywaliśmy nowe zależności. Czasami bardzo szczegółowe – na przykład to, że konkretny kamień, jak czarny diament, jest dostępny wyłącznie w jednym szlifie, podczas gdy biały diament laboratoryjny może występować we wszystkich.

Warsztaty dały nam wstępny obraz sytuacji, ale pojawiały się też sprzeczne intuicje, dlatego w przypadku niejasności wracaliśmy do osoby, która na co dzień zarządzała katalogiem produktów i znała rzeczywiste zasady oferty.

5 ustaleń z wyników testów, których nie było widać na ekranie

Kiedy zaczęliśmy rozpisywać logikę konfiguratora, okazało się, że część problemów wykrytych podczas przebiegu testów miała bardzo konkretne źródło.

• Jakość nie zawsze była wyborem
  Jakość kamienia centralnego – Standard albo Premium – jest rzeczywistym wyborem klienta, ale tylko w przypadku diamentu naturalnego w konkretnym szlifie. Dla diamentu laboratoryjnego i pozostałych kamieni to pole w ogóle nie powinno się pojawiać. Na produkcyjnej stronie tej zasady jednak nie było. Gdy klient próbował zmienić jakość przy kamieniach bocznych, system zmieniał mu kamień centralny na inny. To tłumaczyło jeden z wcześniejszych problemów zauważonych podczas testów: „jedyną różnicą jest kolor kamienia głównego, co dodatkowo nie jest logiczne, bo kamień główny był dobierany wcześniej”.
  
  Wniosek: jeśli dana opcja nie jest możliwa w określonym wariancie, nie powinna wyglądać jak aktywny wybór.
  
• „Nie można wybrać” nie znaczy „nie trzeba pokazywać”
  Podczas mapowania logiki zauważyliśmy jeszcze jedną ważną rzecz. Łatwo wpaść w pułapkę chowania wszystkiego, czego klient nie może wybrać. Ale są dwie sytuacje: klient nie wybiera tej wartości → ukryj kontrolkę, klient powinen wiedzieć jaka jest wartość → warto pokazać tę informację, nawet jak się jej samodzielnie nie zmienia.
  
  Ta różnica miała znaczenie przy parametrach jakości kamienia. W konfiguratorze mogliśmy mieć ten sam kod jakości, np. SI2/H/GD, przy dwóch różnych cenach. Jeśli klient nie widzi informacji, która wyjaśnia tę różnicę, naturalnie pojawia się pytanie: “Za co właściwie mam dopłacać?”
  
• Parametr może być informacją, nawet jeśli nie jest wyborem
  To samo dotyczyło parametrów takich jak czystość, barwa czy masa kamienia bocznego. Nie wszystkie z nich były wybieralne, ale to nie oznaczało, że nie były istotne.
  
  Klient nadal powinien widzieć, jaki kamień faktycznie otrzymuje. Problem polegał na tym, że informacje były przedstawione językiem branżowym, którego użytkownicy nie rozumieli.
  
  Stąd wcześniejszy cytat „Nie mam zielonego pojęcia, o co chodzi” – same dane były na stronie, tylko przedstawione w formie, której nikt nie rozumiał.
  
• Nie każda zależność musi być wyborem klienta
  Kamienie w koronie i na obrączce nigdy nie są osobnym wyborem. Ich rodzaj wynika z kamienia centralnego:
  • diament naturalny centralny = wszystko naturalnelaboratoryjny = wszystko laboratoryjne
  
  Podobnie ich masa rośnie proporcjonalnie do masy kamienia centralnego, mimo że klient nigdy jej sam nie ustawia. Mimo to produkcyjny konfigurator pozwalał kliknąć zmianę rodzaju kamienia w koronie. Ponieważ w systemie nie istniała żadna „mieszana” oferta, kliknięcie albo nic nie robiło, albo przenosiło klienta na zupełnie inny produkt.
  
  Jeśli wartość wynika automatycznie z wcześniejszego wyboru, nie powinna być prezentowana jako niezależna decyzja.
  
• Nie wszystkie kamienie mają te same dostępne masy
  Kolejna zależność dotyczyła masy kamienia. Rodzaj kamienia trzeba było wybrać wcześniej, zanim system w ogóle pokaże sensowne opcje masy.
  
  Na starej stronie ta zależność nie była poprawnie odwzorowana – przy zmianie z brylantu 0,5 ct na granat automatycznie otwierało się okno wyboru masy, ale pojawiał się komunikat „Obecnie 0,5 ct”. Problem? Granat w masie 0,5 ct w ogóle nie występował w ofercie. Dostępny był dopiero w 1,4 ct.
  
  To pokazuje, dlaczego samo sprawdzenie, czy poszczególne pola działają, nie wystarcza. Trzeba jeszcze sprawdzić, czy działają zgodnie z regułami produktu.

Błędy i pułapki przy redesignie oraz co warto zapamiętać

Z tego projektu jako UX Resercherka wyniosłam kilka lekcji, które stosuję teraz przy podobnych wyzwaniach.

1. Nie ufaj bezkrytycznie temu, co robi obecna strona internetowa
   W trakcie pracy natrafiliśmy na sytuacje, w których sam produkcyjny konfigurator łamał własne reguły biznesowe np. dawał klientowi możliwość kliknięcia w opcję, która w praktyce przełączała go na zupełnie inny produkt. Jeśli budujesz diagram na podstawie tego, co „widać na stronie”, powielisz te błędy.
   
2. Nie wstydź się, że nie wiesz i nie rozumiesz
   Bycie badaczem nie polega na tym, że znasz wszystkie odpowiedzi przed rozpoczęciem projektu. W tym przypadku moja rola nie polegała na tym, żeby samodzielnie znać wszystkie zasady dotyczące kamieni i konfiguracji pierścionków. Polegała na tym, żeby zadać właściwe pytania, znaleźć źródło odpowiedzi i uporządkować wiedzę tak, żeby cały zespół mógł się nią posługiwać.
   
3. Wizualizuj skomplikowaną logikę
   Kiedy liczba zależności zaczyna przekraczać to, co można utrzymać w głowie, rozmowy przestają wystarczać. Prosty diagram pozwala zobaczyć, czy wszyscy jesteśmy po tej samej stronie. I co równie ważne – pozwala całemu zespołowi pracować na tym samym modelu.
   
4. Ustal, gdzie znajduje się źródło prawdy
   Warsztaty zespołowe świetnie sprawdzają się do zmapowania obszaru i wyłapania niepewności. Ale kiedy pojawiają się sprzeczne informacje, trzeba wiedzieć, do kogo wrócić. W tym projekcie ostateczne odpowiedzi dawała osoba najbliżej katalogu i rzeczywistych zasad oferty. Nie wszystkie źródła informacji są sobie równe.

Nie zaczynaj od poprawiania ekranów

Wracając do początku tego wpisu: testy użyteczności dały nam „co”. Pokazały, że użytkownicy nie rozumieją parametrów, gubią się w mechanice i nie wiedzą, za co płacą.

Ale dopiero pytanie „dlaczego?” pozwoliło nam ruszyć z projektem dalej. Nie potrzebowaliśmy kolejnej rundy testów. Potrzebowaliśmy zrozumieć system, który użytkownik próbował obsłużyć.

Jeśli projektujesz produkty cyfrowe z ukrytą logiką biznesową np. konfigurator sprzętu, mebli na wymiar, biżuterii albo dowolnego produktu, w którym jeden wybór uruchamia serię kolejnych zależności, zacznij właśnie od tego.

Zanim poprawisz ekran, zrozum, jakie zasady stoją za tym, co widzi użytkownik.

Bo czasem problem nie leży w tym, że użytkownik nie potrafi korzystać z interfejsu.

Problem polega na tym, że interfejs nie potrafi poprawnie opowiedzieć użytkownikowi, jak działa produkt.