Chcesz wdrożyć nowy design w produkcie? Zobacz, jak uniknąć błędów i dodatkowych kosztów.

W tym odcinku rozmawiamy z seniorką UX i team liderką, Martą, jak uniknąć błędów przy wdrażaniu designu. 

Więc jeśli masz produkt lub usługę cyfrową, która wymaga poprawy wyglądu i funkcjonalności, to ten odcinek jest dla Ciebie.

Dzielimy się naszym wieloletnim doświadczeniem z pracy projektowej z klientami.

Najczęstsze błędy podczas wdrażania designu na nowej stronie:

• Brak Project Managera i oszczędzanie na procesach związanych z zarządzaniem projektem – i związane z tym ukryte (spore) koszty

• Omijanie testów z użytkownikami naszego produktu – kolejna pozorna oszczędność w projekcie

• Brak prototypów, które pokazują, jak ma działać produkt.

• Brak finalnych treści, które mają pojawić się na stronie

• Zatrudnienie grafika, który ma pokolorować na nowo nasz interfejs, zamiast UX Designera

• Brak myślenia systemowego o warstwie graficznej naszego interfejsu – czyli brak posiadania Design Systemu

Gość odcinka: Marta Jakubowska-Sobczak – UX Designer & Researcher & Team Leader z 7- letnim doświadczeniem

„Posiadam holistyczne doświadczenie pracy z projektami. Od rozwijania pierwszych konceptów i ich walidacji, przez budowę PoC i MVP, aż po produkty działające na rynku. Prowadzę badania jakościowe, które stanowią punkt wyjścia dla kolejnych zmian w produkcie.

Skomplikowane i złożone systemy upraszczam na zrozumiałe ścieżki użytkownika. 
W Zimie miałam okazję pracować ze startupami: Deliver in Person, Welcome Pickups, Vinesia, AI Clearing, rozwijałam produkty takich firm jak Biletomat.pl, Oferteo.pl, IPF-D, Przychodnia Lekarska nOvum, sieć prywatnych szpitali i przychodni EuroMediCare.„

Rozmowy możesz też posłuchać na Youtube:

Zachęcamy Cię do subskrybowania naszego podcastu! Jeśli interesuje Cię tematyka doświadczeń klientów w świecie cyfrowym i tego, jak design może wspierać osiąganie celów biznesowych.

Będziemy Ci wdzięczni za udostępnienie linku do tego odcinka osobom, którym chcesz pomóc w rozwijaniu biznesu lub własnych kompetencji.

Transkrypcja rozmowy

Ilona: Cześć. W tym odcinku porozmawiamy o tym, jak uniknąć błędów przy wdrażaniu designu. Więc jeśli masz produkt cyfrowy lub usługę, która wymaga przeprojektowania lub jakichś zmian funkcjonalnych, to ten odcinek jest dla Ciebie. 

Podzielimy się dzisiaj naszym wieloletnim doświadczeniem przy wdrażaniu designu. A pomoże nam w tym nasza team liderka Marta Jakubowska-Sobczak. Cześć Marta.

Marta: Cześć Ilona. Bardzo miło mi być po raz drugi już w podcaście Design i Biznes, tym razem w wersji wideo, która od niedawna powstaje.

Ilona: Tak, to jest nasz romans z YouTubem i z wideo, do czego się trzeba o wiele bardziej przygotowywać, ale dzięki temu mamy nadzieję, że odcinki są ciekawsze. 

Czym jest wdrażanie designu?

Ilona: Marta, dzisiaj chcemy porozmawiać o błędach, które wynikają z wdrożenia. Ale samo słowo wdrożenie jest bardzo kojarzone z tym wdrożeniem deweloperskim. Co to właściwie znaczy wdrożenie designu?

Marta: Super, że od tego zaczynamy, bo właśnie chciałam tutaj nakreślić nam odpowiednie rozumienie tego terminu, które w tej rozmowie będzie użyte. Chciałabym, żebyśmy myśleli o tym wdrożeniu trochę szerzej. 

Jest to wszystko, co się dzieje i co doprowadza do tego, że nasz produkt, albo strona, albo apka ujrzą światło dzienne. I one będą do pobrania w sklepie, bądź strona będzie opublikowana. 

Czyli taki szerszy kontekst tego, co musi się zadziać przed i gdzie mogą wystąpić błędy przed, które wpływają na to, że potem przy wdrożeniu de facto się pojawiają jakieś błędy takie stricte, że coś jest źle zrobione, albo po prostu coś się wydłuża, albo nie to, co było ustalone, jest zrobione, czy są jakieś inne problemy.

Trochę to jest tak jak z budowaniem domu. Ja teraz jestem na etapie szukania, więc to jest bliski temat dla mnie, że kiedy chcemy wybudować dom, to oczywiście myślimy o tym, że tak, musimy wymurować ściany, musimy wstawić tam okna, dach i tak dalej. 

Natomiast żeby to się wszystko sprawnie zadziało, to wcześniej musi być projekt. Musi być przemyślany ten dom. My musimy wiedzieć, ile chcemy mieć tam pokoi, czy chcemy mieć piętro, czy chcemy mieć dom parterowy. Gdzie chcemy przechodzić, gdzie nam się musi kończyć korytarz.

Tak samo trochę jest z wdrożeniem. Kiedy myślimy o tym, że to budujemy, to fajnie, żeby to, co budujemy, było przemyślane i wolne od błędów. I tak proponuję, żebyśmy tę rozmowę tutaj dzisiaj przeprowadziły, że podzieliły się wszystkimi doświadczeniami związanymi z projektowaniem i też przekazywaniem tego projektu do deweloperów, które pomagają uniknąć błędów.

Główne błędy w procesie wdrażania produktu

Ilona: Okej, więc odnosząc się do samego tytułu odcinka, który mówi właśnie o błędach we wdrażaniu, jakie byś błędy wyróżniła?

Marta: Pierwsza rzecz to powiedziałabym, że brak odpowiedniego zarządzania, brak PM-a w projekcie, czy jakieś takie oszczędzanie na tym elemencie. 

Kolejna rzecz to niechęć do testowania z użytkownikami. Niechęć do zderzania naszego pomysłu, czy blokada jakaś przed tym.

To, że nie ma finalnych treści, mam na myśli tekst, zdjęcia, wideo, do bardzo późnego etapu projektu, co utrudnia pracę, o czym pewnie w szczegółach porozmawiamy w dalszej części. 

I jeszcze kolejna rzecz to jest brak prototypów w projekcie. I te prototypy są ważną częścią, bo pokazują jak nasz produkt działa, co się w nim dzieje, gdzie ktoś przechodzi. 

No i to chyba są takie, które mi tak przychodzą w tej chwili, w której najczęściej spotykam.

Ilona: Ja mam jeszcze taki błąd, który nie dzieje się może stricte już na etapie projektowania, ale jeszcze wcześniej, kiedy jest proces sprzedaży. Czasami zdarzy się tak, że klienci przychodzą do nas i pytają o grafika. Chcą zatrudnić grafika. I to też jest błąd, który potem ma swoje konsekwencje w tym, że projekt jest albo ciężko wdrażalny, albo niewdrażalny. 

I też druga rzecz, która też jest często podważana i są pytania dotyczące tej części, to jest, dlaczego tu jest design system i dlaczego my do tego projektu musimy taki design system stworzyć.

Czyli takim błędem byłoby brak systemowego myślenia o naszym projekcie, designie, UX-ie, UI-u. I to są jeszcze takie dwie rzeczy, które ja bym wyróżniła właśnie gdzieś tam, które widzę na tym pierwszym etapie, czyli szukania w ogóle podwykonawcy, czy partnera biznesowego.

Marta: Super, że to dodałaś. To są też, bardzo często się też z tym spotykam.

Oszczędzanie na zarządzaniu

Ilona: Okej, a gdybyśmy sobie głębiej porozmawiały o każdym z tych punktów i gdybyś miała wyróżnić taki, który jest najgroźniejszy albo sprawia najwięcej kłopotów, to który by to był?

Marta: Ja proponuję zacząć od takiego bardzo podstawowego, czyli właśnie brak PM-a czy oszczędzanie na zarządzaniu. To może powodować szereg różnych błędów. 

To mogą być stricte faktycznie błędy we wdrożeniu, na zasadzie coś jednak zostało przekręcone, nie to wdrożone, nie ta wersja, ale to też przede wszystkim wydłuża pracę i utrudnia tę pracę. To sprawia, że ta praca ma dużo zbędnych ruchów.

Ilona: To coś, co ja jeszcze widzę w tej komunikacji, to jest na przykład brak dawania feedbacku na bieżąco. Jest czekanie do ostatniej chwili, czy nawet nieprzekazywanie tego feedbacku. Nawet jeżeli on jest, to gdzieś on utyka. I to też wydłuża pracę i zwiększa koszty.

Marta: Tak. Tu też są np. błędy w estymacji. Kiedy my zaczynamy projekt, coś szacujemy i tak samo to szacują inni wykonawcy. I czasem tak jest, że ten projekt się rozwija i jednak ta estymacja się rozmija z rzeczywistością. 

To jest coś, czym trzeba zarządzić. Też tymi oczekiwaniami względem np. początkowego terminu. Albo względem scope’u, czyli zakresu pracy, który się zmienia np. w trakcie projektu i wymaga czasem zazwyczaj dołożenia pieniędzy. Nie spotkałam się jeszcze, żeby budżet się zmniejszył.

Ilona: Tak, no to jest specyfika projektów IT. Odnosząc się do tej metafory, o której ty powiedziałaś, budowania domu, to też byłaby specyfika takich projektów, które po prostu trwają dosyć długo. 

To nie jest taki jednorazowy strzał typu warsztat, tylko jeżeli mamy coś wdrożyć od A do Z, to zajmuje to czas, uwagę, energię, no i często zapominamy o pewnych rzeczach, ustaleniach, czy czymś, co było, nie wiem, rok temu powiedziane, czy nawet dwa tygodnie temu. 

I ważne jest, żeby zespół był dobrze zorganizowany, a jak dobrze wiemy, zespół się sam nie zorganizuje. Potrzebny jest ktoś, kto będzie takim liderem, PM-em, czyli project managerem, który zarządzi tym, żeby to gadko poszło.

Marta: Tak i to jest coś z mojego doświadczenia, co mogę powiedzieć, że świetnie się sprawdza. Stykałam się już z tym, że jest bardzo duża pokusa, żeby na tej części przyoszczędzić, żeby ją skrócić, zmniejszyć, nie dać odpowiedniego czasu takim osobom, które naoliwiają tę maszynkę, żeby sprawnie działała. 

Ja polecam jednak, żeby na tym nie oszczędzać. Zainwestować w to. My w Zimie też mamy procesy, które… no częścią pracy takiej osoby jest to, żeby ona przechodziła w jakiś sposób taki zorganizowany przez ten proces i zespół też, żeby przechodził w sposób zorganizowany. 

Żebyśmy wiedzieli, co się dzieje, na którym etapie, kiedy trzeba o coś zapytać, do kiedy trzeba zamknąć jakieś ustalenia. I u nas tak to jest zrobione, że jest osoba, która tego pilnuje. Ona ma jasny proces. Dba o te podsumowania spotkań. Dba o przypominanie o terminach, o umawianiu się z wyprzedzeniem na jakieś większe spotkanie.

I dzięki temu ta praca nie stoi i żadne ustalenia nie umykają, co stricte się przekłada na wdrożenie. Ale też całość po prostu idzie płynnie.

Niechęć do testowania na użytkownikach

Ilona: Okej, a patrząc na tę listę, którą wymieniłaś, co byłoby kolejne?

Marta: Myślę, że kolejny błąd to jest niechęć do testów, do pokazywania tego, co wypracowaliśmy realnym użytkownikom i do zbierania feedbacku od nich.

Ilona: Okej, a jak to wpływa właśnie na te błędy we wdrożeniu designu?

Marta: To wpływa bardziej na efekt naszego wdrożenia, bo produkt może być nawet dobrze wdrożony, w sensie zgodnie z tym, co wypracowaliśmy, natomiast może być nieużyteczny. 

I w tym sensie, jeżeli nie mamy tego feedbacku, to możemy wydać pieniądze i czas programistów, czy nawet projektantów na to, że oni zaprojektują coś, co de facto nie przynosi korzyści organizacji, nie generuje wartości. 

Też mogą być jakieś rozwiązania niedopasowane. Często też się zdarza, że podczas testowania z użytkownikami, szczególnie jeżeli produkt już istnieje i to jest na przykład na jakimś, nie na makietach czy prototypach, tylko na istniejącym produkcie… 

Użytkownicy wyłapują przy okazji inne błędy, o których nie wiedzieliśmy, które w ogóle nie były tematem, ale pojawiają się na tej ścieżce. To też są często błędy wdrożenia. Te błędy można wyłapać i naprawić.

Ilona: Tak. O samych badaniach, tutaj widzę, że już ci się oczy świecą, bo to jest twój konik… O samych badaniach rozmawiałyśmy w poprzednim odcinku podcastu z Martą. Podlinkujemy go w opisie. Rozwijamy tam trochę szerzej ten temat badawczy. 

Ale jakbyś miała w jakiejś takiej pigułce opowiedzieć o problemach wynikających z tej niechęci do testów, to co by to było?

Skąd wynika brak badań z użytkownikami

Marta: Może ja powiem, skąd często wynika ta niechęć…

Często produktowcy czy właściciele mają takie pojęcie, że to jest drogie i czasochłonne. I fakt, to wymaga pracy. Natomiast nie musi być też zawsze bardzo drogie. Można te testy zoptymalizować, można je dopasować do tego, czego potrzebujesz w swoim produkcie i można je zrobić szybciej, można je zrobić jakby czasem dłużej, zależnie od tego, co chcesz osiągnąć. 

Kolejnym powodem tej niechęci jest często takie podejście, że ja bardzo kocham swój produkt, ja jestem jego autorem i ja po prostu wiem, czego ci ludzie potrzebują. I ja im to daję. 

I niezderzanie tego z obawy albo z nieświadomości, jak dużo wartości to może przynieść… Zazwyczaj pierwsze spotkanie z porządnymi testami oducza tej postawy, bo ludzie widzą, jak dużo można zyskać. 

Ta czasochłonność jest częstą obawą przed prowadzeniem testów. Natomiast tutaj warto właśnie myśleć o tym, że te testy muszą być dobrane do produktu i one czasem mogą być zmniejszone, jeżeli tego akurat potrzeba w produkcie i trzeba na przykład mieć wyniki szybciej, no to trzeba ten zakres okroić.

Ilona: No tak, bo czasami najlepsza metoda badawcza… powiedzmy te badania dzienniczkowe, które są takimi długimi badaniami, jeżeli chodzi o czas… byłaby najlepsza dla naszego produktu. 

Ale nie mamy tych trzech miesięcy. Musimy podjąć decyzję w miesiąc. Więc to, co robimy, to, w jaki sposób próbujemy ciągle osiągnąć ten cel, czyli dostarczyć jednak tę informację zwrotną, żeby podejmować lepsze decyzje, to jest zaproponować po prostu inną metodę. 

I taką sytuację miałyśmy ostatnio w jednym z projektów…

Małymi krokami do badań UX

Marta: Tak, tam zaproponowaliśmy pilotaż. Trochę inaczej to wyglądało. Zaproponowaliśmy klientowi, że zrobimy mniejsze badanie na początek, w którym upewnimy się, że później robiąc większe badanie na pewno dowiemy się tego czego chcieliśmy się dowiedzieć. 

To był akurat klient z branży edukacyjnej. Tam były rozmowy z nauczycielami i zdecydowaliśmy się zrobić badanie z trzema osobami z danego produktu po to, żeby w ogóle zweryfikować, czy nasze hipotezy, nasze myślenie o tym jest dobre. 

Okazało się, że trochę trzeba zmienić to główne badanie, bo jednak nie do końca tam były akcenty, gdzie zakładaliśmy, że są. I teraz pracujemy nad drugą częścią tego badania i ono już jest zmienione, będzie inny scenariusz napisany, bo są troszeczkę inne wyzwania przed tym badaniem. 

Klient mógł się tego dowiedzieć dzięki temu, że zrobił mniejszy fragment badania, który mu powiedział, co de facto musi zbadać później. Co przełoży się na wdrożenie zmian w produkcie w przyszłości.

Badania z użytkownikami online 

Ilona: Ale też to, co ja bardzo lubię, co sprawia, że te badania są chętniej wybierane i też optymalizują koszty, to jest przeprowadzanie ich online.

Marta: Tak, z tym też mamy doświadczenie, to się super sprawdza…

Ilona: Szczególnie po dwudziestym, prawda? Rok 2020 był takim punktem, gdzie…

Marta: Wcześniej też się robiło oczywiście takie badania, natomiast po pandemii okazało się, że jest bardzo mało przeszkód przy takich badaniach, bo była to jedyna opcja. 

One są tańsze po prostu, bo nie spotykamy się na żywo. Badacz nie musi jechać do jakiegoś innego miasta. Jeśli ktoś się nie pojawi, to jest mniejszy problem. Jeśli ktoś specjalnie pojechał na ten dzień i ktoś nie przyszedł, no to generuje to więcej kosztów. Więc jest sposób na to, żeby tę obawę o te koszty zmniejszyć. 

Rekrutacja użytkowników do badań 

Marta: Kolejną rzeczą, w której agencja może pomóc, tak jak w Zimie my to robimy, jest rekrutacja. Rekrutacja jest bardzo czasochłonna i kosztochłonna. Czasem jest tym, co zniechęca.

Bo zaczynamy tę rekrutację, bardzo trudno nam znaleźć odpowiednie osoby do testu i firma się poddaje. Stwierdza, że po prostu, no nie, nie przeprowadzę tego. Dlatego my w tym wspieramy. Znajdujemy te osoby. Też dbamy o to, żeby to były właśnie dobre osoby. Dzięki temu całe testy są miarodajne, ale to jest też coś, w czym możemy wyręczyć.

Grafik zamiast projektanta UX/UI

Ilona: No i właśnie kolejna rzecz, która jest problematyczna i sprawia, że wdrożenie jest trudniejsze, to jest zatrudnienie grafika zamiast projektanta UX/UI. 

I tutaj często ta sytuacja występuje, kiedy jakiś produkt istnieje. On jest zakodowany, ale nie do końca spełnia wymagania biznesowe w takim kontekście, że nie zarabia tyle, ile na przykład byśmy oczekiwali. Albo widzimy, że konkurencja nas trochę podgryza.

Zapada decyzja, że trzeba taki redesign przeprowadzić. Zespoły szukają grafika, który poprawi interfejs, wygląd strony, produktu cyfrowego, usługi, czy aplikacji. 

A taka osoba, nie ma takich umiejętności, żeby popracować nad użytecznością, żeby poprawić nie tylko to, jak ten produkt wygląda, ale też jak on działa. I nie do końca zatrudnienie grafika, pozwoli nam osiągnąć ten pierwotny efekt biznesowy.

Marta: Tak. I jak się przekłada na wdrożenie. Bo jeżeli faktycznie tak się stało, że był właśnie zatrudniony grafik, który zrobił zmianę wizualną, ale nie za bardzo w funkcjonalność ingerował… Albo narysował coś, a nie do końca pomyślał, jak to będzie działało… Jak nowy fragment systemu zadziała ze starym… 

Zaczynamy wdrażać i programiści albo przychodzą z pytaniami, bo coś im się nie zgadza. Wtedy są dwie opcje, tak? Albo się cofamy, poprawiamy, bo na przykład coś było źle zaprojektowane. Co oczywiście wydłuża czas, oni stoją w tym momencie. 

Albo wymyśla się na szybko jakieś obejście, jak to zrobić, tak? I to może nie powoduje stricte błędu, bo to może być wdrożone poprawnie, ale przekłada się bardzo na tę sprawność pracy wdrożeniowej i na to, żeby wdrażać to, co chcemy. 

Myślę, że to jest też spowodowane tym, że ta praca graficzna jest taka bardzo uchwytna w takim sensie, że wszyscy to widzą, że nie podoba się im na przykład, więc chcą to zmienić. Więc łatwo jest dyskutować o tej warstwie wizualnej i łatwo jest powiedzieć, że to jest tego wina. 

UX a budowanie domu

Marta: Natomiast ta praca koncepcyjna, którą często wykonuje UX designer, ona jest taka no mało… wow. Nie daje takiego efektu, bo to często są jakieś schematy, szare makiety, jakieś takie niewizualne.

Nie każdy widzi, patrząc na te elementy, jak bardzo to wpłynie na produkt. I tak jak powiedziałam o metaforze domu na początku… Kiedy mamy projekt tylko domu, na przykład rzuty, pomieszczeń z wymiarami, czy instalacji, to mało kto, poza pewnie jakimiś specjalistami spojrzy na ten rzut i powie: wow, ale to jest zarąbiście zaprojektowany dom. 

Dopiero jak ten dom powstanie, jak te ściany powstaną, jak te rury zostaną położone, to można poczuć wartość z tego projektu i można jakby być w tej przestrzeni i powiedzieć sobie, że kurczę, to jest naprawdę funkcjonalnie zaprojektowane. Bo szafki mi się otwierają w tę stronę. Mam gniazdka tam, gdzie ich potrzebuję itd. 

I to jest podobna sytuacja, że kiedy widzimy projekt, no to trudno jest zobaczyć, jak dużo on da w momencie, kiedy go potem przeniesiemy do tego kolejnego etapu UI i potem wdrożenia.

Ilona: Tak, to fajnie idąc dalej tą metaforą, albo zatrudniamy architekta, który nam to zaprojektuje, albo zatrudniamy dekoratora wnętrz, który nam kupi ładne poduszki.

Marta: Tak, dokładnie. Pewnie, że będzie fajnie z ładnymi poduszkami, ale jak będę musiała sięgać daleko do kontaktu, żeby podłączyć telefon, siedząc na kanapie, to nie będzie to tak przyjemnie się tam siedziało, w tym pokoju.

Brak prototypów

Ilona: No tak, ale powiedziałaś o tych otwierających się szufladach i o tym, że to się wszystko tak fajnie spina i mam gdzie podłączyć gniazdko. Przypomniał mi się punkt, o którym mówiłyśmy wcześniej, czyli brak prototypowania i nieprzygotowywanie prototypów, co idealnie łączy się z tym, że trzeba to wszystko posprawdzać.

Marta: Tak, prototypy są bardzo ważne. Jest dużo narzędzi, które dzisiaj umożliwiają w miarę szybkie ich budowanie. Nasz produkt cyfrowy, aplikacja mobilna, ona się w pewnym momencie składa z ekranów, które są w narysowane programie graficznym, płasko sobie leżą, jeden obok drugiego. 

Natomiast de facto potem to jest coś, co działa, co człowiek używa w różnych sytuacjach, w różnych kontekstach. I zobaczenie tej ścieżki w całości na prototypie bardzo ułatwia pracę wszystkich w zespole. 

To pomaga zrozumieć, gdzie są luki, zadać odpowiednie pytanie, nadać całą strukturę temu naszemu produktowi, tak żeby ona była zrozumiała i żeby to właśnie było użyteczne, żeby nie było tak właśnie, że podchodzę do szafki i ona mi się otwiera ze złej strony.

Czyli jak szukam czegoś na stronie, to żeby to było umieszczone w tym procesie. Jeżeli zamawiam ciuchy i zastanawiam się, jakie są formy przesyłki, bo nie mam paczkomatu pod domem i nie chcę akurat zamówić do paczkomatu, tylko chciałabym kuriera… 

Żeby nie było tak, że muszę porzucić ten cały proces mojego kupowania. Albo muszę go zapisać i teraz szukać pół godziny informacji na stronie o tym, jakie są formy dostawy, tylko żeby to gdzieś było blisko. Żeby była nawet jakaś malutka adnotacja dotycząca dostawy. 

Prototypowanie i badania 

Ilona: A to nam wyjdzie z połączenia prototypowania i badań. To o czym teraz powiedziałaś, łączy w jeden obrazek.

Jeżeli my zrobimy prototyp i w firmie przeklikamy się przez to i powiemy: a, okej, tutaj to może nie do końca tak ma być. Albo: to nie jest użyteczne, to nie jest główna akcja na tym ekranie, powinniśmy to zmienić… To jesteśmy w stanie zareagować już na etapie koncepcyjnym.

Po to są prototypy — żeby poprawić, wyczerpać wszystkie pytania, które mają osoby wewnątrz. A potem jak już to mamy, to idziemy do naszych klientów i pytamy ich. Zgodnie ze scenariuszem realizujemy badanie i sprawdzamy, czy te dane podane na ścieżce mają sens.

Prototypy a dokumentacja

Marta: Tak, dokładnie. Prototypy są też świetnym narzędziem do dokumentowania. Każdy, kto robi produkty cyfrowe, wie, że tam jest sporo niuansów. Teraz możemy przygotować obszerną dokumentację tekstową i opisać to wszystko, jak to działa, ale możemy też część tych rzeczy zawrzeć w prototypie. 

Dzięki temu ktoś, kto to wdraża, nie będzie się musiał domyślać, co się dzieje, jak tutaj ktoś wejdzie, kliknie, albo jak nie ma on czegoś. Tylko będzie to widział i będzie to mógł zrobić tak, jak my to chcieliśmy, żeby było zrobione. 

Nie będzie tak, że dopiero po wdrożeniu my się zorientujemy, że gdzieś tam jednak nie trafia ten użytkownik tam, nie wyświetla się to, co miało się wyświetlać, bo ktoś źle zrozumiał np. nasze notatki, czy jakieś luźne, niepołączone ze sobą widoki.

Brak tekstu w makietach

Ilona: Tak, a żeby przygotować taki prototyp, żeby pójść do użytkowników, no to musimy jeszcze tam coś napisać na tych ekranach.

Marta: Dokładnie. I tu dochodzimy do punktu, który wymieniałam, czyli brak treści czy tekstów, zdjęć na stronach. Oczywiście na etapie prototypowania czy w ogóle rysowania, to już jest ważne, żeby te teksty tam były.

Ilona: Nie muszą być wszystkie.

Marta: Tak, nie muszą być wszystkie, bo też jeżeli projektujemy stronę, to często nie projektujemy każdej pojedynczej strony, tylko są strony jak np. strona produktu, utworzone według jednego schematu i wszystkie produkty tak wyglądają, mimo że tam się wstawia konkretne zdjęcia już potem. 

Warto, żeby już na etapie makiet mieć te teksty, ale to nie jest bardzo popularne. My się staramy tak zawsze pracować, ale wymaga to przygotowania.

Dlaczego to jest ważne? Po pierwsze myślę, że rozumienie wewnątrz zespołu tego, co się dzieje, co tam jest napisane. Dzięki tym tekstom też jest czasem jaśniej, gdzie to prowadzi dalej, bo nie jest jakby napisane tam label, tylko jest napisane dodaj do koszyka. Wtedy wiadomo, że coś dodamy do koszyka wtedy. 

Po drugie, też możemy sprawdzić, jak te teksty współgrają z graficznym interfejsem. Czy one nie są za długie, czy one się mieszczą, czy przy mniejszym urządzeniu coś nie spadnie do drugiej, trzeciej, czwartej linijki. Może nie chcemy, żeby to tak wyglądało. 

Dlatego to jest bardzo ważne, żeby te teksty, czy tak samo zdjęcia, czy filmy… bo musimy pamiętać, że ludzie odbierają ten interfejs jako całość. Oni nie przechodzą przez to jak przez pojedyncze ekrany, tylko wchodzą na stronę, czy do aplikacji i chcą coś zrobić. Chcą mieć swoją lekcję w Duolingo. 

To, co oni zobaczą po kolei, albo im pomoże, albo im przeszkodzi.

Makiety bez tekstu: przykłady problemów

Ilona: Tak, teksty to są instrukcje. Marta, przypomnę Ci teraz nasz projekt na rynek meksykański. Robiłyśmy projekt finansowy Buy Now, Pay Later, gdzie makieta była początkowo przygotowana właśnie w języku angielskim, tak żeby wszystkie zespoły były świadome tego, jak wygląda ten proces, jak on jest przygotowany. 

Potem nastąpiło tłumaczenie na język hiszpański. I pamiętasz tę hiszpańską makietę? Czy ty byś coś z niej zrozumiała, gdybyś nie zrobiła tej angielskiej wersji?

Marta: Nie, no tak, oczywiście, ja nie znam hiszpańskiego.

Ilona: Ale to jest idealny przykład.

Marta: Ale mamy inny przykład. Projektowaliśmy sklep z łóżkami na rynek niemiecki niedawno. No i tam był duży problem. Niemiecki jest bardzo długim językiem. Tam są te słowa, które się zlepiają jak Überraschungsgeschenke, czyli niespodzianki urodzinowe.

Sklejamy kilka słów i tworzymy jedno bardzo długie. To był duży problem na tym interfejsie. Jak potem zostało dodane tłumaczenie, to nam się rozjechało i trzeba było to zoptymalizować. 

Też pamiętam kiedyś, ale to jeszcze w poprzedniej pracy… pracowałam przy produkcie edukacyjnym, który był na wiele rynków. On był międzynarodowy. Taka platforma dla uczniów. 

I tam też zespoły pracowały na wersjach angielskich, ale w którymś momencie było wlewane tłumaczenie. I bardzo były duże problemy przy języku niemieckim i innych długich językach. Bo button nie może mieć nieskończonej długości. Wtedy trzeba albo napisać inny tekst, albo kombinować co zrobić z takim słowem.

Znaczenie tekstu w projektowaniu UX

Ilona: Tak. Dla nas jako projektantów i w ogóle przy prowadzeniu takich projektów to jest mega problematyczne. Brak jakiegokolwiek copy… nawet nie na samym początku, ale w trakcie trwania projektu. Oraz jeżeli tekstów, treści nie ma właśnie do prototypu czy nawet już na finalnym UI. 

I to jest coś, na co bardzo zwracamy uwagę i nasza PM-ka Dorota, o której trochę mówiłyśmy na początku w kontekście notatek i w ogóle organizowania samego projektu, przypomina o tym. 

Chociażby na naszym kick-offie. Mamy dwa kick-offy, żeby zaopiekować się tą częścią też miękką, żeby przekazać wiedzę ze sprzedaży do projektantów, gdzie właśnie rozmawiamy o tym i też rozmawiamy o copy.

Potem mamy kick-off też z klientem, gdzie na pierwszym spotkaniu już ustalamy zasady, kto przygotowuje dane treści, na kiedy. I znowu wracając do pierwszego punktu, Dorota, project managerka, pilnuje, żeby te teksty były na czas. 

W momencie, kiedy teksty się opóźniają, no to nie jesteśmy w stanie skończyć naszej pracy projektowej, bo właśnie będzie taka sytuacja, jak teraz powiedziałaś — wlewamy jakąś treść, która jest bardzo długa i nam się rozjeżdża interfejs.

Więc jaki jest sens przygotowywania makiet finalnych UI-ów, finalnych projektów, jeżeli my nie mamy tych ostatecznych tekstów. Nawet takich, które się zbliżają do bycia ostatecznymi, Bo też nie musimy być purystami, nie musimy mieć wszystkiego gotowego przed wdrożeniem, bo taka sytuacja idealna w naturze rzadko występuje. 

Ale żeby to było jak najbardziej zbliżone do tego, jak ten produkt ma funkcjonować, bo bez tego po prostu ma to mniejszy sens i jest większy ryzyko błędów.

Marta: Bardzo dobrze to podsumowałaś. Można się tym zaopiekować…

Ilona: Nawet trzeba.

Marta: Trzeba się tym zaopiekować. Jeszcze chciałam powiedzieć o sytuacji, gdzie czasem jest tak, że jeszcze później… My dostajemy teksty np. na makiety, które są za długie.  Nie jest to fajnie, ale jeszcze nie jest najgorzej…

Ilona: Ale możemy się tym zająć wtedy, prawda? Bo jesteśmy w trakcie zmian.

Marta: Natomiast chyba najgorzej jest, kiedy my oddamy makiety z jakimiś tekstami, które są sugerowane, że mają takie być, a potem jest wlany tekst zupełnie niezależnie od tego już przez programistów.

Oni nie zwrócą uwagi, że jest kilka razy dłuższy i nagle przycisk nam spada, nie widać go już tam, gdzie go miało być widać. Generalnie są problemy z tym i jest to coś, co potem jest trudno nawet wychwycić, że ten błąd wynikał ze złych tekstów, czy zdjęć, czy filmów.

Co to jest design system?

Ilona: Został nam ostatni błąd, który sprawia, że wdrażanie designu jest problematyczne, wydłuża się albo gdzieś tam napotykamy trudności, a mianowicie brak systemowego podejścia do designu i w skrócie brak design systemu.

Rozmawialiśmy o design systemie w jednym z naszych podcastów, też podlinkujemy. Podcast nosi wdzięczną nazwę Bałagan w produkcie, jak go opanować. No i już sam, sam ten tytuł podcastu, gdzie rozprawialiśmy się z design systemem, tłumaczy, o co chodzi.

Przechodząc do samej definicji — brak takiej biblioteki komponentów, czyli takiego jednego źródła prawdy, gdzie mamy pokazane wszystkie teksty (mam na myśli typografię), wszystkie pola tekstowe, pola tekstowe, wszystkie drobniejsze elementy typu checkbox, karuzela, przycisk…

To jest wszystko w jednym miejscu i jest to taka nasza referencja i z tego design systemu pobieramy komponenty, z których później budujemy pudełkowo interfejs już docelowych ekranów. 

I mając takie jedno źródło prawdy, Ty jesteś w stanie w swoim produkcie czy usłudze trzymać porządek. No bo bez tego nie ma systemowego podejścia do budowania nowych interfejsów.

Problemy wynikające z braku design systemu

Marta: Tak, to brak myślenia o tym i brak tego w produkcie powoduje bardzo dużo problemów po wdrożeniu, bo te interfejsy są niespójne. Czasem jest tak, że jakiś podobny element w jednym miejscu wygląda tak, a w innym miejscu wygląda inaczej. 

I to może budzić niepokój u naszych użytkowników, którzy przechodzą przez stronę… Oni przechodzą płynnie jakąś tam ścieżkę i zaczynają sobie myśleć, że tutaj, kurczę, coś wyglądało wcześniej tak, teraz wygląda tak, czy ja jestem na pewno na dobrej stronie? 

Czasem się zdarza, że gdzieś tam klikniemy i coś nam się otwiera w nowej karcie przeglądarki. I wtedy, kiedy to zaczyna wyglądać inaczej niż to, co było wcześniej, no to użytkownik traci zaufanie i pewnie nie kupi albo nie zapłaci. 

To też powoduje niespójność pracy zespołów. Jeżeli mamy kilku projektantów, to fajnie by było, żeby to, co wychodzi spod ich rąk, jednak wyglądało, jakby było spod jednej ręki.  Taki design system pozwala nam na to, żeby to, co oni robią niezależnie od siebie, na przykład różne kawałki systemu, jednak wyglądały tak samo. 

To usprawnia ich pracę, pracę wdrożeniową i właśnie daje ten efekt spójności na koniec, o którym mówiłam przed chwilą. Czyli ktoś się nie gubi w naszym produkcie.

Ilona: Tak, a jeszcze, żeby zrobić nawiązanie do innych punktów… posiadanie design systemu skutkuje tym, że robimy szybciej prototypy.

Marta: I w ogóle szybciej się udaje projektować. I to jest taka praca, którą warto wykonać na początku projektu, kiedy już mamy jakiś kierunek wizualny np. w nowym produkcie, to zbudować sobie ten design system. 

On może być na początku zbudowany z mniejszej ilości elementów. Każdy projektant, z którym będziecie pracować, pomoże wam wybrać, które elementy muszą być na początku, które można rozwijać w trakcie. 

Natomiast to jest takie przygotowanie sobie dobrego zestawu klocków, z których będziemy budować. Te klocki też potem są okodowywane, czyli programiści też korzystają już z takich prefabrykatów, powiedzmy, więc to ich pracę też przyspiesza i u nich nie powoduje też błędów. Nie powoduje tego, że system działa inaczej w różnych miejscach.

Błędy przy wdrażaniu design produktu: podsumownie 

Ilona: Cały czas ta metafora budowlana się nas trzyma. Teraz porównałyśmy design system do prefabrykatów, co w sumie jest fajnym nawiązaniem, bo ostatecznie ten nasz produkt to jest nasz dom, do którego zapraszamy użytkowników. 

Chcemy, żeby nasz biznes rósł, więc wszystkie te elementy, o których powiedziałyśmy i próba zaopiekowania się nimi w Twojej firmie może tylko przynieść korzyść. Jak to mówią same plusy, zero minusów. 

Bardzo Ci dziękuję Marta, że przyszłaś jeszcze raz do naszego podcastu i porozmawiałyśmy o tym jak przyspieszyć wdrażanie nowego designu z tej perspektywy projektowej, a nie koniecznie koderskiej, chociaż też otarłyśmy się o ten temat. 

W tym odcinku porozmawiałyśmy o:

• problemie braku komunikacji i dobrego PM-a
• nierobieniu testów z użytkownikami
• braku prototypowania
• braku wlewania finalnych treści do naszych produktów, makiet
• zatrudnianiu grafika zamiast zatrudnianiu UX designera albo UI designera
• braku myślenia systemowego o naszej warstwie graficznej w naszym produkcie 

Bardzo dziękuję za tę rozmowę, a Ciebie słuchaczu i widzu zachęcam do podzielenia się może swoimi przemyśleniami dotyczącymi wdrażania designu. Bardzo dziękuję.

Marta: Bardzo dziękuję za zaproszenie.