Ta rozmowa pojawiła się na kanale wieki temu, ale dopiero teraz mam zrobione napisy i transkrypcję, więc wrzucam. Jeśli nadal jej nie widzieliście, to zachęcam do odsłuchania lub przeczytania – jest naprawdę niezła i odpowiada na pytania związane ze współpracą na linii projektanci – developerzy.
Gość spotkania
Adam Romański – Znany za sprawą kanału Youtube Hello Roman, sam siebie nazywa kreatywnym frontendowcem – zanim zaczął pracować w IT, przez kilka lat był copywriterem. Na swoim kanale dzieli się wiedzą i spostrzeżeniami, z nadzieją że pomoże to innym w odkrywaniu fascynującego świata programowania.
Błędy UI designerów we współpracy z programistami – zapis rozmowy
NB: Adam Romański, znany bardziej jako Roman z kanału Hello Roman. Cześć!
AR: Hello, siema!
NB: Jak mam do Ciebie mówić: Adam czy Roman?
AR: Roman.
NB: Będziemy rozmawiać o tym trochę jak to wygląda, jak się już tam zaprojektuje ten UI i co się potem z tym dzieje? A może też zanim się zaprojektuje ten UI coś się dzieje?
A chodzi właściwie o to co się dzieje między projektantami a developerami i tej takiej relacji, zawodowej oczywiście, między naszymi zespołami. Pogadamy o tym na co zwrócić uwagę, czego się wystrzegać. Może jakieś tutaj złote rady Roman nam sypnie z rękawa – czego jako projektanci nie powinniśmy na pewno robić, żeby się na nas programiści nie obrazili.
Ja tutaj widzę, że już wpadło w ogóle pierwsze pytanie i to takie, wiesz, konkret. Od Kacpra. Ale wydaje mi się, że trochę dzisiejszy temat będzie właśnie tego dotyczył. Więc ja pozwolę sobie nie zadać tego pytania. I zaraz będziemy przechodzić przez te wszystkie rzeczy, bo to nie jest pewnie odpowiedź tak po prostu na dwie minuty. Ale zanim jeszcze przejdziemy do tego „mięsnego” tematu to ja jeszcze tutaj chciałam heheszkowo zagadać. Bo kilka lat temu było bardzo popularne takie określenie, że się cięło layouty – że się robi projekt: ja robię ten projekt w Photoshopie albo w innym, magicznym narzędziu i oddaję projekt do cięcia developerowi.
No i właśnie pytanie: czy dalej się tnie layouty? Co to właściwie oznaczało, że się cięło layouty i czy nadal możemy tego określenia używać? Czy to jest pro czy już niespecjalnie?
AR: Wydaje mi się, że to się wzięło od tego, że w Photoshopie miałaś ten „slice to” – taki, który wyglądał jak ten nożyk. Brało się tego png’a czy tam jpg’a i po prostu zaznaczało się kolejne fragmenty. Była nawigacja, był ten side bar, to wszystko. Na podstawie tych wyslice’owanych elementów później się eksportowało te małe png’i, które się wrzucało na chama do HTML’a i to się jakoś tam sklejało. Wydaje mi się, że stąd wzięła się… Wziął się ten termin cięcia layoutu, który w dzisiejszych czasach już bardziej, jeśli już w ogóle jest używany, oznacza bardziej po prostu przełożenie layoutu, który dostajemy od designera do CSS i do HTML’a, więc ja np. nie używam tego określenia, bo jest one dość nieprecyzyjne. Jest właśnie… Wywodzi się jakby z przeszłości, już nie ma nic za bardzo ten proces z cięciem layoutu w żaden sposób. Jest po prostu wdrażanie layoutu, więc tak.
W ogóle jeśli dostałbym dzisiaj projekt w Photoshopie to bym odszedł z projektu.
NB: To wiesz co? Okrutne, naprawdę.
AR: To nie jest program do takich rzeczy. To nie jest program stworzony do projektowania stron i po prostu jest mega niewygodny. Ale tak. Więc myślę, że stąd się wzięło cięcie layoutu. Faktycznie to określenie funkcjonuje nadal, choć moim zdaniem jest nieprecyzyjne i nie powinniśmy go używać. No chyba, że ktoś używa Photoshopa i faktycznie używa slice tool’a jeszcze.
NB: Myślę, że z Photoshopem już można Zeplin’a używać, więc to już by było takie trochę przegięcie jakby się tego slice tool’a…Tutaj Iwona podpowiada, że to się nazywa cięcie na plasterki w Photoshopie. Piękne, polskie tłumaczenie.
A ja się pytam od razu czatu czy ktoś jeszcze pamięta te wspaniałe, piękne czasy kiedy się cięło layout w Photoshopie i czy mieliście okazję ciąć na plasterki taki projekt, żeby wdrażać go później pociętego w jakieś strony na tabelkach. Piękne czasy, które już mam nadzieję minęły. No właśnie…
AR: W gimnazjum to robiłem.
NB: No – podstawówka, gimnazjum to było mniej więcej, nie – ten moment kiedy się to robiło. Lata młodości piękne.
No cóż… No dobra. To jeszcze drugie pytanie takie miałam, heheszkowe, żeby się pośmiać na dobry początek: czy to prawda, że nieważne co sobie zaprojektujemy jako projektanci, bo i tak programista albo programistka później siądzie do tego i w sumie zrobi po swojemu, walnie jakiegoś bootstrapa i powie, że się nie da? Czy to faktycznie tak działa albo zdarza się jeszcze? Bo macie słaby PR, to ci powiem, że generalnie developerzy wśród projektantów chyba mają dosyć słaby PR i pewnie w drugą stronę też to trochę działa.
AR: Designerzy też mają słaby. Zawsze coś tam wymyślacie, utrudniacie życie tylko. Generalnie jest tak, że istnieje faktycznie duża grupa developerów, która lubi frameworki UI, czyli właśnie bootstrapa, materiala, &design np. Jest tego sporo. One są coraz fajniejsze jeśli chodzi o dopracowanie, o elastyczność tych design systemów, tych frameworków, nazwijmy. Więcej jest o tyle spoko. Ja np. bardzo nie lubię z tych narzędzi korzystać i zazwyczaj miałem tak, że jeśli miałem coś wdrożyć, jakiś layout to i tak robiłem to po prostu ręcznie. Nie korzystałem z żadnej biblioteki, ponieważ ostatecznie więcej czasu by mi zajęło dopasowanie tego co już istnieje niż napisanie tego od zera.
Z drugiej strony zaletą tych wszystkich narzędzi jest np. to, że dbają o dostępność, o accessibility, więc jakieś tam rzeczy związane z tabowaniem po elementach itd., to wszystko jest bardzo ładnie obsłużone. Więc ma to swoje plusy i minusy.
Natomiast jeśli chodzi o współpracę z designerem to nigdy nie powinno być tak, że designer sobie coś wymyśli a później developer mówi: „dobra to zrobimy to na Bootstrapie”, bo bardzo często wtedy są jakieś faktycznie odchylenia, bo nie wiem, np. grid bootstrapowy nie zakłada takich odstępów a designer sobie to tak wymyślił i później trzeba i tak kombinować, przesuwać to jakoś na chama. Więc jeśli już dochodzi do takiego momentu, że ktoś chce wykorzystać Bootstrap albo inny framework to powinno się to wydarzyć na etapie designu, bo np. projekt zakłada, że musi być bardzo szybko wdrożony. Trzeba zrobić coś z gotowców, klient np. nie ma hajsu albo chce, żeby to był tylko prototyp i chce żeby to było bardzo szybko zrobione. To są takie argumenty, które zazwyczaj wykorzystywane są żeby przekonać kogoś z zespołu do wykorzystania takiego frameworku. Więc jeśli już korzystamy z takich narzędzi to powinien to designer najpierw wziąć. Są np. w Figmie gotowe paczki, które mają wszystkie komponenty już gotowe do wykorzystania. Posklejać z tego ten layout i później przekazać to developerowi. Wtedy każdy ma ułatwione zadanie i wtedy faktycznie to idzie szybko, bo jeśli nie ma tej synchronizacji między designerem a developerem to ostatecznie albo designy będą źle wdrożone, albo będzie to po prostu bardzo wolno szło.
Bo ta customizacja, to dopasowywanie tego frameworka to będzie mordęga.
NB: Bo to też chyba będzie zależało od tego jak w ogóle współpracuje się na linii design i development, bo tutaj może być kilka rodzajów tej współpracy, prawda? Z jednej strony mówisz, że fajnie by było pogadać na początku i ustalić te rzeczy, ale też nie zawsze jest tak, że ten designer i developer mogą w ogóle rozmawiać ze sobą na początku.
Opowiesz trochę o tych różnych wariantach współpracy – jakie są w ogóle takie, z którymi się spotykasz lub z którymi się spotkałeś?
AR: Tak. To znaczy w rzeczywistości takiej jak np. nie wiem, pracowałem w Netguru i mieliśmy jakiś projekt to idealną sytuacją zawsze jest ten moment kiedy designer i developer wchodzą do projektu razem, i po prostu gadają, ustalają pewne rzeczy, współpracują. Designer feedbackuje developera i odwrotnie. A raczej na początku developer feedbackuje designera co można zrobić, żeby było np. szybciej, prościej i bardziej dostępnie. Jeśli developer ma w ogóle taką wiedzę, bo zazwyczaj to jednak designer się tym zajmuje, ale ta wymiana tych informacji czasami naprawdę rodzi fajne dyskusje i fajne rozwiązania.
Problem jest tylko taki, że bardzo często bywa tak, że klient np. nie chce, żeby developer wszedł od razu z designerem do projektu, no bo będzie musiał płacić hajs od samego początku a developer tak naprawdę na początku tej roboty za dużo nie będzie miał. Chyba, że sobie to w projekcie jakoś tak poukładają, że na początku logika biznesowa a później implementacja komponentów. Można to jakoś tam rzeźbić i rozwiązywać. Nie zawsze się da niestety. Więc to jest taki główny problem, że często ten developer nie jest obecny na etapie
designu i designer rzeźbi sam. Ja i tak zawsze wtedy apelowałem, żeby np. wiedzieć jaki developer zostanie przydzielony do tego projektu, żeby nawet nie pracując jeszcze w tym projekcie, pogadał z tym designerem, bo to jest ich wspólny interes, żeby ten projekt fajnie wyszedł i żeby fajnie się każdemu pracowało. Więc są takie dwa podstawowe scenariusze: albo robią od samego początku razem, co jest super, bo wtedy ta wymiana informacji jest naprawdę natychmiastowa i rodzi bardzo fajne rozwiązania i dyskusje albo wchodzą na zakładkę, ale wtedy fajnie by było też gdyby szukali tych sposobów komunikacji. Jeśli ich nie ma, jeśli designer faktycznie robi wszystko od początku do końca sam i później robi tylko handover tego designu dla developera, no to trzeba zadbać o to, żeby ten handover przebiegł w odpowiedni sposób, żeby po prostu te materiały były dobrze przygotowane.
Bardzo złą sytuacją jest moment, kiedy po handoverze od razu designer wypada z projektu, idzie gdzieś indziej, nie ma nawet możliwości skontaktowania się z nim, żeby coś poprawić: albo żeby zapytać, albo dopasować, albo zaprojektować jakiś komponent w trochę inny sposób, bo X, Y, Z – są jakieś tam argumenty. Więc jest to dość skomplikowana współpraca i fajnie gdyby była dobrze skoordynowana.
NB: Dobra. To ja Cię od razu podpytam o to w kontekście tego pytania co się pojawiło. Bo wyobrażam sobie, że trochę inaczej jest jak masz tę współpracę design–developer, development od razu. Sobie po prostu pogadacie, dogadacie się jakoś, w jakikolwiek sposób, jakimkolwiek narzędziem. Ale jak jest ten handover taki pociachany, czyli najpierw robimy projekt i nagle Ty zostajesz z tym projektem jako developer, i nie masz za bardzo tutaj pola manewru, żeby się albo skontaktować z designerem. Jak wygląda taka Twoja praca wtedy? To jest tak, że Ty te brakujące rzeczy sam sobie wymyślasz, dorabiasz? Jak to działa?
AR: Nie wyobrażam sobie takiej sytuacji, żeby z designerem w ogóle nie było kontaktu. No chyba, że wyleciał z firmy, nie wiem, to był jego ostatni projekt i po prostu… I to był jedyny designer, który coś robił, więc nie ma, wiesz…
NB: Tylko PMi i developerzy zostali.
AR: To jakaś nierealna sytuacja. To w ogóle nie mogłoby się zdarzyć, mam wrażenie, w poważnej firmie, więc tego w ogóle nie zakładam. Jeśli designer odszedł do innej firmy to pewnie jakiś inny designer jest gotów, żeby coś tam podpowiedzieć, pomóc.
Natomiast, tak jak mówię, tutaj w pytaniu Kacpra najważniejszy jest handover. Handover to nie jest tylko spotkanie developera i designera, i obgadanie co jest gdzie, ale też przygotowanie odpowiednio plików. Przygotowanie np. nie wiem – jeśli są tam animacje to wyeksportowane to do odpowiednich formatów na zasadzie MP4 np. żeby widzieć jak ta animacja ma wyglądać, nie tylko sztywne obrazki statyczne, tylko też jak ten ruch ma się zachowywać na stronie. Ja np. dostawałem od jednego z designerów nawet easingi do animacji, jak ma wyglądać easing danej animacji na takim fajnym wykresie, więc to już były takie bardzo zaawansowane rzeczy, które niesamowicie ułatwiają developerowi pracę, ale też przede wszystkim sprawiają, że developer jest w stanie odzwierciedlić to, co designer miał na myśli, bo o to w tym wszystkim chodzi.
Desingerom chyba najbardziej, ale prawda jest taka, że czasami bywa tak, że designy były piękne a implementacja wygląda okropnie i nie zawsze jest to wina developera.
Czasem jest to również wina…
NB: Powiedz to. Wina projektanta, tak?
AR: Albo np. źle przygotował handover, niechlujnie i po prostu o wielu rzeczach zapomniał.
Np. bardzo ważną rzeczą, której czasami nie dostawałem od designerów są stany poszczególnych komponentów, czyli dobra – mamy imput, ale jak imput wygląda pusty, pełny, jak wygląda kiedy jest błąd, co tam się z nim dzieje, nie? To są niesamowicie ważne rzeczy, o których czasami się zapomina. Więc to wszystko powinno zostać zawarte w handoverze.
NB: Dobra. Myślę, że do tych takich rzeczy, które robimy i sobie przekazujemy, i w ogóle narzędzi, w których to możemy zrobić to jeszcze w trakcie rozmowy wrócimy. A tym czasem się pojawiło pytanie od Tomka: „Jestem designerem i tworzę aplikację mobilną, tworzę prototyp w Adobe XD, żeby dyrektora miał coś do pokazania zarządowi.” Wiadomo po co się robi.
„Jeśli będzie akcept sprawa pójdzie do developera i co później?” To chyba zależy od tego jak w ogóle wygląda proces pracy w firmie.
AR: Struktura firmy, nie? Raczej to nie trafi do developera tylko powinna trafić do zespołu projektowego, który później zdecyduje co dalej, bo… Czym jest ta aplikacja? Czemu ma służyć? Jaki jest scope tej aplikacji? Czy tworzysz prototyp tylko jakiegoś wycinka tej aplikacji czy tworzysz prototypy całej aplikacji? Jeśli tak, jeśli już jest na tak zaawansowanym poziomie to czy możemy z tego stworzyć jakiś backlog tasków, jakieś stories np. user stories czy user journey, które później można przełożyć na mniejsze zadania, które developer będzie mógł implementować? Pytanie czy pracujecie w Scrumie?
Nawet to już są takie podstawowe rzeczy, ale proces tego jak to będzie wyglądać bardzo zależy od tego jak funkcjonuje firma. Jeśli to jest małe studio, które nie ma procesów poukładanych to może faktycznie tak jest, że przychodzi designer do developera i robimy aplikację. I wtedy siedzicie razem i po prostu pewnie z pomocą jakiegoś project managera czy kogoś będziecie to wdrażać. Ale ciężko odpowiedzieć na to pytanie jakoś bardziej precyzyjnie.
NB: Tak. Dopóki się nie wejdzie w procesy firmowe. Ja myślę, że Ty mówisz też Roman o takich bardzo idealnych procesach trochę, bo pracowałeś w firmie i pracujesz w firmie, która ma to dobrze poukładane i przede wszystkim jest taka dosyć duża świadomość i roli projektowania, i tego jak działa development.
Wyobrażam sobie, że trochę inaczej to wszystko będzie wyglądało kiedy mamy jakiś biznes a ten development i Ci designerzy to oni są tak na doczepkę, bo oprócz jakiegoś tam głównego biznesu, cora, jest jakaś wersja np. nie wiem, sklepu digitalowa, ale tak naprawdę najważniejsze są sklepy stacjonarne. I wyobrażam sobie, że w takim scenariuszu łatwo jest mieć sytuację gdzie właśnie jest jeden designer, jeden developer i robią sobie rzeczy.
Tak naprawdę jest jeden wielki dług technologiczny i po prostu się coś tam dłubie na bieżąco. Więc to pewnie też będzie zależało od tego jak to wygląda w firmach różnych.
Ja jestem ciekawa. Dużo jest nas na czacie to dajcie znać w ogóle jak to u Was wygląda.
Czy to jest, tak że macie właśnie duże struktury i całe zespoły developerskie i projektantów? Czy raczej jesteście „one man army” i próbujecie jakoś to wszystko połatać? Bo to mnie zawsze bardzo ciekawi.
No i Ty teraz, Roman, pracujesz dla zagranicy to też jest trochę inaczej pewnie, co?
AR: Porównując strukturę organizacji i jakieś takie ogólne ogarnięcia pracy to akurat mam to szczęście, że Netguru jest bardzo podobne do Hotjar’a, więc… Tak myślę i to jest całkiem spoko. Tam mi się fajnie pracowało też, więc nie odczuwam jakiejś ogromnej różnicy. Po prostu przywykłem, jestem rozpuszczonym devem i przywykłem do poukładanej firmy.
NB: Tak to jest właśnie z Wami.
No dobra. To ja przejdę do kolejnego pytania, bo jestem bardzo ciekawa jak to wygląda w momencie kiedy jeszcze nie przechodzimy do tego momentu, kiedy już jest zrobiony design tylko jeszcze zanim ten design zrobimy.
Czyli tak: wyobrażamy sobie ten taki idealny scenariusz kiedy mamy developera i projektanta w jednym miejscu i zaczynamy pracować. Teraz wyobraźmy sobie, że przychodzi taki junior projektant, który będzie wdrażał swój… Będzie projektował, właściwie tworzył swój pierwszy projekt. Jak to zrobić dobrze? Jakby ktoś taki Cię spytał „od czego zacząć, żeby w momencie kiedy ja zaczynam projektowanie zrobić to tak, żeby ten development przeszedł w miarę gładko i żeby nie narobić sobie tych wszystkich problemów? Czego unikać albo na co zwrócić szczególną uwagę?” to co byś poradził takiej osobie?
AR: Jeśli to jest junior designer i mam nadzieję, że developer jest doświadczony przynajmniej w tym zespole, bo jeśli to jest dwójka juniorów to krzyż na drogę.
NB: Załóżmy, że developer jest już wiesz… Że jest Roman. Że Roman poleca.
AR: Nie wiem czy jestem dobrym akurat tutaj egzemplarzem, ale… Myślę, że fajnie by było, gdyby developer wtedy przygotował taką listę rzeczy o której designer powinien pamiętać.
Nawet może być to lista fuckupów z poprzednich projektów np. co zrobił designer X w jakimś tam projekcie, co sprawiło, że było to trudne do wdrożenia. I moimi takimi przykładami, którymi się posługuję czasami jest np. dbałość o eksportowane pliki. To znaczy: miałem designera, który był z Niemiec i dostałem ikony do aplikacji, które były w języku niemieckim. W sensie nazwy ikon były po niemiecku i najdłuższa nazwa pliku miała 32 znaki. Weź to teraz zaimportuj w kodzie i się nie pomyl. To jest w ogóle niemożliwe, więc pierwsze co zrobiłem to Google Translate i po prostu każdą ikonę tłumaczyłem na angielski, bo jeszcze tam nie było nawet tych myślników. Chociaż możliwe, że jeśli to niemieckie słowo to faktycznie…
NB: To mogło nie mieć.
AR: Więc potłumaczyłem to, ale zajęło mi to dobre kilka godzin, żeby potłumaczyć te ikony i to jest jeden z takich absurdalnych przykładów, które nigdy się nie powinien zdarzyć. No ale designer z Niemiec mi tak zrobił, więc jakby… To jest tylko przykład oczywiście i to taki dość skrajny, ale generalnie eksportowane materiałów dla developera typu obrazki, ilustracje, które powinny być pngami albo svg, jeśli są takie bardziej wektorowe, animacje, jeśli np. korzystacie z Lottie to w jsonie, żeby były ładnie już wyeksportowane. Mnóstwo jest tych zasobów, które powinny być ładnie wyeksportowane. Favicony, które developer powinien posiadać, czyli nie tylko mamy logo, ale mamy też favicony w odpowiednim formacie i mamy w odpowiedniej wielkości. Tam jest chyba 64, 128, 200 coś tam, 512 itd.
Więc to są takie rzeczy, o których bardzo często designerzy nie pamiętają, bo jest to rzecz bardzo związana z tym jak działa aplikacja wewnątrz przeglądarki np. działanie favicony itd.
Ale o których trzeba pamiętać, bo inaczej bywa tak, że developer jest później zdany sam na siebie i musi, nie wiem, rzeźbić z logo svg sam te favicony. Fajnie gdyby to było jednak dostarczone przez designera.
To jest jedna rzecz, czyli pliki. Druga rzecz to taka świadomość tego jak działa przeglądarka i jak działa renderowanie rzeczy w przeglądarce, bo np. miałem kiedyś takie sytuacje, że na jednej szerokości miałem menu w tym miejscu a jak się trochę zwężyło ekran to się pojawiało w innym, ale część tego menu była na górze a część była na dole. To się w ogóle rozsypywało. I dla developera to jest o tyle problematyczne, że to nie jest jedno menu, które po prostu zachowuje się w dziwny sposób. Nagle Ci się robi pięć różnych komponentów, które są tym samym menu tylko wyświetlają się na różnych rozdzielczościach. Więc fajnie, żeby to było spójne i jeśli istnieje jakaś bardzo silna potrzeba, żeby to rozbić na dwie części – spoko, ale niech to będzie jakoś uwarunkowane, uargumentowane przez designera a nie po prostu „bo tak mi ładnie wyglądało na widokach”.
Akurat w tamtym przypadku tak było i udało mi się przekonać designera, żeby to trochę uspójnić, bo robił się po prostu bałagan w kodzie ogromny. Więc implementacja takich,
ja to nazywam „layoutami niemożliwymi”, czyli takie, które są naprawdę problematyczne i robią mnóstwo problemów w kodzie później i też związanych nawet z wydajnością tego kodu później.
To są rzeczy, których designer powinien unikać. Jeśli nie wie jak coś zaprojektować albo ma wątpliwości czy to będzie proste czy trudne to fajnie gdyby zapytał developera. Więc ta komunikacja jest mega ważna.
NB: Ja Cię jeszcze o takie problematyczne rzeczy podpytam później, bo mam takie pytanie na mojej liście. Ale tutaj widzę, że są pytania od Pawła i to jest też takie pytanie, mam wrażenie, dobre na początek. No bo jak my zaczynamy pracę to my musimy sobie założyć jakąś rozdzielczość, od której zaczniemy. Większość narzędzi tego od nas po prostu wymaga.
Więc tu jest pytanie od Pawła: „Na ile breakpointów przygotować projekt – czy wygodniejsza z punktu widzenia deva jest duża ilość artboardów czy raczej porządnie opisane zachowanie elementów w RWD?”
AR: Zastanawiam się jak można porządnie opisać zachowanie elementów w RWD. To znaczy myślę, że część na pewno można. Nawet nie na całym artboardzie tylko np. menu wyciągnąć do jakiejś mniejszej części i pokazać jak ono się zachowuje, żeby nie robić tego na kopiuj–wklej po prostu, na 10 artboardach różnych szerokości.
Natomiast jeśli już dostawałem designy to zawsze potrzebowałem wersji mobilnej i desktopowej. To jest taki must have. Po prostu jak nie ma mobilek to designer się cofa i idzie robić po prostu. Bardzo ważny jest też tablet, którego często brakuje i bardzo ważny jest też duży ekran, którego też bardzo często brakuje.
Czasami jest tak, że strony są pięknie zaprojektowane na wielkości laptopów a później jak odpalasz to na 27–calowym ekranie to wygląda jak… Brakuje tego takiego… John’a Travolty co tak się obraca. Co się dzieje? Gdzie jest reszta layoutu?
NB: Gdzie jest reszta strony? Bo albo się maksymalnie rozciąga po całej szerokości ekranu, albo jest cały czas taki bardzo wąski pasek, który po prostu do pewnego momentu się nie powiększa i masz takie ciupeńkie literki, bo generalnie wszystko zostało na tej rozdziałce laptopowej. No dobra.
AR: Jak przeglądasz nawigację po prostu, tak wiesz.
NB: Wyobrażam sobie, że to jest też kwestia ceny, nie? W zależności od tego czy mamy projektantów i developerów, którzy pracują w produkcie i są na stałe po prostu przypisani gdzieś, tak jak Ty teraz masz. No to raczej tam dużo łatwiej jest usiąść projektantowi i cisnąć te wszystkie widoki kiedy są po prostu na stałe w projektach. Trochę inaczej to pewnie wygląda w takim trybie agencyjnym czy freelancowym, że po prostu projektant jest na jakiś czas albo na jakiś zakres prac.
No i teraz wyobrażam sobie, że często będzie taka sytuacja gdzie developer dostanie właśnie samą mobilkę i jakiś tam desktop: czy to będzie ten mniejszy czy większy to już pewnie będzie zależało. Jak to potem wygląda? Czy Ty sobie sam wyobrażasz jak mają wyglądać te kolejne break pointy? Czy jak wygląda wtedy taka praca developera? Co tam się dzieje?
AR: Zdarzały się sytuacje kiedy musiałem sobie to po prostu sam jakoś dokleić, bo nie było jak zapytać. Natomiast jeśli nie wiem jak coś ma wyglądać na dużym ekranie to nawet nie musi być tak, że wszystkie layouty, które istnieją, wszystkie widoki, które istnieją muszą być przełożone na ten duży ekran. Wystarczą dwa na przykład, które pokazują część komponentów i resztę sobie możesz wyobrazić po prostu, jakoś to zrobić. Więc to nie jest jakiś duży nakład pracy dla designera stworzyć dwa dodatkowe artboardy, żeby coś zaprezentować. Więc myślę, że to jest taki quick win, który można zastosować, żeby faktycznie każdy był zadowolony i jeśli tego nie ma to chociaż kontakt do designera na zasadzie: „ej, zrobiłem coś takiego. Powiedz mi czy to wygląda ok czy może chciałbyś, żebym to zrobił inaczej.”
NB: Spoko. To jest fajne, bo trochę zapominamy o tym, że w sumie projektując stronę często mamy te powtarzalne komponenty i elementy, które będą zachowywać się w podobny sposób, więc to jest kwestia zrobienia kilku tych komponentów czasami w takiej wersji na różne szerokości.
Tu jest jeszcze jedno pytanie od Pawła: „Jak przygotować projekt w Figmie z dużą ilością art boardów tak, żeby developer sprawnie poruszał się między widokami?” Myślę, że to będzie pewnie pytanie do każdego programu, który działa na podobnej zasadzie, czyli jest ileś tam page’y, art boardów i dużej przestrzeni, gdzie tych projektów jest masa wrzucone.
Masz jakieś takie idealne rozwiązanie, które bardzo lubisz?
AR: Z tego co pamiętam, bo już dawno nie robiłem nic takiego, w sensie, na takich większych projektach, gdzie było aż tyle widoków. To chyba pamiętam, że najbardziej mi się podobało kiedy miałaś po prostu osobne strony w Figmie, w sensie po lewej tam – przełącza Ci po prostu całe widoki i miałaś mobile, desktop, big desktop itd. To było rozdzielane w taki sposób, że one nie były obok siebie tylko były na innych stronach. Czasami też się robi tak, że masz rt board i później masz z prawej, na przykład, jeszcze tablet, mobile itd., że są obok siebie. To też jest wygodne, więc to są takie dwie rzeczy. Myślę, że nie ma uniwersalnych zasad. Jednemu będzie to się bardziej podobać, drugiemu to, sle to już jest taki detal. W sensie najważniejsze, żeby one były a gdzie one będą to już sobie tam developer poradzi. Najwyżej trochę poszuka.
NB: Żeby były dobrze opisane, bo ja mam takie doświadczenia, że bardzo łatwo pogubić np. w projektach, które są in progress a które są już do developmentu, żeby to było też dobrze opisane. Bo ja się też z bardzo różnymi typami opisów i przygotowania plików spotkałam.
Dużo będzie zależało od wielkości projektu i tego ile tych ekranów tak naprawdę jest, bo np. się spotykam teraz bardzo często z Figmą, która nie daje rady jeżeli chodzi o zawartość pliku. Po prostu za dużo jest artboardów w plikach i trzeba rozdzielać obszary w ogóle na osobne projekty, więc to jest też ciekawe, że przy małych projektach tego się po prostu czasami nie widzi, więc dobrze się zastanowić jak będzie się skalować później taki system uporządkowania plików.
AR: No ale to w Figmie się nie odpali a w Sketchu się odpali? Jak Sketch, już te późniejsze wersje, był tak wolny. Pamiętam, że on był kiedyś taki super szybki.
NB: A nie wiem, bo ja nie odpalam tego… W sensie nie odpalałam tego… Ten przykład z tą masą artboardów mam akurat z Figmy, nie porównywałam tego. Ale ze Sketchem nigdy nie miałam problemów, szczerze mówiąc. Nie pamiętam, żebym miała problem. Ale też mam wymaxowane zawsze komputery pod tego Sketcha, więc to chyba ma znaczenie. Więc pewnie będą różne doświadczenia w zależności też od sprzętu i właśnie wielkości tych plików.
O, to jest fajne pytanie. Ja sobie pozwolę je przerzucić od razu, od Łukasza: „Czy możliwe jest ogarnianie na dobrym poziomie designu a potem programowania? Czy jest to zbyt kosztowne i czasochłonne?” Roman, czy Ty czujesz się designerem?
AR: Nie, co Ty.
NB: Nie chcesz?
AR: To znaczy…
NB: Trochę jesteś.
AR: Potrafię jakieś tam super proste rzeczy zaprojektować, ale do bycia designer mi bardzo daleko. Ale są tak zwani, to się chyba nazywa unicorn developer albo unicorn designer, który potrafi nie tylko zaprojektować, ale i wdrożyć. Mam faktycznie jednego takiego kolegę. On akurat w JSie aż tak dużo nie pisze, ale jeśli chodzi o jakieś takie proste landingi np., to potrafi je bardzo pięknie zaprojektować i później je wdrożyć z bardzo fajnymi animacjami. Więc istnieją takie osoby. Pytanie co nazywamy programowaniem i developmentem.
Bo jakby wydaje mi się, że jeśli projektanci potrafią kodzić to zazwyczaj ogranicza się to do implementacji interfejsu. Ale jakbyś dała im do zrobienia aplikacje Reactową np., jakąś skalowalną to byłby problem, bo to już wymaga bardzo dużej wiedzy o JavaScript. Więc to jest takie rozgraniczenie. Też myślę, że na frontendzie istnieje taka dyskusja i ciągle się ona toczy: czy to już się podzieliło? Czy mamy świat, nazwijmy to CSS developerów i JS developerów? Ja się z tym nie zgadzam i nie lubię takiego szufladkowania, bo ktoś się może przez to poczuć gorzej.
Myślę, że nie można być ignorantem po prostu będąc frontendowcem i pogodzić się, z tym że jest to bardzo inter…
Brakuje mi słowa. Interdyscyplinarna dziedzina, tak. Ale mądre.
NB: Mądre słowa dzisiaj na live, kurczę. O tej godzinie? Nie spodziewałam się, ale życie przynosi zaskoczenia każdego dnia, w każdej chwili.
U nas też jest taka dyskusja, że właśnie pytanie: Czy designer powinien kodować? Czy designer powinien umieć programować i co jest live jakiś właśnie o UI to jest to pytanie magiczne. Czy ten designer powinien umieć w ten development? Ja zakładam, że fajnie wiedzieć o co chodzi, nie? Czym Wy się zajmujecie, żeby się dogadać.
Jak to z Twojej perspektywy wygląda?
AR: Tak samo jak mówię frontendowcom, że nie powinni być ignorantami np. rozumieć, nie wiem, mniej więcej chociaż jak działa dobieranie kolorów. Dlaczego coś sprawia, że coś wygląda dobrze albo źle, wyrabiać sobie to poczucie estetyki, uczyć się tego trochę, uczyć się o UXie, o dostępności, o takich rzeczach związanych trochę bardziej z Waszą dziedziną, ale dostępność finalnie i tak zależy od developera, więc trzeba się po prostu tego uczyć.
Ale to są takie rzeczy z pogranicza nazwijmy to i nie można być na to obojętnym po prostu, jeśli godzimy się z tym, że chcemy być frontendowcami to nie ma bata i po prostu trzeba się za to wziąć. I tak samo uważam, że jeśli designer, nie wiem, jak masz DTPowca, który robi plakaty np. projektanta, który tworzy bardziej pod druk no to on się zna na tym jak działają te maszyny i jaki kolor Ci wydrukują itd. I tak samo jeśli designer tworzy dla sieci no to fajnie, żeby rozumiał jak działają urządzenia mobilne i przeglądarka internetowa.
NB: Patrząc na to jak rozwijają się też narzędzia do projektowania myślę, że warto być na bieżąco, bo coraz częściej te narzędzia projektowe mają możliwość albo częściowo w ogóle dodawania kodu czy rozbudowywania naszych projektów, prototypów o tą część właśnie związaną z kodowaniem i to też ułatwia pracę. Teraz bardzo popularne jest chociażby Webflow. Nie wiem jakie Ty masz podejście do takich no code, tych wszystkich narzędzi do tworzenia prostych stron, czasami bardziej nawet skomplikowanych. Ale to też pokazuje, że warto się tego kodowania chociaż w takiej podstawie nauczyć.
AR: Mimo wszystko, jakby nie rozumiejąc CSS’a nie zrobisz nic w Webflow, bo on wymaga od Ciebie tego. Tam wszystkie parametry, które możesz ustawić są typowo CSSowe. To jest tak jakbyś pisała tego CSSa tylko zamiast pisać go, wyklikujesz. Ale i tak musisz zrozumieć czym jest pading, czym jest margin, czym jest flex np. itd. Bez tego nic w Webflow nie zrobisz i akurat z tych wszystkich narzędzi, które istnieją typu Wix np. itd., których nie lubię – to jest takie… To zawsze wypluwa jakieś babole. To akurat Webflow jest porządnym narzędziem. Jeśli ktoś wie co robi to naprawdę można tam bardzo szybko fajne rzeczy wyklikać, także nie hejce. Sam nie używam, ale nie jestem hejterem takich rzeczy.
NB: Dobra. To jeszcze wrócę do tego tematu uczenia się kodowania. Bo jeżeli załóżmy, że jest projektant czy projektanci, którzy chcieliby się trochę podszkolić w tych tematach fronendowych to co byś polecał takim osobom? Czy chwycić się za ten kurs HTML i CSSa czy może jakoś inaczej do tego podejść, żeby zrozumieć czym się zajmujesz?
AR: Kurczę, fajnie by było zrobić kurs dla designerów.
NB: Może trzeba zrobić.
AR: Może trzeba. Mało kodowania a dużo takiej właśnie teorii związanej z tym jak to po prostu działa – żeby to skumać, ale niekoniecznie potrafić napisać. Myślę, że to by wystarczyło.
Ale jeśli już ktoś szuka tego typu rzeczy no to fajnie jak sobie zrobi chociaż jakieś podstawy HTML i CSSa gdziekolwiek. freeCodeCamp np. ma bardzo fajne rzeczy darmowe, ale tych materiałów jest mnóstwo. Unikałbym rzeczy typu Codecademy np., które skupiają się bardziej na składni, tego jak pisać CSS np. Dla designera to nie jest jakoś super istotne, żeby pamiętać przez całe życie później jak się pisze np. właściwości dla flexboxa. Ale fajnie, żeby rozumiał jak ten flexbox działa albo np. jak g działa w CSSie. To są takie rzeczy, które fajnie skumać. Niekoniecznie trzeba umieć je później napisać.
NB: Ja tu mam komentarz odnośnie Twojego pomysłu. To jest właśnie tak: jak zapraszacie Romana na live’a, on wam próbuje opchnąć jakieś produkty i zarobić na Was hajs. To jest w ogóle szczyt. To może przypomnijmy jeszcze ten kod na notesy jak już tutaj jesteśmy.
AR: Nie no, nie będę tak po chamsku tutaj reklamy robił.
NB: Są linki w opisie. Tak przypominam tym, którzy dopiero do nas dołączyli – tam jest między innymi sklep romanowy z notesami. Możecie wpadać, są promki.
Ja wrócę do tego tematu. Pytałam na Instagramie u siebie z kolei czy są jakieś pytania, które ktoś chciałby Ci zadać a niekoniecznie będzie dzisiaj na spotkaniu i padło fajne pytanie pod kątem tego właśnie projektowania a nie myślenia trochę jeszcze o developmencie.
Czy są jakieś takie rozwiązania, które są super, wyglądają fajnie, są przekozackie, są teraz super modne, trendy, wiesz… Trendy 2021 UI/UX, które są super problematyczne we wdrożeniu i wiesz, że jak ktoś Ci po prostu coś takiego dostarczy to np. nie chcesz tego robić? Czy jest w ogóle coś takiego? Są takie rzeczy, na które powinniśmy zwracać uwagę szczególną jak projektujemy?
AR: Chyba najbardziej debilnym rozwiązaniem jakie pamiętam to jest scrollowanie w bok. To znaczy, że masz jakąś sekcję, która nagle kradnie ci scrolla i zaczyna… Nie możesz się scrollować już w dół, tylko się scrollujesz w bok i dopóki nie zescrollujesz…
NB: To nie możesz albo nie zejdziesz kursorem tam w to miejsce gdzie już nie…
AR: To jest w ogóle jakiś dramat i takich rzeczy nie powinno się robić, więc jestem przeciwnikiem wszelkich rozwiązań, które zaburzają naturalne działanie przeglądarki i porywają użytkownika w taki bardzo nieprzyjazny sposób, że nie pozwalają mu na coś co on chciałby zrobić. Jeśli ja chcę zjechać do stopki np. żeby coś sprawdzić, adres firmy to nie powinienem zapieprzać w bok przez 5 minut.
Także to są takie rzeczy i to bardziej mówię na intuicję teraz, bo nie podam Ci 5 różnych przykładów, ale to jest jeden z takich, które naprawdę irytują i dla developera to też jest takie, że: „Czemu ja to robię? Czemu ktoś mi kazał to zrobić? Cierpię jak muszę to zrobić.”, więc to nie jest fajne. Starajmy się projektując rzeczy robić tak, żeby po prostu dla użytkownika to było też fajne. Wczujmy się trochę w jego rolę a nie tylko myślmy o tym czy coś będzie wyglądać fancy czy nie. Natomiast wszystkie jakieś animacje, paralaksy, lazy loading, wjeżdżanie itd. To są rzeczy, które istnieją, których się używa. Dla developera to jest raczej naturalne, że one się pojawiają. Nie jest to jakiś wielki problem i, o ile są zastosowane w odpowiedniej ilości i po prostu nie jest ich za dużo na stronie, i nie wpływają aż tak bardzo na performance, to są to fajne rzeczy, które ożywiają interfejs, nie?
Pamiętam, że właśnie na stronie głównej Netguru bardzo mi się podobało robić te animacje. Jak się wejdzie, takie są na svg w GSAPie po prostu robiłem, że brałem całe svg i tam animowałem poszczególne elementy i efekt tego uważam jest bardzo ładny. Miałem przy tym mega frajdę też. Było to skomplikowane do wdrożenia, ale niesamowicie przyjemne. Więc to nie jest tak, że developerzy zawsze narzekają, bo coś tam designer sobie wymyślił.
NB: To ja odnośnie tego narzekania jeszcze Cię zapytam, bo czasami może być tak, że designer sobie coś wymyśli faktycznie i że to może mieć negatywny wpływ, nie wiem, na ładowanie treści, na użyteczność. Zdarza się, że ktoś może po prostu coś słabego zaprojektować i wtedy developer powie: „No nie zrobię tego tak albo nie da się tego tak zrobić, albo to byłoby bardzo kosztowne” itd.
A co jeżeli jest tak, że developerzy mówią nam na wszystko, że tego nie zrobią, bo nie. Czy są jakieś takie sygnały, które mogą nam powiedzieć, że po prostu developerowi się nie chce wtedy za bardzo z nami pracować? Skąd mamy wiedzieć czy faktycznie coś źle zrobiliśmy a to nie jest po prostu narzekanie drugiej strony?
AR: Myślę, że tutaj najlepszym symptomem będzie to, że developer mówi za często to. Jeśli powiedział to raz w trakcie trwania projektu to znaczy, że faktycznie się nie dało tego zrobić. Ale jeśli co tydzień wraca do Ciebie z czymś i mówi: „Nie, tego nie zrobimy tak. To jest bez sensu.” to zazwyczaj po prostu ma tendencję do tego, żeby sobie zbytnio ułatwiać życie, tym bardziej jeśli chodzi o jakieś animacje albo coś. Często developerzy też nie potrafią robić animacji, bo po prostu ignorują tę część, bo im się to nie podoba, bo oni chcą robić JavaScript i w ogóle „wal się”. Ale no jak już są w projekcie to fajnie, żeby potrafili a jeśli nie to niech się nauczą. To nie jest aż tak trudne, przynajmniej w podstawowej jakiejś tam formie. Poza tym praca developera też na tym polega, że mierzymy się z rzeczami, których po prostu nie rozumiemy i nie potrafimy bardzo często na początku, i na tym to polega, żeby dłubać, dłubać i znaleźć coś, co będzie zadowalające. Więc częstotliwość odpowiadania w taki sposób na pytania jest na pewno ważna.
Jeśli developer wraca z takim feedbackiem na zasadzie „nie da się” to różnica jest taka, że dobry developer przygotuje Ci całą listę rzeczy dlaczego się nie da i argumentację – przedstawi Ci to tak, że zrozumiesz to dlaczego tego się nie da zrobić i sama powiesz: „Ok, faktycznie bez sensu.” Kiepski developer po prostu powie: „nie da się” i to znaczy zazwyczaj tyle, że nie zrobił żadnego researchu. Bo jakby zrobił to by się nim podzielił a po prostu z góry powiedział, że: „e, przecież tak się nie da.” Co ciekawe, nawet jakby developerzy czasami niecelowo wpadają w taką pułapkę. Miałem parę razy tak, zwłaszcza na początku jak zaczynałem być programistą w firmie to czasami robiłem tak, że wracałem i mówiłem: „ej, ale nie da się tego zrobić, to jest za trudne” itd. A starszy developer, po prostu stażem, przychodził i mówił: „Nie, no dobra. Ogarniemy jakoś” i w końcu znalazł jakiś tam sposób jak to zrobić. Więc to nie jest tak, że to zawsze jest zła intencja. Po prostu czasami jest to niedoświadczenie i trzeba się do tego przyznać, nie? Że nie pozjadaliśmy wszystkich rozmów i ta umiejętność researchu i znajdowania pewnych rozwiązań jest też jakby skillem, które musimy ogarnąć jako developerzy. Nie zawsze go posiadamy od samego początku.
NB: No chyba, że po prostu trafimy w którymś momencie na po prostu słabego programistę, no bo tak też się może zdarzyć. Myślę, że teraz branża rozkwita i zachęca do tego, żeby dołączać, robić bootcampy i zacząć programować. I są jakieś takie cechy, zachowania, wypowiedziane zdania, które mogą nam zapalać lampkę ostrzegawczą i mówić, że po prostu mamy do czynienia z osobą niekompetentną?
AR: Z mojego doświadczenia to właśnie ten brak argumentacji przy tego typu stwierdzeniach. Czyli jeśli… straszny wstyd. A propos komentarza. Właśnie ten mój kolega designer, który też wdraża strony, pracowaliśmy razem w pierwszej agencji. To jest w ogóle gość, który mi robił logo. Adam – pozdrawiam, Adam, jeśli oglądasz. On, jak jeszcze pracowaliśmy w agencji właśnie mieliśmy developerów i była kilka razy taka akcja, że on zaprojektował coś na stronę, developer mówił, że się nie da po czym on przychodził i praktycznie ten fragment kodu pokazywał, że „ej, ale przecież możemy to zrobić tak i to w czystym CSSie”, więc zdarzają się. Jest jakby mem, ten żart jest jakby już taki powszechny, ale faktycznie tak się zdarza.
Natomiast, wracając. Złego developera poznamy po tym, że jeśli mówi nam, że się nie da to nie dostarcza nam żadnych informacji dlaczego się nie da. Jest po prostu leniem i mu się nie chce. Jak się nie da to niech nam udowodni, że się nie da i niech nam to wytłumaczy a nie traktuje nas jak idiotów, że my nie zrozumiemy, bo jesteśmy designerami. To tak nie działa praca w zespole i trzeba też szanować to, że designerzy mają inne pole, którymi się zajmują, ale jakby jeśli coś im się wytłumaczy no to rozumieją. Tak samo jak my możemy się uczyć od designerów, tak samo starajmy się dzielić tą wiedzą z nimi.
NB: Dobra. Mam jeszcze takie pytanie, które pominęłam przez przypadek, patrz: „Słownik między designerem a developerem? Żeby nie wyjść na głupka.” Spotkałeś się z czymś takim?
AR: Nie. Tak sobie myślę nawet o jakichś właśnie zwrotach, które można by było użyć.
NB: Mi się wydaje, że warto w obszarze tym takim UIowym zerkać na design systemy, bo to jest takie narzędzie, które często jest pomostem między projektantami a developerami. Tam dużo jest takiego i słownictwa projektowego, i w sumie jest kod i można sobie popatrzeć jak to jest opisane dla developerów. Więc taka dokumentacja może być jakimś punktem wyjścia, żeby coś zrozumieć i wyłapać?
AR: Nawet nazywanie komponentów czasem jak np. wiesz, designer nazwie coś np., nie wiem, range i np. masz taki slider po prostu gdzie trzeba przeciągać wartość a np. właśnie developer to nazwie slider albo jeszcze nie wiem, scale albo coś jeszcze innego, więc taka spójność pomiędzy nazewnictwem pewnych komponentów jest na pewno fajna, żeby się jakoś tam dogadać.
I tak jak mówisz, bardzo często właśnie fajnym odnośnikiem jest np. material UI, gdzie możesz sobie podejrzeć jak się ten komponent nazywa, bo to są wszystkie komponenty świata już zaprojektowane.
NB: I tak sobie myślę jeszcze, że jak mamy jakąś przestrzeń, nie wiem, w Confluence albo w jakimkolwiek narzędziu, gdzie zbieramy, jest naszym źródłem wiedzy to tam możemy po prostu przeznaczyć page’a jednego na taki słowniczek dosłownie. Często jak się robi analizy biznesowe to tam też się wrzuca jakieś pojęcia, żeby ujednolicić opisy między poszczególnymi obszarami. Spotkałam się z tym po prostu w takiej dokumentacji i w sumie co stoi na przeszkodzie, żeby wypisać te elementy, żeby one były i żeby łatwiej się do tego odnosić? Że mamy jakieś określone nazwy na komponenty, bo te nazwy komponentów w każdym systemie inaczej się będą nazywać i każdy to inaczej będzie rozumiał, więc to jest też dobry punkt wyjścia. A tak to chyba taka współpraca, nie? Jak się na co dzień współpracuje to się łapie te słówka i tam się zaczyna rozumieć co oni o czym gadają, w ogóle o co chodzi.
AR: To wychodzi w praniu. Warto pamiętać o tym, że to że designer nazwie jakiś komponent X a developer w kodzie nazwie to Y to też nie jest jakiś wielki problem. Problem może pojawić się wtedy, że designer nazwie coś z sliderem a developer np. range’m i później mają story book’a, gdzie jest zaimplementowany już ten komponent i designer będzie szukał jak wygląda ten komponent już zaimplementowany pod złą nazwą, więc po prostu nie znajdzie. Także tutaj jakoś faktycznie można się dogadać, ale to są takie przypadki. Myślę, że do rozwiązania szybko.
NB: Tu widzę, że jest… Chciałam Ci jeszcze zadać kolejne pytanie, ale tu widzę, że jest jeszcze pytanie od Kamil Ka: „Jestem grafikiem, pracuję w DTP (ulotki itp.). Tworzę grafiki na social media, chcę bardziej iść w web dev. Moje pytanie czy lepiej iść w UX/UI czy uczyć się programowania i iść we front–end? Znam HTML, CSS.” Co byś, Roman, doradził?
AR: Dużo rzeczy tutaj. Cztery stanowiska tu widzę.
Nie wiem, Kamil, bo Cię nie znam i po prostu ciężko mi powiedzieć np. co robisz w HTMLu i CSSie. Wydaję mi się, że to powinieneś sam czuć bardziej: czy Cię ciągnie w stronę właśnie UX/UI. Tutaj warto pamiętać o tym, że to nie jest jedno i to samo, że UX to jest trochę w stronę Zebzy, UI to jest bardziej… Ale się teraz wkopałem.
NB: Dajesz, dajesz!
AR: Bo nie wiem. Jak np. mamy UI, mamy też np. designerów, którzy się specjalizują bardzo w UI, ale nie mają aż tak dużej wiedzy na temat UX np.: nie potrafią robić badań itd., czy jakiś wywiadów z użytkownikami. Teraz tak rzucam tutaj, kleje na gorąco, żeby wybrnąć jakoś z tego, ale… Wiesz, później masz jeszcze ilustratorów, którzy też czasami coś projektują. Tych zawodów w projektowaniu jest teraz mnóstwo. To już nie jest tak jak kiedyś, że był tylko designer i elo.
NB: Nie, był ten – Web Master i robił i designy, i tabelki, strony na tabelkach. Więc to w ogóle się robiło wszystko wtedy. Fullstack, to był prawdziwy fullstack można powiedzieć.
AR: Natomiast frontend to jest taki potwór ogromny, że… Też on ma sporo swoich odnóg. Możesz robić frontend w naprawdę najróżniejszych rzeczach i taki mainstreamem teraz jest JavaScript i np. React, jakieś aplikacje, ale nie wszyscy przecież się tym zajmują. Są ludzie, którzy nie wiem, robią templaty do WordPress’a i zarabiają na tym dużo pieniędzy. Dużo…
Dobra – w dużo pieniędzy i powiedziałem duże pieniędze.
NB: Przypominam, że Roman był copywriterem kiedyś, człowiek od słowa. A w ogóle nie wiem czy wiecie, ale to jest człowiek, który wymyślił nazwę naszego wyzwania UIowego – „Idź pan w UI”, więc tutaj oklaski przy okazji.
Sory, że Ci przerwałam, ale muszę tutaj…
AR: To się mówi „Idź pan w UI (czyt. uj)”.
NB: Wiem, ale potem mówią, że brzydko nazwałam.
Ja bym powiedziała, że to pewnie będzie zależało od tego jak dobrym grafikiem jesteś teraz i jak dobrze się czujesz w tym grafikowaniu, bo czasami jest tak, że jak bardzo długo pracujemy w projektowaniu i się okazuje, że coś co nam się sprawdzało w DTP albo w ulotkach w ogóle się nie sprawdzi w digitalu i w ogóle nie będziemy czuć tego projektowania do webów. Więc to chyba, nie wiem… Trzeba by było już indywidualnie rozpatrywać kto jak tam co czuje.
AR: Miałem jedną graficzkę właśnie w jednej z agencji, która robiła świetne np. key visuale do kampanii reklamowych. Była na maxa kreatywna, tworzyła super plakaty, jakieś takie rzeczy. Jakoś miała taki polot po prostu w tym wszystkim, aż fajnie się to oglądało. I w momencie kiedy przychodziło do zaprojektowania nawet jakiejś prostej strony to wyglądało po prostu dramatycznie, bo brakowało jej takiej podstawowej wiedzy nawet na temat tego, jak projektować dla sieci. I to też są takie rzeczy że to, że ktoś robi DTP np. plakaty, key visuale itd. to nie znaczy, że będzie tak samo skutecznym projektantem stron aplikacji i odwrotnie też jest tak, że designer robiący stronki nie zrobi ci dobrego key visuala, bo może nie ma takiej, wiesz… To jest trochę copywriter w Photoshopie po prostu, nie?
NB: Bo tutaj jest temat Photoshopa to od razu zahaczę, płynnie przejdę do kolejnego pytania Iwony: „Co z tym Photoshopem do projektowania stron? Nie bijcie, jestem DTP, stron nie robię i się nie interesuję, ale jak się kręcę po biurze to widzę, że są ciśnięte te weby w PSie i potem są zaprogramowane.”
AR: Myślę, że tutaj największym problemem jest to w jaki sposób Photoshop jest skonstruowany, czyli że masz po prostu art board, na którym masz warstwy, ale bardzo szybko zrobić tam bałagan i jakoś ciężko się w tym odnaleźć. W tych nowoczesnych narzędziach do projektowania wydaje mi się, że jest to trochę łatwiejsze, bardziej poukładane. Nawet jeśli mamy mnóstwo warstw to wydaje mi się, że ta użyteczność tego jest po prostu wyższa. To raz a dwa jednak Photoshop jest do grafiki rastrowej. Dobrze mówię, Zebza? Problem jest taki, że jeśli zaczniesz używać wektorów to, z tego co pamiętam, Photoshop dość szybko zaczyna mulić, bo on nie radzi sobie do końca z tym wszystkim. Już pomijam fakt eksportowania później tych zasobów, gdzie w Sketchu czy Figmie prostu klikasz, robisz eksport do odpowiedniego formatu w odpowiedniej wielkości, jest to jakby natychmiastowe. W Photoshopie jest to trochę bardziej skomplikowany proces. Generalnie nie jest to narzędzie do projektowania stron w gruncie rzeczy.
NB: Adobe ma w ogóle Adobe XD, które docelowo miało być tym narzędziem do tworzenia takich rzeczy, więc można połączyć w ogóle Adobe XD z Photoshopem i te bardziej skomplikowane…
Bo też kwestia jakie strony, jaki UI. Bo można robić landingi, które są bogate w ilustracje, jakieś fotomontaże i wtedy taki Photoshop faktycznie może się przydać, żeby zrobić taki baner, jakiś wyrąbisty… Te efekty powrzucać. No ale jak się pracuje na UI tak nie wiem, robi się formularze, tabelki, nudne rzeczy no to robienie tego w Photoshopie jest po prostu mało wygodne i jeżeli ma się narzędzia dedykowane do takiej pracy to lepiej zawsze wybierać narzędzia, które faktycznie nam tą pracę ułatwią.
AR: W XD jeszcze masz o tyle fajnie, że możesz sobie faktycznie spiąć Photoshopa z XD i jak masz ten baner, o którym mówisz no to jak klikniesz go dwa razy to on się odpali w Photoshopie, zapiszesz go, on się wtedy zaktualizuje a dodatkowo jeszcze w XD możesz zrobić animację, więc jest to dużo…
W Photoshopie też może zrobić na timelinie, ale to już by było naprawdę hardcore jakby ktoś tak robił animacje do webu w Photoshopie. To jest naprawdę dużo bardziej przyjazne.
NB: Myślę, że Adobe też działa po prostu na zasadzie tego ekosystemu, więc jeżeli chcesz robić animacje no to masz te Animate’y, After Effects’y i inne narzędzia, które znowu można spiąć, więc… No ale to znowu – robi się bardzo dużo narzędzi, żeby w ogóle zrobić jakieś całkiem proste rzeczy.
Tutaj mamy pytanie od Marcina i ono jest takie poszatkowane na kilka wiadomości: poradnik UI/UX dla backend developerów. Nie wiem czym miałby się różnić taki poradnik dla backend developerów od tych frontendowych właściwie. Tutaj wspomina, że „projektanci wysyłają niedziałające linki do stron, skopiowane portfolio zmusza mnie jako programistę do nauki UI/UX. Mam frontend developerów seniorów, ale UI/UX już nie zrobią. Mam wrażenie, że rozmawiając jako programista z UI/UX Designerem i grafikami to próba dogadania się z obcymi formami inteligencji”. Myślę, że ten komentarz powinien zostać przypięty do końca rozmowy.
Jak wygląda komunikacja między projektantami a developerami zazwyczaj? No właśnie – gdzie tu jest problem?
AR: Marcin, jesteś backendowcem a chcesz robić designy. O tym krążą memy w sieci, nie rób tego.
NB: Myślę, że to jest kwestia znalezienia specjalistów. To nie jest proste. Ja rekrutuje też do Mobee’go projektantów, projektantki i znalezienie specjalistów, którzy robią dobrą robotę to chyba… I tak samo u Ciebie, Roman, nie? Dobrych programistów jest po prostu niezbyt łatwym zadaniem i trzeba mieć trochę cierpliwości do tego. Chociaż nie wiem jakie Ty masz doświadczenia jako programista?
AR: Tak. Generalnie mam wrażenie, że w jakimkolwiek zawodzie, o jakimkolwiek zawodzie nie mówimy wszędzie specjalistów jest mało, nie? Czy mówimy o lekarzach, czy stolarzach, czy developerach jest tak, że zazwyczaj trafiamy na przeciętnych, bardzo rzadko trafiamy na wybitnych. Czasami trafiamy na bardzo kiepskich.
NB: Ja mogę polecić, żeby się odezwać do Mobee Dicka w takich tematach. Jak brakuje projektantów to polecam Mobee Dick – tutaj może wspomóc.
Przejdę do kolejnego pytania, bo tutaj jest o współpracy freelans designera i developera. „Jak powinna wyglądać? Na co zwracać uwagę podczas doboru designera, z którym będziemy realizować projekt?” Na co Ty zwracasz uwagę? Jakbyś szukał designera do współpracy to na co byś patrzył?
AR: Na to czy ma doświadczenie w projektowaniu do sieci. To jest dla mnie najważniejsze, bo tak jak Ci mówiłem o tej graficzce z agencji, nie? Jeśli trafiłbym na nią i mielibyśmy razem zrobić projekt to dla mnie to by była męka po prostu, bo ona się nie zna na tym. To nie jest jej wina, po prostu nigdy tego nie robiła, więc tutaj zawsze patrzyłbym na doświadczenie. Kwestie, nie wiem, tego jak to wygląda, czy robi piękne rzeczy, czy przeciętne to już nie jest do końca moja brożka, bo to klient jakby o tym decyduje. Jeśli to zaakceptuje no to moim obowiązkiem jest to wdrożyć. Mogę ewentualnie dawać jakieś rady jak można by było to ulepszyć. Natomiast wygląd dla mnie nie ma aż takiego znaczenia, więc pod tym kątem bym nie patrzył, ale właśnie pod kątem tego jak przygotowuje materiały, czy one są kompletne, czy potrafi stworzyć jakiś porządek w tym projekcie, w którym ja się później odnajdę – to są takie rzeczy, które dla developera, tak egoistycznie patrząc, są bardzo ważne.
NB: Ja jeszcze bym patrzyła czy się można dogadać z takim człowiekiem komunikacyjnie. To jeszcze tam pasuje.
AR: Z mojego doświadczenia designerzy są supcio. Zawsze ich bardzo lubiłem i nie trafiłem chyba nigdy na designera buraka.
NB: To zazdroszczę Ci, bo ja trafiłam.
Ale dobra – jeszcze mam takie pytanie: Właśnie – „Projektowanie to jedno. Development to drugie a trzecie content. Wszystko ładnie zaprojektowane, wdrożone i wchodzą treści. No i się dzieje: sypie się. Jak żyć? Co wtedy?”
AR: To jest bardzo dobre pytanie, ponieważ bardzo często jest tak, że designer sobie projektuje rzeczy pod idealne treści, czyli że np. odpowiedź w FAQ ma tylko dwa zdania. Po czym się okazuje, że ma trzy strony A4. I weź to sklej później, żeby to wyglądało normalnie na stronie.
Albo, nie wiem, zaprojektowany jest jakiś wygląd na blogu np. pod konkretne długości artykułów.
O, tytuły to jest bardzo ważna rzecz. Zazwyczaj tytuły pięknie wyglądają na designach a później klient robi tytuł na trzy linijki i Ci się rozsypuje cały layout. Więc to są rzeczy, o których designer powinien pamiętać i powinien pamiętać o tym, że te treści mogą być różne a jeśli jest jakieś ograniczenie na zasadzie tytuł musi mieć 100 znaków to niech to później powie developerowi i developer w CMSie może ustawić taką wartość, żeby to zablokować, żeby nie zepsuć tego layoutu. Ale to są rzeczy, które trzeba faktycznie dogadać, więc tworzenie treści na zaimplementowanym layoutcie to już jest kolejny level świadomości, o którym trzeba pamiętać, bo to już jest… Na samym początku trzeba o tym pamiętać a to jest tak naprawdę efekt końcowy.
NB: Zachęcam w ogóle do wczesnej współpracy z ludźmi od contentu. My mamy takie role w Mobee’m jak UX writerzy, którzy staramy się, żeby wchodzili jak najszybciej do projektu i żeby można po prostu od razu przewidzieć te wszystkie contentowe tematy to wtedy jest trochę mniej zamieszania. No ale wiadomo, że to w zależności od tego jak działa proces, projekt to będzie różnie. Nam się powoli kończy czas. Ja za minutę powinnam powiedzieć stop i nara, idziemy stąd, ale mogę Ci jeszcze zadać tak ze dwa pytania, albo jedno?
AR: Nie pali mi się, także spoko.
NB: Dobra. Mi trochę tak, bo ja bym chciała już jednak odpocząć po dzisiejszym dniu pracy, ale mam pytanie od Kamila: „Bo jak to jest w realnych projektach? Zawsze robi się wszystko pixel perfect, dokładnie tak jak ktoś kto zaprojektuje w Axurze albo w XD? Czy jak designer zrobi gradient, który ma jakieś określone wartości to developer musi zrobić to jeden do jednego, co do pixela?” Jak to wygląda?
AR: To to zależy czy designer jest sadystą i się będzie przypieprzał o takie rzeczy. Bo zazwyczaj jakby rzeczywistość nie jest pixel perfect i zdarza się tak… Jakby designerzy projektują na trzy brainpoint’y a developerzy implementują to na po prostu… No może nie nieskończonej, ale na mnóstwie różnych konfiguracji, urządzeń, telefonów, tabletów, które mają różne nawet nie tylko wielkości, ale też proporcje ekranu. To się wszystko może tak spektakularnie wysypać, że pewne kompromisy na niektórych etapach wdrażania są potrzebne i fajnie żeby designer zdawał sobie z tego sprawę. I fajnie żeby miał też takie podejście, że „Dobra. Kumam, że to nie będzie pixel perfect. Zróbmy to tak, żeby po prostu było na tyle elastyczne, ale nadal ładnie wyglądało.” To jest jakby podejście, które ja bardzo lubię.
Więc tak – taka jest moja odpowiedź.
NB: No dobrze. To na koniec takie pytanie: Jakbyś miał tak podsumować rozmowę to mógłbyś nam powiedzieć, nam projektantom, o czym musimy bezwzględnie pamiętać? Co powinniśmy zapamiętać z tej rozmowy, kiedy będziemy się zabierać za współpracę z developerami? Takie wiesz, złote rady od wujka Romana.
AR: Myślę, że najważniejszą radą jaką mógłbym udzielić to świadomość, że Wasze designy nie żyją w Figmie, tylko żyją później w przeglądarce. I one mają i różne rozdzielczości, i one się zwijają, rozwijają i mają treści, które są dłuższe i krótsze, i mają różne stany, błędy, które trzeba wyświetlić, empty state’y, które muszą zostać zaprojektowane, bo inaczej np., nie wiem, ja muszę wyrenderować tabele, ale jak mi się dane nie zaczytają albo akurat ta tabela jest pusta to głupio będzie wyświetlić pustą tabelę. Fajnie, żeby tam była jakaś ładna ilustracja, która mówi “nie ma – coś się stało”, żeby to było jakieś fajne po prostu dla tego użytkownika, ciekawe, żeby to nie było takie nudne i suche. I to są właśnie często rzeczy, o których designerzy nie pamiętają.
Więc raz – ta świadomość tego, że Wasze projekty będą żyć w jakiś urządzeniach mobilnych czy w przeglądarkach a dwa to mnogość scenariuszy, które mogą pójść tak albo nie tak i to też trzeba zaprojektować, bo developer sam z siebie tego nie wytrzaśnie.
NB: Pięknie powiedziane.
Dobrze. To ja się czuję zainspirowana. Mam nadzieję, że Wy też. To tak słowem zakończenia.
Moim gościem dzisiaj był Adam Romański, czyli Roman z kanału Hello Roman. Pod tym odcinkiem znajdziecie całą masę linków do różnych miejsc gdzie Romana znajdziecie m.in. jego kanału na YouTubie. Więc zerkajcie, patrzcie. Tam możecie trochę o frontendzie posłuchać. Sklep z notesami, takie tam. To wszystko znajdziecie.
Ja Ci dziękuję bardzo za to, że wpadłeś tutaj dzisiaj do nas. Fajnie było Cię zobaczyć, chociaż tylko wirtualnie. Dzięki wszystkim, którzy dzisiaj tutaj byli z nami: słuchali, oglądali, zadawali pytania. I do zobaczenia następnym razem gdzieś tam w sieci.
