Recommended
More Related Content
Similar to Jak to zepsułem? Kilka lekcji pokory
Similar to Jak to zepsułem? Kilka lekcji pokory (20)
Jak to zepsułem? Kilka lekcji pokory
- 1. Jak zepsułem produkt kilka lekcji pokory Igor Farafonow
- 3. Lekcja 1 Portal społecznościowy usprawniający budowanie relacji wśród znajomych w GG Źródło: oficjalne materiały prasowe GG Network
- 4. Lekcja 1 W czym jest lepszy? • Adhocowe konferencje one-‐to-‐few, one-‐to-‐one • Walle półprywatne • EmoNkony w streamie • Integracja z komunikatorem • Znacznie więcej – zdjęcia, wydarzenia, gry
- 5. Lekcja 1 Konferencje Źródło: oficjalne materiały prasowe GG Network
- 6. Lekcja 1 zdjęcia… Źródło: oficjalne materiały prasowe GG Network
- 7. Lekcja 1 gry… Źródło: oficjalne materiały prasowe GG Network
- 8. Lekcja 1 Launch udany – na grafikach. Źródło: oficjalne materiały prasowe GG Network
- 9. Lekcja 1 Jaki błąd użyteczności łączy wszystkie te ekrany?
- 10. Lekcja 1 Prezentują produkt dojrzały.
- 11. Lekcja 1 ? • Jak to będzie wyglądać przy niewielkiej ilości treści? • Jak to wyglądać, gdy nowe ciekawe treści będą pojawiać się bardzo rzadko? • Gdzie są ekrany pierwszych wejść? Co ze scenariuszami budowania zaangażowanie? / czy rozwijania krzywej uczenia? • Zresztą – po co użytkownicy mają dodawać treść? W jaki sposób mają się poczuć zachęceni?
- 12. Lekcja 1 Tak wygląda rzeczywistość, gdy nie uwzględnimy mechanizmów budujących zaangażowanie oraz pominiemy kwesNe syndromu pustego sklepu. Źródło: publikacja w serwisie internetowym gadunews.pl
- 13. Lekcja 1 Projekt nie uwzględniał aspektów braku treści i niewielkich ilości treści. Tylko w podstawowej formie określał narzędzia budujące zaangażowanie użytkowników. Nie był przewidziany jeden kluczowy aspekt w cyklu życia produktu – rzeczywistość.
- 14. Lekcja 1 Koncentracja na przeczuciach, doświadczeniach, branżowych wzorcach projektowych.
- 15. Lekcja 1 A wzorce są bez sensu… Przykład:
- 16. Lekcja 1 Właśnie utworzyłeś konto i jesteś tu po raz pierwszy. Źródło: zrzuty facebook.com
- 17. Lekcja 1 Czy Ciebie, jako nowego użytkownika te ekrany zachęcą do korzystania z serwisu?
- 18. Lekcja 1 To, że użytkownicy korzystają z funkcjonalności nie znaczy, że są one dobrze zaprojektowane. Wpływ na ich korzystalność mają znajomość produktu, zaufanie do marki, świadomość, że inni korzystają i inne. Źródło: zrzuty facebook.com
- 19. Lekcja 1 Jedynym wzorcem kierującym przy projektowaniu jest rzeczywistość. Intuicje i inspiracje znajdują uzasadnienie tylko wtedy, gdy w całości uwzględniają skalę i problemy produktu. PS> tych problemów z dziś, nie z jutra
- 21. Lekcja 2 Ile osób spośród Was projektowało kiedyś sklep internetowy?
- 22. Lekcja 2 Czy w tym sklepie były systemy ocen / recenzji produktów? Źródło: fotozakupy.pl
- 23. Lekcja 2 Czy projektowaliście scenariusze wysyłek mailowych do klientów po zakupie z prośbą o oceną produktu lub ocenę jakości dostawy. Źródło: mail zalando.pl
- 24. Lekcja 2 Projektowanie modułów opiera się rysowaniu i składaniu klocków. Rozwiązywanie zagadnień biznesowych to budowanie wielosesyjnych doświadczeń na różnych płaszczyznach. Doświadczeń uwzględniających różne kanały komunikacji – przeglądarka, email, mobile, social, itd.
- 25. Lekcja 2 Ale tu nie chodzi tylko o ilość
- 26. Lekcja 2 Czy ktoś z Was projektował kiedyś system autentykacji? Źródło: gg.pl (zrzut)
- 27. Lekcja 2 Kto w swoim projekcie nie uwzględnił wszystkich usecase’ów i scenariuszy? • Ekran odzyskiwanie hasła • Niepoprawny email w procesie odzyskiwania hasła • Potwierdzenie wysłania instrukcji do utworzenia nowego hasła • Treść emaila odzyskiwania hasła • Ekran tworzenia nowego hasła – po kliknięciu w link z maila • Ekran potwierdzenia założenia nowego emaila • Ekran tworzenia nowego konta • Ekran wykorzystania Facebooka / G+ do założenia konta / zalogowania • Ekran potwierdzający założenie nowego konta • Treść emaila z linkiem aktywującym konto (dla double opt-‐in) • Ekran po potwierdzeniu założenia nowego konta • Ekran, gdy token zawarty w linku z maila już wygasł • Przypomnienie o potwierdzeniu adresu email • Walidacja formularzy dla wszystkich ustandaryzowanych elementów • Spójne GUI w ramach całego projektu – wszystkich formularzy, labeli, pól • Wszystkie dodatkowe komunikaty potwierdzające sukces porażkę w każdym usecase
- 28. Lekcja 2 Każda funkcjonalność powinna być kompletna. Źródło: gg.pl (zrzut)
- 29. Lekcja 2 Nie układamy klocków – projektujemy doświadczenia. Powinny być wielowątkowe, wielokanałowe, ale i kompletne w ramach scenariuszy. Źródło: materiały własne
- 30. Lekcja 3 Zakres
- 31. Lekcja 3 Odtwarzacz muzyki: nieskończenie piękny J
- 32. Lekcja 3 Jak to się miało do rzeczywistości? Nijak. Sztuka dla sztuki.
- 33. Lekcja 3 Rok pracy zanim produkt powstanie?
- 34. Lekcja 3 Produkt musi być realizowalny • Ciągła współpraca z IT • Określenie listy funkcjonalności kluczowych biznesowo • Realna wycena, jeszcze zanim powstaną makiety • Projektowanie ustalonego zakresu – ‘nie projektujemy do szuflady’ • Konsekwencja – nie zmieniamy zakresu funkcjonalnego w międzyczasie • Dyscyplina – nie zmieniamy projektu w nieskończoność
- 35. Lekcja 3 Bo co by było, gdybyśmy przygotowali prosty player MP3? • Mielibyśmy gotowy produkt w ciągu trzech miesięcy • Skonfrontowalibyśmy interfejs użytkownika z Klientami • Poznalibyśmy, w jaki sposób korzystają z naszego systemu i jakie problemy rozwiązują • Wdrażalibyśmy kolejne funkcjonalności mając już działający produkt
- 36. Lekcja 3 Podobna historia w Uxerii Źródło: Uxeria.com
- 37. Lekcja 3 Większy zakres funkcjonalny opóźnia launch i wprowadza dodatkowe ryzyka • wydłuża czas oczekiwania na wydanie • zwiększa ryzyko, że coś się wysypie • zmniejsza elastyczność na zmiany – czasami konieczne po pierwszej weryfikacji z rynkiem • z punktu widzenia produktowego potrafi zmniejszyć przejrzystość głównych cech produktu
- 38. Lekcja 3 Nie robimy sztuki dla sztuki. Nie zawsze warto ratować świat. Projekt powinien po prostu być realizowalny.
- 39. Lekcja 4 Zasady
- 40. Lekcja 4 Każde kolejne pole formularza obniża konwersję o 15 do 30 procent. Prawda? Źródło: fotozakupy.pl (zrzut)
- 41. Lekcja 4 11.500 klientów w 70 krajach 1.900 klientów agencyjnych Źródło: hubspot.com(zrzut)
- 42. Formularz na ebooku hubspot Lekcja 4 Źródło: hubspot.com (zrzut)
- 43. Jeszcze raz… Źródło: hubspot.com (zrzut)
- 44. Lekcja 4 Co więc tak naprawdę decyduje o konwersji formularza? • Zaufanie – użytkownicy nie uzupełnią formularza, gdy nie ufają produktowi i intencjom • Opisanie celowości – użytkownicy muszą wiedzieć, po co uzupełniają formularz, po co podają poszczególne dane – jeżeli to wiedzą, zrozumiały jest dla nich fakt podania tych danych • Znajomość kontekstu uzupełnienia – forma formularza uzależniona powinna być od kontekstu uzupełnienia danych – czasem ktoś chce zrobić szybko bazując na standardowych form-‐fieldach; czasem warto dać więcej playability • Pola umieszczone w odpowiedniej kolejności – kolejność pól nie może być przypadkowa – labele czytane jeden po drugim same z siebie powinny opowiadać historię – tworzyć nić komunikacji • Konwersacja – forma opisów labeli powinna być jasna i czytelna – powinno się unikać słów kluczowych i generycznych haseł • Podobne pola powinny być pogrupowane (razem) • Koncentracja na formularzu – no distracNons please! • Autouzupełnianie możliwie największej ilości danych (np. miejscowość na podstawie kodu) • Unikanie błędów zamiast ich walidowanie postsubmitowe • Proces to tunel • Na pewno nie ilość pól (zwłaszcza, gdy spełnione są powyższe)
- 45. Lekcja 4 Jeśli użytkownik rozumie celowość formularza i wie, do czego posłużą umieszczone tam dane, formularz nie musi być kompaktowy. Źródło: Inwestorwkapitalludzki.pl (zrzut)
- 46. Lekcja 4 1 2 Konwersja porównywalna. Z punktu widzenia biznesowego różnica znaczna. Źródło: Uxeria.com (zrzut)
- 47. Lekcja 4 Ogólne zasady, wzorce i statystyki są przydatne jako inspiracje i tezy. Nie powinniśmy ich uznawać za prawdziwe, dopóki nie zweryfikujemy na swoim podwórku. • Testy A/B • AnalyNcs • Badania z użytkownikami • Mouse tracking, heatmapy • Grupy fokusowe
- 49. Lekcja 5 Źr.: htp://johnhaime.com/2014/04/your-‐emoNonal-‐brain-‐a-‐key-‐in-‐performance/ Decyzja zakupowa nie jest wynikiem pracy mózgu racjonalnego, lecz emocjonalnego
- 50. Lekcja 5 Golden Circle – emoNonal design
- 51. Lekcja 5 Klienci kupują emocjonalnie. Determinantem wcale nie muszą być są logiczne przesłanki. Często jest nią wiara we wspólne wartości.
- 52. Lekcja 5 EmoNonal design w markeNngu
- 53. Lekcja 5 EmoNonal design w webie
- 54. Lekcja 5 Emocjonalne doświadczenie powinno być spójne we wszystkich touchpointach Klienta z produktem
- 55. Lekcja 5 Emocje wynikają z sumy wszystkich doświadczeń Klienta z firmą / produktem. Tych dobrych i tych złych. Niestety gorsze doświadczenia i emocje są zawsze silniejsze (negaNvity bias).
- 56. Lekcja 5 Projektujemy emocje – stąd nasze projekty powinny być spójne z emocjonalnym nastawieniem klientów do produktu • Jeśli jest to dyskont, powinien wyglądać jak dyskont • Jeśli jest to sklep z produktami premium, taką też powinien mieć architekturę informacji • Jeśli to jest aplikacja wspierająca biznes, to też powinna mówić strona – rozumiemy Twój biznes To wszystko zarówno w kontekście architektury informacji, jak i estetyki witryny
- 57. Lekcja 5 źr.: htp://jesserogerson.com/tag/brain/ A nasz projekt składa się z treści i formy, które powinny budować spójną komunikację…
- 58. Lekcja 5 EmoNonal design – połączenie formy i treści, by zbudować spójne doświadczenie emocjonalne.
- 59. Lekcja 5 Naszym zadaniem jest projektowanie doświadczeń emocjonalnych. Czym ten produkt ma być dla Klienta – jakie emocje mają ich łączyć? To nie decyzja projektanta, lecz biznesu. Ta konsekwencja i spójność produktowa powinna być zachowana na każdym touchpoincie.
- 60. Dziękuję za uwagę Igor Farafonow igor@uxeria.com
- 61. Pragnę poinformować, że wszystkie przykłady i grafiki wykorzystane w tej prezentacji są oficjalnymi materiałami podmiotów, bądź też zrzutami ekranów aktualnych systemów i stron internetowych – dostępnymi wszystkim użytkownikom Internetu (przy każdym wpisane źródło pochodzenia). Żadne z zaprezentowanych w prezentacji grafik i informacji nie są objęte tajemnicą firmową ani nie są materiałami wewnętrznymi jakiegokolwiek podmiotu. Informuję również, że prezentowane przeze mnie przykłady nie powinny świadczyć o tym, że w ramach mojej dotychczasowej pracy realizowałem którykolwiek z przedstawionych projektów. Celem umieszczenia tych materiałów jest wskazanie moich subiektywnych odczuć i przemyśleń dotyczących pewnych rozwiązań. Nie powinno się przypuszczać, żebym bym był w jakikolwiek sposób powiązany z tymi witrynami i systemami, bądź podmiotami za nie odpowiedzialnymi. Igor Farafonow. Uwaga dodatkowa
Editor's Notes
- Jednym z pierwszy projektów, które realizowałem w GG było GG.pl. Miał to być system, który poprzez społęczności troszkę odciągnie użytkowników od Facebooka. W ramach biznesu w GG powołany został zespół – razem określaliśmy, co powinno stanowić wartość dla naszych użytkowników
- Oczywiście dokładnie przejrzeliśmy facebooka – nasz CEO zrobił mini focusy, szukaliśmy też ogólnych aspektów w FB, które nam nie leżały. Jednym z takich aspektów była komunikacja one-to-all. GG to było od zawsze one-to-one. My chcieliśmy przede wszystkim powołać one-to-few. Rozmowę w niewielkich grupach i walle półprywatne Chcieliśmy troszkę nadać charakteru GG – emotikony, w dużej mierze rozpropagowane w Posce właśnie dzięki GG. Wykorzystaliśmy je jako substytut lajków. Poza tym chcieliśmy wyróżniać ciekawe wpisy o postępującym zaangażowaniu, itp..
- Przygoda była niesamowita, bo projekt miał powstać w ciągu kilku miesięcy. Pracowaliśmy na dwukrotność swoich sił. W kluczowych momentach nad moimi makietami pracowało prawie 100 programistów.
- Mnożyliśmy fajne funkcjonalności, z których mogliby korzystać nasi użytkownicy
- Gdy uruchamialiśmy produkt – byłem z siebie dumny. To pierwsza w moim życiu konferencja prasowa. Nasz CEO opowiadał o produkcie mediom, a ja stałem z boku rozpierany przez dumę. Następnie zapisałęm się do grup dyskusyjnych ‘zgłoś błąd’ i ‘nie działa’, by poznać feedback naszych użytkowników…
- Domyślacie się pewnie, jak skończył ten produkt. Jak myślicie, dlaczego? Podpowiem Wam jedno – ten błąd usability przewijał się na wszystkich ekranach, które przed chwilą widzieliście.
- Problem tkwił w tym, że produkt został zaprojektowany pod sytuację, gdzie użytkownicy regularnie dodają treści, dzielą się zdjęciami, korzystają ze wszystkich funkcjonalności serwisu. Produkt pod kątem interfejsu był gotowy pod sytuację idealną – która w normalnym produkcie zostaje osiągnięta dopiero w jakimś czasie po uruchomieniu.
- Więc weźmy teraz te ekrany i zamiast 20 wpisóna wallu dajmy 3 wpisy, zamiast awatarów przy mordkach znajomych na liście dajmy zaślepki, zamiast pięknego bloczka grup dajmy pustkę… jak wtedy wygląda nasz produkt?
- Tak naprawdę wyglądał nasz produkt – pusty bloczek z konferencjami, wpisy na streamie wynikające tylko z tego, że zdecydowaliśmy ratować sytuację tym, że w wallu pojawiały się opisy, które sobie ustawiali użytkownicy… GG.pl stało się takim archiwum opisów Twoich znajomych…
- Zbudowaliśmy piękne podwórko, ale nasz interfejs był dostosowany do działających mechanizmów, które już zbudowały zaangażowanie. A naszym zadaniem było dopiero budowanie tego zaangażowania. Inaczej powinien wyglądać wall, na którym średnio dziennie pojawi się 5 wpisów niż taki, na którym pojawi się 50 wpisów. Inaczej powinien wyglądać teaser wgrania zdjęcia, gdy użytkownik jeszcze nic nie wprowadził. Rzecz w tym, by zdawać sobie sprawę z tego, na jakim etapie zaangażowania i znajomości interfejsu jest użytkownik w danej chwili i umieć zaprojektować rozwiązania pod ten etap, a nie pod etap kolejny. Strona www to coś, co się rozwija i zmienia, a nie budynek, który raz wybudowany ma stać X lat.
- Bardzo ważne jest uwzględnienie swojej sytuacji na etapie dobierania wzorców projektowych. Serwisy, z których pochodzą, mogą być na zupełnie innym cyklu życia niż nasz produkt – to, że dana funkcjonalność z powodzeniem realizuje się u innych, nie znaczy że zadziała u nas
- Przykład
- Wizard tworzenia profilu w FB. Wyobraźcie sobie, że go odbrandujemy – logujemy się do jakiegoś nowego portalu społęcznościowego – wcale tam nie ma naszych znajomych, wcale nie mamy zbudowanego w głowie wiarygodnego modelu tego produktu. Czy ten formularz zachęca Was do korzystania z serwisu? Czy podacie swój adres email i hasło do poczty? Czy wpiszecie w te nieatrakcyjne pole swoje szczegółowe informacje o miejscu zamieszkania, mieście rodzinnym i inne? Czy będzie się Wam chciało wyszukać zdjęcie do umieszczenia jako profilowe? To są trzy pierwsze kroki po utworzeniu konta na facebooku.
- To, że u nich to działa, nie znaczy, że zadziała u nas.
- Wzorzec projektowy to coś, co działa u innych, więc możemy założyć, że zadziała u nas ze względu na podobną specyfiką zachowawczą. Jednakżę pamiętajcie – fakt, że zadziałało u konkurencji nie musi wynikać z tego, że dana funkcjonalność jest dobrze zaprojektowana. To, że użytkownicy z powodzeniem realizują dane zadania na stronie wynika również np. z zaufania do produktu / firmy; większej chęci dołączenia ze względu na social proof, itp..
- I to jest pierwsza lekcja, jaką chcę się z Wami dziś podzielić. Projektować należy pod aktualną sytuację. Nie wolno wierzyć, że wystarczy uruchomić produkt i użytkownicy w ramach chęci wypróbowania nowości będą sobie klikać po Twoim produkcie. Nie jesteś Googlem, Applem ani Facebookiem
- Lekcja 2
- Kto z Was projektował kiedyś sklep internetowy? Podnieście proszę ręce do góry.
- Czy w ramach projektu rysowaliście również działanie systemów do oceny produktów i dodawania recenzji?
- A czy projektowaliście maile wysyłane do klientów z prośbą o ocenę produktu? Bo jeśli nie, to znaczy że nie wykorzystaliście najbardziej efektywnego pod kątem doświadczeń klienta modułu mającego zrealizować Wasz cel projektowy.
- O Co chodzi – gdy mówimy o funkcjonalnościach projektowanych, nie możemy ich rozpatrywać w kategoriach modułów, lecz w kategoriach doświadczeń – rozwiązań. Jeśli Waszym celem jest stworzenie efektywnego systemu ocen, nie rozpatrujcie tego w kategorii „narysujemy bloczki z ocenami na produkcie i damy też informacje o ocenie na listach produktów” – musicie przemyśleć cały proces. Uwzględnić np. powiadomienia, gdy ktoś doda swój komentarz o produkcie, i inne podsystemy pomagające zwiększać zaangażowanie.
- Teraz kolejna rzecz – ile osób z Was projektowało system autentykacji?
- Gdy mówimy o systemach logowania, to najczęściej widzimy coś takiego… Ale z punktu widzenia projektowego jak należy je rozpatrywać?
- To jest raptem wycinek listy ekranów związanych z centrum autentykacji, o których ciągle zapominamy.
- W ramach naszych działan projektujemy cały proces, a nie tylko pojedyncze ekrany.
- Lekcja trzy.
- Chcę Wam pokazać jedną z makiet, które realizowałem w GG – celem było stworzenie fajnego playera do MP3 w cloudzie.
- Jak takie rzeczy kończą?
- Pzede wszystkim czas pracy.
- IT jest kluczowe do zaangażowania na początku – razem określacie z biznesem i IT, które funkcjonalności muszą zostać odpalone na start. Tych funkcjonalności musi być jak najmniej – skoncentrować się należy przede wszystkim na tych, które są najbardziej cenne z punktu widzenia biznesowego, a jednocześnie najmniej czasochłonne w realizacji z punktu widzenia IT
- Gdybyśmy to zrobili w tym projekcie playera muzycznego, mielibyśmy gotowy produkt już po kilku miesiącach. Przetestowalibyśmy go i lepiej zadbali o to, by był dopracowany. Pamiętać należy, że nasz dizajn nie musi być od razu super piękny. On po prostu musi się stać.
- Podobnie mieliśmy w Uxerii – dewelopment Uxerii trwał kilka lat. Wyobrażacie sobie, że od początku moglibyśmy mieć badania scenariuszowe, a resztę byśmy dobudowali później – mielibyśmy gotowy produkt w ciągu pół roku / roku. Co za tym idzie – pozycję biznesową na rynku, zbudowaną wartość i stałych klientów.
- Im większe zakresy ustalamy na etapie planowania, tym większe ryzyko, że nie uda nam się zrealizować projektu dobrze.
- Minimalizuj liczbę funkcojnalności i mechanizmów. Twój produkt nie musi być super piękny innowacyjny – on musi po przede wszystkim działać. To jest trzecia lekcja na dziś.
- Lekcja trzy.
- Tu chciałbym porozmawiać ponownie o wzorcach UX i ogólnych wytycznych w projektowania. Znacie tą starą jak świat zasadę, często wałkowaną przez kolejnych ekspertów od UX. Że każde kolejne pole formularza obniża jego konwersję o 15-30%. Kiedyś w to mocno wierzyłem. No zobaczcie np. tu – proces zakupowy w pierwszym lepszym koszyku, który odnalazłem na potrzebę tego wykładu. No i faktycznie – jak przyjmiemy że usuniemy zbędne pola: po co dwa telefony, po co gG i skajp? Czemy przy adresie do zamówienia widnieje faktura VAT. Po co zresztą gwiazdki w nawiasach. Po co hasło od razu widoczne? Jak widzicie ty zbędnych danych jest dużo. Więc jak uśrednimy populację sklepów internetowych, faktycznie można uznać, że każde dodatkowe pole obniża konwersję formularza. Ale to jest myślenie stereotypami – podobnie jak myślenie że wszyscy czarni tańczą lepiej od białych.
- Hubspot – mistrzowie content marketingu. Ich formularze, które używają nie tylko do sales inquiries, ale i innych, np. pobrań materiałów udostępnianych przez web, są długie. A jednak oni dobrze wiedzą, co robią?
- Tak naprawdę o tym, czy użytkownik wypełni nasz formularz, decyduje szereg czynników. Niektóre z nich wypisałem tu. Ale to tylko drobna część wszystkich czynników – tak samo są to czynniki na różnym poziomie szczegółowości.
- Najważniejsze jest jednak to, że użytkownicy nie będą mieli oporów przed uzupełnianiem formularza, gdy będą rozmieć, po co go robią i do czego posłużą te dane. Oczywiście inna sprawa to generalna potrzeba uzupełnienia formularza bo przecież dla użytkownika to nie ma być ‘chcę uzupełnić formularz’ tylk ‘chcę poznać ofertę’, ‘chcę sfinalizować transakcję zakupową’, ‘chcę założyć konto’.
- My też to porównaliśmy na formularzach cennikowych i zakłądania konta. Różnica konwersji nieznaczna, ale z punktu widzenia biznesowego
- Stąd też warto słuchać ogólnych wskazówek i guidelineów projektowych, ale tylko w kontekście formułowania tez. Ponownie – nie znamy wszystkich czynników i dodatkowych cech, na których bazują te wskazówki, więc ignorancją i głupotą z naszej strony byłoby nieweryfikowanie ich słuszności w naszym projekcie. Każdą nowość powinniśmy skrupulatnie testować.
- Ostatnia lekcja – tym razem o produkcie
- Z punktu widzenia neurobiologii wyróżniamy mózg gadzi, mózg emocjonalny i mózg racjonalny. Wykazane zostały że decyzje zakupowe wynikają z działania nie mózgu racjonalnego, lecz emocjonalnego.
- Zakup emocjonalny. O tym mówił Simon Sinek, gdy przedstawiał Golden Circle. Opisać, o co chodzi
- Czyli aby doprowadzić do zakupu musimy zbudować z Klientem emocjonalną więź
- Emotional design jest często stosowany w marketingu. Klienci kupują, bo wierzą w te same wartości co my. Opisać Apple, Sephorę, Porsche, pepsi.
- Podobnie w webcie – opisać poprzednią stronę ryanair
- Co jest jednak najważniejsze – te doświadczenia muszą być spójne na każdym touchpoincie klienta z produktem.
- A emocje dotyczące naszego produktu wynikają z sumy doświadczeń klienta. Co gorsze – te złe doświadczenia są zawsze silniejsze od dobrych – to się nazywa negativity bias.
- Nasz produkt powinien być częścią tych doświadczeń i budować z nimi spójne customer experience.
- Pamiętajmy, że z punktu widzenia poznawczego nasz mózg jednocześnie przetwarza bodźce analityczne i plastyczne – więc musi to być realizowane zarówno na poziomie merytoryki, jak i layoutu.
- Dlatego między innymi okładka Forbesa różni się od okładki Bravo nie tylko treściami, ale i ogólnym look n feel.
- Ostatnia lekcja – projektujemy doświadczenia emocjonalne. Stąd kluczowa jest konsekwencja i spójność we wszystkich touchpointach klienta z naszym produktem. Nasza działka UX jest tylko częścią tego doświadczenia. Poza nami jest spredaż, support, marketing, technologia. Ale nasza działka powinna być z pozostałymi komplementarna.
- Dziękuję za uwagę