Dziś krótki tekst dla tych, którzy przygodę z UI dopiero zaczynają.
Niedawno na kanale gościł u mnie Adam Romański – czyli Roman z kanału Hello Roman. Oprócz tego, że opowiedział trochę o tym co dzieje się po przekazaniu plików graficznych, wspomniał również o kilku wskazówkach. Warto je zapamiętać, jeśli zabieracie się za przygotowanie projektu do wdrożenia. Oto one, z komentarzem ode mnie:
Projektuj z myślą, że Twój projekt będzie żył w wielu przeglądarkach na setkach urządzeń – projekty nie żyją w Figmie
Zebza: Dlatego właśnie, na etapie planowania prac projektowych, warto uwzględnić projektowanie nie tylko na bazową, ustaloną szerokość. Projektując statyczne widoki, a tak właśnie projektujemy w popularnych programach do UI – zawsze od czegoś wychodzimy. W mojej codziennej pracy to albo któraś z mniejszych szerokości desktopowych (np. 1440 px lub 1366 px) lub szerokość mobilna (360 px).
W zależności od projektu, tworzymy albo całe zestawy widoków mobilnych i desktopowych (czasem kilka rozmiarów jeśli wymaga tego projekt) lub tylko na bazową rozdzielczość z kilkoma przykładowymi innych szerokości. Robimy to po to, żeby pokazać w jaki sposób zachowują się komponenty – nawigacja, jak formatują się teksty, jak zmniejszają lub zwiększają się marginesy i czy zdjęcia kadrują się czy skalują. Dzięki temu – już na etapie projektu rozstrzygamy zachowania interfejsu i przewidujemy, w których miejscach mogą pojawić się kłopoty.
Dużo prościej jest gdy pracujemy na gotowym design systemie, bo te decyzje zostały już podjęte wcześniej. Mając już zaprojektowane komponenty dopasowane do różnych ekranów, możemy nawet naszkicować lub zamakietować widok, a osoby odpowiedzialne za wdrożenie poradzą sobie ze złożeniem tego w całość. Oczywiście to jak pracujemy w tym przypadku – zależy od procesu, który sobie wypracowaliśmy lub wypracujemy – nie każdy osoba, która programuje zgodzi się budować ekrany w oparciu jedynie o makiety 😉
Kolejny krok to testowanie wdrożonego projektu. Tu zachęcam osoby projektujące do oglądania jak zachowuje się wymyślony interfejs i testowania go na różnych urządzeniach i systemach. Po co? Testów nigdy za wiele 😉 A do tego, również na tym etapie można znaleźć miejsca do usprawnień.
Zadbaj o porządek podczas handoveru – nazwy plików, odpowiednie eksporty, dobrze ponazywane artboardy i warstwy
Zebza: Powiedziałabym, że nie tylko podczas handoveru. Handover czy Handoff to termin oznaczający przekazanie prac. Używamy go najczęściej gdy mówimy o przekazaniu prac zespołu projektowego do wdrożenia. Czyli programistki i programiści przechwytują nasze projekty UI (lub makiety) i zaczynają to programować.
Dawno odeszliśmy już od klasycznego cięcia layoutu w Photoshopie. Najnowsze narzędzia do projektowania UI pozwalają na szybkie przełożenie warstwy wizualnej na kod. I sporo rzeczy automatyzują. Ale wciąż musimy dbać o to, by odpowiednio grupować nasze obiekty, nazywać je i jeśli sami zajmujemy się eksportem obrazów – zadbać również o ich nazwy i formaty. Roman w rozmowie przytaczał przykład ikon, które ktoś wyeksportował z bardzo długimi niemieckimi nazwami – zachęcam do stosowania uniwersalnego angielskiego (raczej wszyscy go znają). Jeśli pracujecie wyłącznie w polskim środowisku – to sprawa jest prosta – używamy polskiego.
Pamiętajcie, że porządek w pliku pomoże Wam – jeśli po jakimś czasie będzie trzeba coś w projekcie podłubać. Ale też każdej innej osobie, która będzie musiała zaprojektować coś po was lub z wami. Bardzo często pracuję na jednym pliku z kilkoma projektantami i ustalenie wspólnych zasad, jest ważne. Im większy projekt i większy zespół, tym więcej potencjalnych problemów pojawi się, jeśli te zasady nie zostaną ustalone. Nigdy nie wiecie też co się zdarzy – być może będziecie nagle niedostępni przez dłuższy czas. Takie dbanie o porządek sprawi, że osoby przejmujące wasz projekt, po prostu się w nim odnajdą.
Frontendowiec nie powinien być ignorantem względem UI i UX – Ty nie bądź względem developmentu i spróbuj zrozumieć, jak to działa
Zebza: Często projektanci wkraczający na ścieżkę UX lub UI pytają czy musimy umieć kodować? Otóż nie – i raczej w większości polskich ofert o pracę nie spotkacie się z takim wymogiem (za granicą to bardziej popularne). Nie zmienia to faktu, że podstawowa znajomość tego jak działa kod, jak wygląda wdrożenie szalenie się przydaje. I na etapie planowania projektu i budowania komponentów. I na etapie rozmowy z zespołem odpowiedzialnym za programowanie.
Łatwiej będzie wam przewidzieć miejsca potencjalnie problematyczne. Będziecie wiedzieć o co pytać i swobodniej poczujecie się na rozmowach z biznesem i programistkami i programistami. Po prostu będziecie lepiej rozumieć na czym polega wasza praca. Więc jak widzicie – same plusy.
W rozumieniu tej drugiej strony warto zacząć od zapoznania się z zupełnymi podstawami. Kursy z HTML i CSS mnożą się w sieci. Jest ich mnóstwo w różnych formatach, w wersjach darmowych i płatnych, po polsku i angielsku. Nic tylko sięgnąć po któryś z nich i spróbować stworzyć swoją pierwszą stronę. To, co prawda, nie jest jeszcze programowanie – na co dzień osoby programujące działają w oparciu o bardziej złożone mechanizmy. Ale to doskonały start żeby liznąć mały wycinek front-endu.
Sprawna i intensywna komunikacja rozwiąże problemy zanim staną się pożarem
Zebza: W każdym przypadku – nie tylko we współpracy z zespołem wdrożeniowym. Po prostu gadajcie. A jak nie możecie gadać – napiszcie – maila lub wiadomość na komunikatorze. Czasami wystarczy wymienić kilka wiadomości lub pogadać dziesięć minut żeby rozwiać wszystkie wątpliwości.
Projektując pamiętaj o interakcjach, animacjach, błędach i pustych stanach
Zebza: Wspominam o tym często gdy poruszam tematy projektowania interfejsów. Bardzo łatwo i przyjemnie projektuje się na optymistyczne scenariusze. Takie, gdzie teksty są krótkie, obrazki ładne, a dynamicznie wypełnionych treści dokładnie tyle ile sobie zamarzyliśmy. Ale prawdziwe produkty rzadko tak wyglądają.
W interfejsie pojawiają się błędy – wynikające z działań osób korzystających z interfejsu, jak i takich zupełnie od nich niezależnych. Zanim wypełnimy nasze aplikacje treścią – będą puste – a te stany również trzeba zaprojektować. Na przykład instruując, coś tłumacząc – pokazując, gdzie rozpocząć pracę z interfejsem. Interfejs jest z założenia interaktywny – to znaczy pozwala nam wykonywać pewne akcje i na nie odpowiada. Dlatego stany przycisków po najechaniu kursorem, wygląd pól tekstowych kiedy wpisujemy teksty czy to jak wygląda stan ładowania się treści – to wszystko trzeba zaprojektować.
I to by było na tyle!
Zapis rozmowy z Romanem
Rozmowa, o które wspomniałam na początku, jest dostępna do obejrzenia na kanale, o tutaj:
