Dobre praktyki przy przy projektowaniu UI oraz UX cz. 2 – Koszyk

baner3

Tydzień temu prezentowaliśmy dobre praktyki przy projektowaniu UI oraz UX w odniesieniu do karty produktu sklepu online. Dziś zapraszamy do przeczytania kolejnej części, która dotyczy koszyka.

Koszyk

1. Zmiana wariantu w koszyku

7

Koszyk to ostatni etap dzielący klienta od zakupu. Należy zatem zwrócić szczególną uwagę by nie porzucił on koszyka. Jednym z powodów wyjścia z koszyka jest potrzeba zmiany wariantu produktu. Odnosi się to do sytuacji, gdy klient wybrał np. zły rozmiar lub kolor i zorientował się już w momencie gdy kliknął w koszyk, by dokonać zakupu. Kliknięcie w “zmień wariant” może prowadzić na inną stronę, skąd potem łatwiej porzuci koszyk. Warto zatem umieścić opcję zmiany wariantu już na poziomie koszyka, aby klient nie opuszczał go ani na chwilę.

2. Adekwatne buttony

8

Może się to wydać banalne, jednak źle opisane przyciski mogą spowodować, że klient źle odczyta komunikat i zrezygnuje z przejścia na kolejną stronę w procesie zakupu. Kolejne kroki w koszyku powinny być zatem adekwatnie nazwane, by nie wprowadzać użytkownika w błąd oraz nie sprawić, że zrezygnuje on z zakupu jedynie dlatego, że poczuje się niepewnie.

3. Eliminacja rozpraszających elementów

9

Warto pamiętać również, że umieszczanie przycisków w koszyku, które nie są związane z procesem zakupowym, może okazać się zgubne. W momencie gdy klient przejdzie na inną stronę i zainteresuje się kolejnymi rzeczami, może stwierdzić, że zakupu dokona innym razem lub całkowicie z niego zrezygnuje. Na etapie koszyka, nawet standardowe menu sklepu z kategoriami może sprawić, że zostanie on porzucony. Należy więc zastanowić się jaką informację należy umieścić, by pomóc klientowi podjąć decyzję. Istnieje wiele możliwości, jak na przykład wysyłka tego samego dnia lub też darmowa dostawa.

4. Metody dostawy

10

Drugi krok w koszyku to zazwyczaj wybranie metody dostawy i wpisanie adresu, na który ma zostać doręczona przesyłka. Jeśli firma oferuje usługę click & collect, czyli zamówienie online i odbiór w sklepie stacjonarnym marki, warto umieścić w tym kroku mapy salonów, by ułatwić klientowi wybór. Podobną sytuacją jest usługa paczkomatów, w tym wypadku również dużo łatwiej zdecydować się na lokalizację, która jest najbliższa, a mapka ułatwia tego zobrazowanie.

5. Szybkie płatności

11

Ostatnim etapem jest dokonanie płatności. Jeśli strona nie jest przejrzysta, może to zniechęcić klienta do kolejnych zakupów. Bardzo duży wpływ na pozytywne user experience ma wygodna metoda płatności. Obecnie, coraz większą popularność zdobywają płatności online, które przede wszystkim są szybkie oraz mają prosty proces. Opcja zwykłych przelewów nie pozostawia pozytywnego wrażenia, szczególnie gdy informacje odnośnie tego sposobu płatności nie są podane w jasny i czytelny sposób. Szybki czas realizacji i przejrzyste zasady sprawiają, że klient jest zadowolony z obsługi i chętniej wróci do sklepu i może poleci go innym osobom.

Jasna komunikacja na stronie marki to bardzo ważna sprawa. Buttony powinny być adekwatnie nazwane, metody płatności i dostawy przedstawione transparentnie i zrozumiale, a samo poruszanie się po stronie powinno odbywać się intuicyjnie. Klient nie chce czuć się zagubiony na sklepie. Oczekuje, że szybko znajdzie odpowiednie informacje, nie tylko o produkcie, ale również o samej firmie czy metodach dostawy oraz, że będą one dla niego jasne i czytelne.

Za tydzień przedstawimy kolejną i ostatnią już część wybranych przez nas dobrych praktyk przy projektowaniu UI oraz UX, odnoszącą się do uniwersalnych funkcjonalności sklepu online.

Dobre praktyki UI i UX cz. 1

Zobacz również artykuły o podobnej tematyce

B2E, czyli skuteczne wsparcie organizacji pracy
B2E banner

Jak sprawić, by organizacja efektywnie funkcjonowała na współczesnym rynku? Każdy kto prowadzi firmę wie, że kwestia ta potrafi spędzać sen...

Aplikacja mobilna brakującym ogniwem omnichannel?
aplikacja mobilna

W 2018 r. strategia omnichannel wydaje się standardem. Wszystkie liczące się marki posiadające sieć sklepów stacjonarnych połączyły w większym lub...

Czy człowiek może być kolorem? Kapitał ludzki, jako największa wartość w organizacji
ludzie-1

Chcąc prowadzić innowacyjną i ponadczasową firmę należy bacznie obserwować indywidualne predyspozycje pracowników. Nie każdy z nich nadaje się do pracy...

Zobacz więcej wpisów
  • http://oferownik.pl Robert Marketingowiec

    Nie da się być mocnym we wszystkich kanałach komunikacji, trzeba sobie wypracować te które najbardziej się wybijają i się ich trzymać.

  • Marcin

    „Dawno temu skupialiśmy się na ważnych rzeczach, czyli rozwiązywaniu problemów i logice biznesowej. Dzisiaj jesteśmy prawie całkowicie skoncentrowani na abstrakcji i generalizacji.” – i to wszystko wina frameworków? Czy to wina cegieł i zaprawy że murarze krzywo wybudowali mur, czy jednak problemem było nieprofesjonalne podejście fachowców, którzy ubzdryngoleni przyszli do pracy? Nie możemy zrzucać winy na narzędzia, za to że źle tworzymy aplikacje. Powinniśmy raczej starać się dostrzec fakt, że problem leży w nas samych i spróbować go zrozumieć… oraz coś z nim zrobić. I na pewno nie jest metodą na ów problem podejście, że „powinniśmy używać PHP, a nie architektury do budowania aplikacji” – taki tok rozumowania jest idealnym dowodem na to jak wiele osób nie rozumie czym jest architektura. Architektura to nie framework! Posłużę się kolejnym odwołaniem do budownictwa: czy patrząc na kościół pierwsze co widzimy to to, z czego jest on zbudowany czy raczej jakie jest jego przeznaczenie. Albo: czy widząc bramę pierwszą naszą myślą jest „użyli cegieł z Castoramy i wkrętarki boscha” czy raczej „to jest brama – służy do tego by gdzieś wejść lub skądś wyjść”?
    To prawda – we współczesnym programowaniu zapominamy o logice biznesowej, ale nie jest to wina architektury, tylko raczej braku dyscypliny w nas samych – nie interesuje nas to, nas jara głównie fakt że piszemy np. w kotlinie bo to jest teraz modne. „Zrobię to na symfony, zapytania puszczę doctrinem a obiekty będę serializować jms’em” – to nie jest opis architektury, to lista zakupów – jakich narzędzi potrzebuję by zrealizować cel. Szkoda tylko, że przez to cel ląduje na drugim (albo i nawet dziesiątym) miejscu – a celem jest np. zbudowanie aplikacji do przechowywania dokumentów. Ale to nie decyzja twórców bibliotek/frameworków, że cel staje się dla nas mało istotny. To nie Fabien Potencier każe nam całą logikę wrzucać do akcji w kontrolerze, to nie Jonathan Wage podpowiada nam, by nasze biznesowe obiekty bezpośrednio wywoływały doctrine’a! To my, my programiści sami doprowadzamy do tego, że nasze aplikacje przypominają niestrawione resztki pokarmu które codziennie zostawiamy w porcelanowym ekspresie. I póki nie nauczymy się odseparowywać logiki biznesowej od narzędzi to dalej będziemy tworzyć legacy code.
    Co do argumentu, że niektóre z zależności mogą zostać po kilku latach porzucone i nie będą dalej rozwijane… serio? I proponujesz phpti jako alternatywę do twiga albo smarty? Wszystko może zostać po kilku latach porzucone, to do obowiązków programisty należy m.in. nie pozwolić na to, by moduły/komponenty nie były sprzężone z innymi elementami czy zewnętrznymi bibliotekami.
    A co do bogactwa wiedzy i tego co się dzieje pod maską – ogólnie nie powinno się używać narzędzi, których się nie rozumie: jak działają, dlaczego tak działają itp. By potem nie było sytuacji w stylu senior piszący od 5 lat w laravelu nie potrafi odpowiedzieć na rozmowie kwalifikacyjnej na pytanie „Co robi funkcja die()?”…

    TL;DR: nie zgadzam się 😉