Jak programiści frontendu mogą usprawnić pracę projektanta

Ten artykuł jest skierowany głównie do Ciebie, drogi Frontend Developerze, który lubi implementować interfejsy użytkownika, ale ma trudności z dopasowaniem oczekiwań do projektantów, z którymi pracujesz. Być może jesteś określany jako „Programista UI” lub „Inżynier UX”. Niezależnie od tytułu, który nosisz, twoja praca (a także moja) to coś więcej niż tchnięcie życia w pliki projektowe. Odpowiadamy również za wypełnienie luki między procesami projektowania i rozwoju . Jednak przekraczając ten most, stajemy przed wieloma wyzwaniami.

Dzisiaj chciałabym podzielić się z Wami praktycznymi wskazówkami, które pomogły mi efektywniej współpracować z projektantami w ostatnich latach.

Uważam, że naszym zadaniem, jako deweloperów interfejsu użytkownika, jest nie tylko pomaganie projektantom w ich przygodzie do poznania działania sieci, ale także poznanie ich rzeczywistości i nauczenie się ich języka.

Zrozumienie doświadczenia projektantów UX

Większość projektantów UX (określanych również jako Web Designers lub Product Designers) stawiała pierwsze kroki w świecie projektowania za pomocą narzędzi takich jak Photoshop i Illustrator. Być może byli to graficy : ich głównym celem było tworzenie logotypów i tożsamości marek oraz projektowanie layoutów magazynów. Mogli też być Marketing Designerami : drukować billboardy, projektować banery i tworzyć infografiki.

Oznacza to, że większość projektantów UX spędziła swoje pierwsze dni na projektowaniu do druku, co jest zupełnie innym paradygmatem niż ich obecne medium, ekran. To było ich pierwsze duże wyzwanie. W przypadku druku projektanci dbali o wyrównanie pikseli, ale na ustalonym obszarze (papierze). Nie musieli zmagać się z dynamicznym układem (ekranami). Myślenie o łamaniu tekstu lub stanach interakcji też nie było częścią ich pracy. Projektanci mieli również pełną swobodę w zakresie kolorów, obrazów i typografii bez ograniczeń wydajnościowych.

Na szczęście społeczność samouków UX podjęła wiele wysiłków, aby nauczyć podstaw programowania, przedyskutować, czy projektanci powinni nauczyć się kodować i zrozumieć, jak najlepiej przekazać programistom. To samo dotyczyło strony deweloperskiej (więcej o tym za chwilę). Jednak nadal istnieje tarcie między tymi dwoma polami.

Z jednej strony projektanci narzekają za każdym razem, gdy implementacja nie pasuje do ich projektów lub czują się niezrozumiani, gdy są one odrzucane przez programistów bez jasnego wyjaśnienia. Z drugiej strony programiści mogą przyjąć za pewnik, że projektanci wiedzą coś technicznego, gdy może to nie być prawdą. Wierzę, że wszyscy możemy zrobić coś lepszego.

Przyjęcie nowego sposobu myślenia

Tworzone przez nas strony i aplikacje będą wyświetlane na ekranach o różnych rozmiarach. Każda osoba będzie z nich korzystać na wielu urządzeniach. Naszym wspólnym celem jest stworzenie znajomego doświadczenia podczas ich podróży.

Kiedy my, jako programiści, myślimy, że projektanci są wybredni w kwestii wyrównania pikseli, musimy zrozumieć, dlaczego tak jest. Musimy przyznać, że wykracza to poza wierność i spójność. Chodzi o sumę wszystkich współpracujących ze sobą części. To spójność. Musimy to przyjąć i zrobić co w naszej mocy, aby to osiągnąć. Poznanie podstaw zasad projektowania to dobry punkt wyjścia . Zrozum, jak ważny jest wybór właściwych kolorów, jak działa hierarchia i dlaczego białe znaki mają znaczenie.

Uwaga : istnieje kurs online znany jako „Projektowanie dla programistów” i książka zatytułowana „Refaktoryzacja interfejsu użytkownika” — oba są świetne na początek. Dzięki nim będziesz w stanie zaimplementować interfejsy użytkownika z bystrym okiem do szczegółów i uzyskać znaczącą dźwignię podczas komunikowania się z projektantami.

Zwiększanie świadomości projektantów

Możesz przyjąć za pewnik, że projektanci znają sieć tak samo jak Ty. Cóż, mogą nie. Właściwie nie muszą! Naszym obowiązkiem, jako deweloperów, jest aktualizowanie ich o aktualny stan sieci.

Pracowałem z dwiema stronami tego spektrum: projektanci, którzy uważają, że można zbudować wszystko (takie jak złożone filtry, nowe zachowania przewijania lub niestandardowe dane wejściowe formularzy) bez zastanawiania się nad kompatybilnością przeglądarek. Następnie są projektanci z założeniami o „niskich ograniczeniach sieci” i po prostu zakładają sobie, że czegoś nie da się zaimplementować. Musimy pokazać im prawdziwe możliwości projektowania stron internetowych i nie pozwolić, by ograniczenia ograniczały ich umiejętności.

Naucz je kodować, a nie kodować

Wydaje się to sprzeczne, ale proszę mnie o to: umiejętność kodowania jest podstawą pracy programisty. Pracujemy w szybko rozwijającej się branży, w której codziennie pojawiają się nowe rzeczy. Byłoby hipokryzją z naszej strony żądać od projektantów, aby nauczyli się kodować. Możemy jednak pomóc im zrozumieć kod.

Usiądź obok projektanta, z którym pracujesz, przez 15 minut i naucz go, jak sam może zobaczyć, czy specyfikacje elementu są prawidłowe i jak je zmienić. Uważam, że Inspektor Stron Firefox jest wyjątkowo przyjazny dla użytkownika.

Obecnie przyjemnie jest wizualizować układy, debugować animacje CSS i poprawiać typografię. Pokaż im gotowy do użycia plac zabaw z kodem, taki jak Codepen, aby mogli je odkryć. Nie muszą znać wszystkich specyfikacji CSS, aby zrozumieć, jak działa paradygmat układu. Muszą jednak wiedzieć, jak powstają i zachowują się elementy, aby wzmocnić ich codzienną pracę.

Uwzględnij projektantów w procesie rozwoju

Zaproś projektantów, aby dołączyli do Ciebie w spotkaniu stand-up, aby uczestniczyli w procesie kontroli jakości i usiedli z Tobą podczas dopracowywania szczegółów wizualnych w swoich wdrożeniach. Dzięki temu zrozumieją ograniczenia sieci i wkrótce zrozumieją, dlaczego wdrożenie funkcji wymaga czasu.

Poproś projektantów, aby włączyli Cię w proces projektowania

Zdasz sobie sprawę, że robią znacznie więcej niż tylko „uczynić rzeczy ładnymi”. Dowiesz się więcej o procesie badawczym i sposobie przeprowadzania testów użytkowników. Odkryjesz, że dla każdej propozycji projektu, którą ci przedstawiają, kilka innych badań zostało wcześniej porzuconych. Gdy projektanci proszą o zmianę, zapytaj o powód, dla którego się to stało, abyś mógł dowiedzieć się więcej o podejmowanych decyzjach . W końcu zaczniesz rozumieć, dlaczego są wybredne w kwestii białej przestrzeni i wyrównań, i miejmy nadzieję, że wkrótce też będziesz!

Uważam za kluczowe traktowanie frontendu jako kluczowej części procesu projektowania, a projektowania jako kluczowej części procesu rozwoju. Promowanie sposobu myślenia, w którym każdy ma szansę uczestniczyć w cyklu projektowania i rozwoju, pomoże nam wszystkim lepiej zrozumieć wzajemne wyzwania i stworzyć wspaniałe doświadczenia.

Możemy używać różnych narzędzi, ale musimy mówić tym samym językiem

Teraz, gdy zaczynamy lepiej rozumieć nawzajem tok pracy, nadszedł czas na kolejny krok: mówić tym samym językiem.

Wykraczając poza edytor kodu

Kiedy zaczniesz zwracać uwagę na swoje otoczenie, będziesz lepiej przygotowany do rozwiązywania problemów. Poznaj lepiej biznes i bądź chętny do wysłuchania tego, co mają do powiedzenia projektanci. Dzięki temu staniesz się członkiem zespołu z bogatszym wkładem w projekt. Współpraca w obszarach wykraczających poza nasze kompetencje jest kluczem do tworzenia konstruktywnych rozmów i wzajemnego zaufania.

Korzystanie z systemów interfejsu użytkownika jako umowy

Poproś projektantów, aby podzielili się z Tobą swoim systemem projektowania (a jeśli go nie używają, nigdy nie jest za późno na rozpoczęcie). Dzięki temu zaoszczędzisz sobie trudu ręcznego wybierania użytych kolorów, obliczania marginesów lub odgadywania stylu tekstu. Upewnij się, że znasz system interfejsu użytkownika w takim samym stopniu jak oni.

Być może znasz już koncepcję opartą na komponentach. Jednak niektórzy projektanci mogą nie postrzegać tego w taki sam sposób, jak Ty. Pokaż im, jak komponenty mogą pomóc w bardziej efektywnym tworzeniu interfejsów użytkownika. Rozpowszechniaj ten sposób myślenia, a także pożegnaj się z podobnymi, ale nie równymi imionami: nagłówek vs bohater, informacje o cenach vs selektor cen . Kiedy budowany jest element interfejsu użytkownika (aka „komponent”), staraj się używać tych samych nazw , aby można je było odzwierciedlić zarówno w projektach, jak i plikach kodu. Następnie, gdy ktoś mówi: „Musimy ulepszyć widżet zaproszenia do składania propozycji”, wszyscy dokładnie wiedzą, o czym mowa.

Uznanie prawdziwego źródła prawdy

Pomimo tego, że interfejs użytkownika jest najpierw tworzony w plikach projektowych, prawdziwym źródłem prawdy jest strona programistyczna. Pod koniec dnia to właśnie ludzie widzą, prawda? Kiedy projekt jest aktualizowany, dobrym pomysłem jest pozostawienie na marginesie informacji o jego stanie rozwoju, zwłaszcza w projektach, w które zaangażowana jest duża liczba osób. Ta sztuczka pomaga utrzymać płynną komunikację, więc nikt (w tym ty) nie zastanawia się: „ To różni się od wersji na żywo. Czy to błąd, czy nie został jeszcze zaimplementowany? ”

Utrzymywanie długu pod kontrolą

Tak więc wiesz wszystko o długu technicznym — dzieje się tak, gdy koszt wdrożenia czegoś nowego jest wysoki z powodu skrótu, który w przeszłości poszliśmy na skróty, aby dotrzymać terminu. To samo może się zdarzyć również po stronie projektu i nazywamy to długiem projektowym .

Można o tym pomyśleć w ten sposób: im większa niespójność UX i UI, tym większe zadłużenie (techniczne i projektowe). Jedną z najczęstszych niespójności jest posiadanie różnych elementów reprezentujących to samo działanie. To dlatego zły projekt jest zwykle odzwierciedlony w złym kodzie . Od nas wszystkich, zarówno jako projektantów, jak i programistów, zależy, czy poważnie traktujemy nasz dług projektowy.

Bycie dostępnym nie oznacza, że ​​musi być brzydkie

Bardzo się cieszę, że zarówno my, jako programiści, jak i projektanci, w końcu zaczynamy wprowadzać dostępność do naszej pracy. Jednak wielu z nas nadal uważa, że ​​projektowanie dostępnych produktów jest trudne lub ogranicza nasze umiejętności i kreatywność.

Przypomnę, że nie tworzymy produktu tylko dla siebie. Tworzymy produkt, z którego mogą korzystać wszystkie osoby , także te, które korzystają z produktu w inny sposób niż Ty. Weź pod uwagę, w jaki sposób poszczególne elementy mogą być bardziej dostępne, przy jednoczesnym zachowaniu przejrzystości i spójności obecnych przepływów użytkowników.

Na przykład, jeśli projektant naprawdę uważa, że ​​tworzenie ulepszonych danych wejściowych jest konieczne, stań po jego stronie i pracuj razem, aby zaprojektować i wdrożyć go w przystępny sposób, aby mógł być używany przez szerokie grono osób o różnych umiejętnościach.

Przekazywanie cennych informacji zwrotnych projektantom

Podczas przeglądania projektów nie da się uniknąć pytań. Nie jest to jednak powód do narzekania na błędy projektantów czy ich ambitne pomysły. Projektanci nie są po to, by doprowadzać cię do szaleństwa, po prostu nie zawsze intuicyjnie wiedzą, czego potrzebujesz, aby wykonać swoją pracę. Prawda jest taka, że ​​w przeszłości też nie wiedziałeś o tych rzeczach, więc bądź cierpliwy i potraktuj współpracę jako sposób uczenia się.

Im wcześniej informacja zwrotna, tym lepiej

Kluczowy jest czas na informację zwrotną. Przepływ pracy z opiniami zależy w dużej mierze od struktury projektu, więc nie ma dla niego uniwersalnego rozwiązania. Jednak, jeśli to możliwe, uważam, że powinniśmy dążyć do przepływu okresowych informacji zwrotnych — zaczynając od wczesnych etapów. Takie nastawienie na otwartą współpracę jest sposobem na ograniczenie możliwości nieoczekiwanych dużych powtórzeń w dalszej części drogi. Pamiętaj, że im później przekażesz projektantowi swoją pierwszą opinię, tym wyższy będzie dla niego koszt zbadania nowego podejścia, jeśli zajdzie taka potrzeba.

Wyjaśnij abstrakcyjne pomysły w prostych słowach

Pamiętasz, jak powiedziałem, że wydajność nie była kwestią poprzednich prac projektantów? Nie panikuj, gdy nie wiedzą, jak tworzyć zoptymalizowane pliki SVG dla sieci. W obliczu projektu, który wymaga załadowania wielu różnych czcionek, wyjaśnij im, dlaczego powinniśmy zminimalizować liczbę żądań, a może nawet skorzystać z czcionek zmiennych. Oprócz szybszego ładowania zapewnia również bardziej spójne wrażenia użytkownika. O ile projektanci nie chcą się uczyć, unikaj używania zbyt wielu terminów technicznych podczas wyjaśniania czegoś. Możesz to postrzegać jako okazję do poprawy swoich umiejętności komunikacyjnych i wyjaśnienia swoich myśli.

Nie pozwól, aby założenia zamieniły się w decyzje

Niektóre pytania dotyczące specyfikacji projektu pojawiają się tylko wtedy, gdy ubrudzimy sobie ręce w kodzie. Aby przyspieszyć ten proces, możemy odczuwać pokusę podejmowania decyzji na podstawie naszych założeń. Proszę nie. Za każdym razem, gdy zamieniasz założenie w decyzję, ryzykujesz zaufanie, jakie zespół projektowy pokłada w tobie przy wdrażaniu interfejsu użytkownika. Zawsze, gdy masz wątpliwości, sięgnij i wyjaśnij swoje wątpliwości . To pokaże im, że zależy Ci na efekcie końcowym tak samo jak im.

Nie rób obejść samodzielnie

Gdy zostaniesz poproszony o zaimplementowanie projektu, który jest zbyt trudny, nie mów „to niemożliwe” ani nie zacznij samodzielnie wdrażać jego taniej alternatywnej wersji. To natychmiast powoduje tarcia z zespołem projektowym, gdy zauważają, że ich projekty nie zostały wdrożone zgodnie z oczekiwaniami. Mogą reagować ze złością lub nic nie mówić, ale czuć się pokonani lub sfrustrowani. Tego wszystkiego można uniknąć, jeśli wyjaśnimy im, dlaczego coś nie jest możliwe, w prostych słowach i zasugerujemy alternatywne podejścia. Unikaj dogmatycznych zachowań i bądź otwarty na współpracę nad nowym rozwiązaniem .

Poinformuj ich o technikach Graceful Degradation i Progressive Enhancement i stwórz razem idealne rozwiązanie i rozwiązanie awaryjne. Na przykład możemy ulepszyć układ z flexbox do CSS Grid. Pozwala nam to szanować główny cel funkcji i jednocześnie jak najlepiej wykorzystywać technologie internetowe.

Jeśli chodzi o animacje, bądźmy prawdziwi: w głębi duszy jesteś tak samo podekscytowany realizacją następnej animacji wow , jak projektanci, którzy ją tworzą. Różnica między nami a nimi polega na tym, że jesteśmy bardziej świadomi ograniczeń sieci. Nie pozwól jednak, aby ograniczało to Twoje umiejętności! Sieć ewoluuje szybko, więc musimy wykorzystać to na naszą korzyść.

Następnym razem, gdy zostaniesz poproszony o wprowadzenie do życia prototypu, postaraj się nie odrzucać go z góry lub zrób to sam. Potraktuj to jako okazję do przeforsowania siebie. Animacje to jeden z najbardziej wybrednych elementów tworzenia stron internetowych, więc upewnij się, że udoskonaliłeś każdą klatkę kluczową z projektantem — osobiście lub udostępniając prywatny zsynchronizowany link.

Wyjdź poza stan idealny — razem

Oto rzecz: nie chodzi tylko o ciebie. Jednym z wyzwań projektantów jest prawdziwe zrozumienie swoich użytkowników i zaprezentowanie projektów w jak najbardziej atrakcyjny sposób do sprzedaży Product Managerowi. Czasami zapominają o tym, co jest poza stanem idealnym, a programiści też o tym zapominają.

Aby uniknąć tych luk, dostosuj do projektantów wymagania scenariusza:

• Najgorszy scenariusz
  Scenariusz, w którym dzieją się najgorsze możliwości. Pomaga to projektantom powiedzieć „nie” stałym treściom i pozwolić, aby były płynne. Co się stanie, jeśli tytuł ma więcej niż 60 znaków lub jeśli lista jest zbyt długa? To samo dotyczy odwrotnego, pustego scenariusza. Co powinien zrobić użytkownik, gdy lista jest pusta?
• Stany interakcji
  Przeglądarka to coś więcej niż poruszanie się i klikanie. Istnieje kilka stanów: domyślny, najechanie, skupienie, aktywne, wyłączenie, błąd… a niektóre z nich mogą wystąpić w tym samym czasie. Poświęćmy im należytą uwagę.
• Stan ładowania
  Tworząc rzeczy lokalnie, możemy użyć kpin i zapomnieć, że ładowanie rzeczy zajmuje trochę czasu. Poinformuj również projektantów o tej możliwości i pokaż im, jak sprawić, by ludzie zauważyli, że ładowanie rzeczy nie trwa tak długo.

Biorąc pod uwagę wszystkie te scenariusze, zaoszczędzisz dużo czasu na przemieszczanie się tam iz powrotem w fazie rozwoju.

Uwaga : jest świetny artykuł autorstwa Scotta Hurffa o tym, jak naprawić złe interfejsy użytkownika, który przybliży nas do uzyskania dostępnego produktu.

Uwzględnij prośby o zmianę

Deweloperzy są znani z tego, że nie są zbyt zadowoleni z tego, że ktoś znajdzie błąd w swoim kodzie — zwłaszcza, gdy jest to błąd projektowy zgłoszony przez projektanta. Wokół tego jest wiele memów, ale czy zastanawiałeś się kiedyś, jak te błędy mogą wpłynąć na pogorszenie zarówno jakości doświadczenia, jak i twoich relacji, gdy te błędy projektowe zostaną przypadkowo odrzucone? Dzieje się to powoli, prawie jak zasypianie. Kawałek po kawałku, a potem wszystko na raz. Projektanci mogą zacząć od powiedzenia: „ To tylko drobny szczegół”, dopóki nie narodzi się obojętność i uraza i nic nie zostanie powiedziane. Szkoda została już wtedy wyrządzona.

Ta sytuacja jest dwojaka: zarówno dla twoich rówieśników, jak i twojej pracy. Nie dopuść do tego. Pracuj nad tym, co wpływa na twoją reakcję. „Wybredny” projektant może być niewygodny, ale może też być płytką interpretacją uwagi i entuzjazmu inżyniera. Kiedy ktoś powie Ci, że Twoje wdrożenie nie jest (jeszcze) doskonałe, odłóż swoje ego na bok i pokaż mu, jak rozpoznajesz jego ciężką pracę w dopracowaniu końcowego rezultatu.

Raz na jakiś czas wybij się z rekordu

Wszyscy mamy zadania do wykonania i plany do ukończenia. Jednak niektóre z najlepszych prac zdarzają się nieoficjalnie. Nie zostanie zalogowany do tablicy TO DO i to jest w porządku. Jeśli znajdziesz projektanta, z którym masz kontakt, zakradnij się do jego przestrzeni roboczej i wspólnie eksploruj nowe eksperymenty. Nigdy nie wiadomo, co może stamtąd pochodzić!

Wniosek

Kiedy chcesz uczyć się od zespołu projektowego, uczysz się również różnych sposobów myślenia. Dzięki swoim doświadczeniom rozwiniesz swój sposób myślenia o współpracy z innymi obszarami, jednocześnie udoskonalając swoje oko do tworzenia nowych doświadczeń. Bądź tam, aby pomóc i bądź otwarty na naukę, ponieważ dzielenie się czyni nas lepszymi.

Ten artykuł nie byłby możliwy bez opinii wielu wspaniałych ludzi. Chciałbym z wdzięcznością podziękować projektantkom Jasmine Meijer i Margaridzie Botelho za pomoc w podzieleniu się zrównoważonym spojrzeniem na nieporozumienia między projektantami a programistami.

Powiązane czytanie na SmashingMag:

• „Projekt dla programistów” Mason Gentry
• „Współpraca: jak projektanci i programiści mogą komunikować się w celu tworzenia lepszych projektów” autorstwa Rachel Andrew
• „Jak programiści frontendu mogą pomóc w wypełnieniu luki między projektantami a programistami” autorstwa Stefana Kalteneggera
• „Których podcastów powinni słuchać projektanci stron internetowych i programiści?” przez Ricky'ego Onsmana