Ilekroć mam do czynienia z briefami dotyczącymi systemów sprzedażowych, zadaję sobie niezliczoną ilość pytań “Po co?”, “Dlaczego?” itd. Oczywiście wiele kwestii wymaga zwyczajnego doprecyzowania i z czasem nabiera logiki, ale niektóre punkty owych wymarzonych list funkcjonalności, choć zrozumiałe, i tak budzą duże wątpliwości (natury UCD). Podzielę się kilkoma przykładami z ogródka e-commerce.

• eksport zawartości koszyka - nie chodzi bynajmniej o eksport dokonywany po stronie administratora, ale o możliwość udostępnioną użytkownikowi, chyba tylko po to, żeby zaciemniała niezwykle istotny widok koszyka. Nie wierzę w to, że ktoś rezygnuje z zakupu (przecież z jakiegoś powodu), ale chce pozostawić na swoim komputerze arkusz z nazwami produktów. To trochę tak, jakby zrezygnować z zakupów będąc przy kasie w supermarkecie (np. zorientowałem się, że sok jest przeterminowany), ale poprosić o zapisanie na kartce, co przywieźliśmy w wózku. Rozumiem, że chodzi o to, żeby niezalogowany użytkownik mógł “szybko” odtworzyć koszyk przy powtórnej wizycie, ale wydaje mi się, że mimo wszystko łatwiejsze jest (a przynajmniej powinno) odnalezienie czegoś na nowo, niż download, a potem upload pliku za pomocą kolejnego formularza.

• historia zmian danych klienta - znów ta sama sytuacja: informacja wcale nie dla administratora (żeby np. miał wgląd w to, jaki był dawny adres klienta), tylko dla samego klienta. Czyli ktoś może dowiedzieć się na kartach swojego profilu, kiedy zmienił nazwisko z panieńskiego na nowe itd… Jeśli do konta ma dostęp wielu użytkowników, to ma to uzasadnienie, ale jeśli tylko jeden? Dla ochrony jego konta sugerowałbym raczej aktywację zmian danych, które są kluczowe, z użyciem wiadomości email.

• eksporty do formatów XML, CSV… - oprócz zawartości koszyka spotkałem się z życzeniami eksportu zamówień, list produktów, szczegółów produktów itd. W tym wypadku chciałbym zwrócić uwagę raczej na formaty tych danych. Nie mam nic przeciwko wydrukowi faktury czy szczegółowych parametrów produktu poprzez format PDF, ale trudno mi sobie wyobrazić przydatność niesformatowanych nijak plików XML czy CSV (ten nie zawsze otworzy się w Excelu). Oczywista sprawa. Wyjątkiem są platformy przeznaczone dla wąsko określonych klientów, potrzebujących danych w bardzo konkretnej formie, aby mogli je wykorzystać w swoich systemach wewnętrznych.

• nieprzemyślane programy lojalnościowe - wiele zależy tu od modelu biznesowego sprzedawcy. Jeśli sprzedajemy dużo i często to program lojalnościowy może być dobrym narzędziem składaniającym do powtórnych zamówień w sklepie. Przykłady z życia codziennego: żywność, paliwa itp., tj. produkty, które faktycznie kupujemy cyklicznie. Natomiast trudno o skuteczny program lojalnościowy w przypadku asortymentu takiego jak komputery, niedrobny sprzęt RTV / AGD, czy meble. “Kup 10 łóżek, a 11 otrzymasz za darmo!” - taki marketing raczej nic nie da, a może zaszkodzić (choć to oczywiście skrajny i nierzeczywisty przykład).

• historia loginów klienta - tym razem coś ze strony administracyjnej. W ogóle nie widzę powodu, żeby administrator przeglądał loginy użytkowników (zwłaszcza jeśli nie są to jednocześnie adresy email), a co dopiero historię: sprawdzanie, jak brzmiał login klienta wcześniej, a jaki jest obecnie (o ile w ogóle ta informacja cechuje się jakąkolwiek zmiennością). No, ale przyjmijmy, że panel to całkiem inna historia, chociażby dlatego, że jest tworzony dla konkretnych osób z konkretnymi zachciankami i z konkretnym budżetem

Spostrzeżenia te nie są odkrywcze dla osób biorących udział w procesie tworzenia serwisów internetowych i mających mniejsze lub większe pojęcie o użyteczności. Dowodzą natomiast, że nastawienie na użytkownika nie jest jeszcze tak powszechne, jak byśmy sobie tego życzyli, zwłaszcza wśród małych i średnich zleceniodawców.