Uwzględniłam cenę z dostawą przy wyborze książki.

Najniższa cena książki to dopiero początek rachunku

W przykładzie poniżej nowa książka kosztuje 39 zł. Z dostawą to już 50,99 zł, a przewidywany termin doręczenia sięga poza piątek.

Inny sprzedawca liczy sobie za książkę więcej. Za to podaje wcześniejszy termin. Obie oferty wymyśliłam wokół prawdziwego tytułu, żeby dało się prześledzić tę decyzję.

Koncepcję zaprojektowałam dla osoby, która wie już, jakiego wydania szuka, i potrzebuje książki na konkretny dzień, a projekt pokazuje to wydanie przez cały czas, gdy porównuje ona stan egzemplarza, sprzedawcę i kwotę do zapłaty przy wybranym sposobie dostawy. Porównanie ma też prawo skończyć się bez wyboru, jeśli żadna oferta nie spełnia wymagań.

Punktem wyjścia był krótki przegląd Empiku bez logowania, na komputerze i w widoku telefonu o szerokości 390 pikseli. Sprawdziłam:

• wyszukiwanie,
• jedną książkę o historii sztuki i oferty jej sprzedawców,
• informacje o dostawie,
• koszyk.

Nie prowadziłam wywiadów z klientami, nie miałam wglądu w analitykę wewnętrzną i nie składałam zamówień. Studium pokazuje więc działający projekt i plan oceny, bez zmierzonego wyniku konwersji.

Skupiłam się na porównaniu ofert

Pierwotny zakres sięgał od wyszukiwania książek po finalizację zakupu. Znalezienie tytułu i opłacenie zamówienia sprawiają trudność z innych powodów, a gdybym zmieniła oba etapy naraz, nie wiedziałabym, która zmiana pomogła. Działający projekt dotyczy więc jednej decyzji. Chodzi o to, u którego sprzedawcy kupić ten sam tytuł w jednym egzemplarzu.

Oferta składa się tu z czterech elementów: poszukiwanego wydania, stanu egzemplarza, sprzedawcy i wyceny wybranego sposobu dostawy. Cena to kwota za książkę plus koszt tej dostawy. W danych przykładowych nie ma programu członkowskiego, kuponu z aplikacji ani promocji związanej z płatnością, więc wynik każdego przykładu da się jednoznacznie policzyć, choć wersja produkcyjna potrzebowałaby prawdziwych zasad każdej korzyści i grupowania dostaw.

Tytuł, nazwisko Susie Hodge i twarda oprawa pochodzą ze sprawdzonej strony produktu, natomiast nazwy sprzedawców, ceny, opłaty i przedziały dat w prototypie wymyśliłam. W opisie odsyłam do źródła i nie wymyślam numeru ISBN. Prawdziwe łączenie ofert wymagałoby zweryfikowanego identyfikatora i uzgodnienia danych katalogowych, zanim egzemplarz kolejnego sprzedawcy trafiłby do tego samego porównania.

Przy dostawie kurierem do piątku warunki spełniają dwa nowe egzemplarze. Book Table ma niższą cenę książki. Z dostawą wychodzi jednak drożej: 62,99 zł wobec 56,99 zł w Paper Window. Book Table podaje też wcześniejszy przewidywany termin. Lista pokazuje rachunek i różnicę terminów, dlatego samo określenie „najtańsza” nie opisuje wszystkich preferencji kupującego.

Używany egzemplarz liczy się dopiero wtedy, gdy kupujący dopuści taki stan. Wymaganie zmienia się jawnie, a wydanie pozostaje to samo.

Open Index ma atrakcyjną cenę książki i niepełną wycenę dostawy, więc nie trafia do rankingu ofert spełniających warunki. Przy sprzedawcy zostaje informacja o brakach i wskazany następny krok. Brakujący koszt nigdy nie zamienia się w bezpłatną dostawę.

Rozbudowane porównanie musi uzasadniać swój koszt

Lista porównawcza pokazuje różnice. Wymaga też więcej czytania. Komuś, kto kupuje u znanego sobie sprzedawcy, może wystarczyć czytelniejsze podsumowanie na stronie produktu.

Tę mniejszą zmianę zachowałam jako poważną alternatywę i oceniałam ją według tych samych warunków zakupu, bo sam wygląd listy byłby słabym powodem, by wybrać kosztowniejszą integrację.

Po zmianie wyboru wyjaśnienie musi być aktualne

Wystarczy wybrać odbiór osobisty, a zmienia się opłata, opis terminu i lista dostępnych sprzedawców. W tym projekcie dostawa jest częścią samej oferty.

Jeśli wybrana oferta nadal spełnia warunki, pozostaje zaznaczona. Jeśli przestaje pasować, podsumowanie prosi o nowy wybór, a przy sprzedawcy pojawia się powód niezgodności.

Na telefonie każdy wiersz staje się pełnym, pionowym opisem oferty. Stoi za tym kilka decyzji implementacyjnych:

• Cena ma własne miejsce przy sprzedawcy, a termin i powód wykluczenia pojawiają się dalej, w kolejności czytania.
• Standardowe pola wyboru i przyciski pozwalają obsłużyć interfejs klawiaturą.
• Zmiany wyników są ogłaszane bez przerywania użytkownikowi.
• Żadna nakładka ani przypięty przycisk zakupu nie zasłania porównania.

Wszystkie cztery decyzje wymagają jeszcze sprawdzenia i nie są deklaracją dostępności dla każdego.

Ocena wygenerowana przez AI może podważyć reguły

Poprosiłam model AI, żeby ocenił reguły z czterech celowo różnych perspektyw:

• osoby z nieprzekraczalnym terminem,
• osoby z ograniczonym budżetem, gotowej odebrać używany egzemplarz,
• kogoś, kto nie zna platform z wieloma sprzedawcami,
• osoby, która zmienia sposób dostawy za pomocą klawiatury.

Te perspektywy są wymyślone; nie wynikają z badań person. Model dostał opis działania i poprawne odpowiedzi dla danych przykładowych. Nie obserwował ludzi korzystających z interfejsu.

Zastrzeżenia dotyczyły opisu terminu, niepełnych wycen i utraty kontekstu, gdy wybór przestaje spełniać warunki. Po tej ocenie zmieniłam prototyp:

• ostrożna reguła terminu jest teraz przy swoim polu,
• niepełne wyceny mają osobne oznaczenie,
• po wyczyszczeniu wyboru poprzedni sprzedawca pozostaje oznaczony,
• ograniczenia odbioru osobistego i ustawienia przywracane przez reset są opisane wprost.

Zmiany odpowiadają na ocenę opisanych mechanizmów. Zrozumienie i zaufanie nadal trzeba sprawdzić, obserwując ludzi przy zadaniach.

Osobna ocena AI dotyczyła rzeczywistego zrzutu ekranu z komputera. Wskazała konflikt wizualny: niskie kwoty wykluczonych ofert były tak samo wyraziste jak kwoty ofert spełniających warunki. Zmniejszyłam ich wyróżnienie, przy każdej takiej kwocie dodałam krótki powód wykluczenia, a niedostępnym opcjom nadałam osobną etykietę. Ograniczenie widać teraz tuż obok kwoty, która może przyciągnąć uwagę, a to, czy kupujący je zauważają, musi sprawdzić badanie z ludźmi.

Najpierw sprawdziłabym poprawność decyzji

Zanim ktokolwiek zacznie liczyć zamówienia, chciałabym wiedzieć, czy kupujący wybierają poprawnie. Plan zaczyna się od obecnej wersji serwisu.

Najpierw sześć sesji z obecnym interfejsem

Następną rundę badań rozpoczęłabym od sześciu moderowanych sesji oceniających obecną wersję. Zaprosiłabym polskojęzyczne osoby, które niedawno kupowały książki przez internet, z różną częstotliwością zakupów i różną swobodą w korzystaniu z narzędzi cyfrowych. Zadania dotyczyłyby określonego wydania, ceny z dostawą i wyboru na wskazany termin, a ich treść sprawdziłby wcześniej pilotaż. Nikt nie miałby płacić. Jeśli zadanie zbliżałoby się do transakcji, zastąpiłby je symulowany koszyk.

Te sesje powinny pokazać, czy trudność z porównaniem się powtarza. Jeśli obecny interfejs już pozwala poprawnie wybierać, ograniczyłabym projekt. Jeśli błędy wynikają z niejednoznacznego katalogu, zaczęłabym od rozpoznawania wydania, bo czytelniejsza lista nie naprawi niewiarygodnego katalogu ani brakującej wyceny dostawy.

Potem porównanie z projektem

Dopiero po ustaleniu tego punktu odniesienia przeprowadziłabym wstępne porównanie z 12 nowymi uczestnikami. Wierne odtworzenie obecnego interfejsu i projekt dostałyby dopasowane scenariusze o podobnej złożoności ofert sprzedawców i dostawy. Cztery zrównoważone sekwencje zmieniałyby to, którą wersję i który scenariusz każda osoba zobaczy najpierw. To ogranicza część wpływu kolejności. Uczenie się pozostaje ograniczeniem badania.

Co uznaję za poprawną decyzję

Klucz odpowiedzi uznawałby decyzję za poprawną, gdy obejmuje właściwe wydanie i stan, dostawę spełniającą warunki oraz poprawną sumę. Poprawne byłoby też trafne rozpoznanie, że żadna oferta nie pasuje. Udzieloną pomoc i błędy rachunkowe zapisywałabym osobno. Czas liczyłabym od pokazania zadania do ostatecznej odpowiedzi, razem z informacją o ukończeniu, więc szybki błędny wybór nadal byłby niepowodzeniem.

Warunek przejścia dalej

Wstępny warunek zakłada, że co najmniej 10 z 12 uczestników poprawnie wyjaśni możliwą do ustalenia łączną kwotę oraz wybór wydania i stanu, a żadna fałszywa obietnica dotycząca ceny lub terminu dostawy nie zostanie bez wyjaśnienia. Jeśli dwie osoby powtórzą to samo poważne nieporozumienie, projekt wróci do poprawek.

To lokalne kryteria kolejnej decyzji projektowej. Nie pozwoliłyby oszacować preferencji populacji ani ustalić efektu sprzedażowego.

Eksperyment produkcyjny wymaga wiarygodnych wycen i osoby odpowiedzialnej

Prawdziwy test wymagałby udziału Empiku. Potrzebna byłaby też uzgodniona implementacja i miarodajne dane o zamówieniach. Najpierw sprawdziłabym zdarzenia na całej drodze od wejścia na stronę produktu przez porównanie, koszyk i finalizację aż po opłacone zamówienie, łącznie z ponowionymi próbami i zamówieniami od wielu sprzedawców. Wytyczne GOV.UK dotyczące ukończenia transakcji pomagają ustalić, gdzie transakcja się zaczyna, gdzie się kończy i co trafia do mianownika wskaźnika.

Pierwszy eksperyment powinien zmieniać tylko podsumowanie wybranej oferty, bez zmian w wyszukiwaniu, promocjach i finalizacji zakupu. Wytyczne Microsoft dotyczące eksperymentów wspierają falsyfikowalną hipotezę, odpowiednie przypisanie do wariantów i kontrolę jakości danych. W tym projekcie oznaczałoby to trzy zasady:

• warunki udziału byłyby sprawdzane przed wyświetleniem interfejsu,
• odwiedzający zachowywałby przypisany wariant,
• analiza obejmowałaby każdą przypisaną osobę spełniającą warunki, również wtedy, gdy porównanie się nie załadowało.

Jako główną miarę rozważyłabym odsetek odwiedzających spełniających warunki udziału i przypisanych do wariantu, którzy opłacą zamówienie na papierową książkę w ciągu siedmiu dni od pierwszego spełnienia tych warunków. Analiza musiałaby zaczekać, aż te okresy obserwacji się zakończą. Decyzję biznesową ograniczałyby marża na jednego odwiedzającego spełniającego warunki, anulowane zamówienia i kontakty w sprawie dostawy, a także błędy wyceny i szybkość reakcji strony. Rozkład zamówień między sprzedawcami oraz przesunięcia zakupów z aplikacji lub Premium musiałby ocenić właściciel eksperymentu.

Wielkości próby i czasu trwania jeszcze nie ustaliłam. Jedno i drugie zależy od danych wyjściowych i dopuszczalnej straty biznesowej, a tych brakuje. Osoba odpowiedzialna musiałaby je uzgodnić przed uruchomieniem, a potem określić etapy wdrożenia i warunki wycofania zmiany. Czytelne porównanie nadal nie nadawałoby się do publikacji, gdyby wyceny okazały się błędne albo pogorszyły się wskaźniki kontroli ryzyka biznesowego.

Jeśli nie da się zapewnić pełnych wycen, rozwijałabym mniejsze podsumowanie na stronie produktu, a pełną listę odłożyłabym na później.