W jaki sposób programiści frontendu mogą pomóc wypełnić lukę między projektantami a programistami

W ciągu ostatnich dziewięciu lat prawie każdy projektant, z którym pracowałem, wyrażał mi swoją frustrację, że często muszą spędzać dni na przekazywaniu opinii programistom, aby poprawić odstępy, rozmiary czcionek, aspekty wizualne i układ, które po prostu nie zostały poprawnie zaimplementowane . Prowadziło to często do osłabienia zaufania pomiędzy projektantami a programistami i powodowało brak motywacji projektantów oraz złą atmosferę między dwiema dyscyplinami.

Wiele razy programiści nadal wydają się mieć złą reputację zbyt technicznych i ignoranckich, jeśli chodzi o dbałość o szczegóły, które wymyślił zespół projektowy. Według artykułu Andy'ego Budda: „[…] wielu programistów ma takie samo stanowisko w kwestii projektowania — po prostu nie zdają sobie z tego sprawy”. W rzeczywistości jednak (jak wskazuje Paul Boag) „deweloperzy [muszą] cały czas podejmować decyzje projektowe”.

W tym artykule przedstawię praktyczne porady dla programistów frontend, aby uniknąć frustracji i zwiększyć produktywność podczas pracy z ich kreatywnym odpowiednikiem.

Patrząc oczami projektanta

Wyobraźmy sobie przez chwilę, że byłeś projektantem i spędziłeś ostatnie tygodnie – jeśli nie miesiące – nad opracowaniem projektu strony internetowej. Ty i Twoi koledzy z zespołu przeszliście wiele wewnętrznych zmian, a także prezentacje dla klientów, i włożyliście solidny wysiłek w dopracowanie szczegółów wizualnych, takich jak odstępy, style i rozmiary czcionek. (W erze responsywnej — oczywiście dla wielu rozmiarów ekranu). Projekty zostały zatwierdzone przez klienta i przekazane deweloperom. Czujesz ulgę i szczęście.

Kilka tygodni później otrzymasz wiadomość e-mail od swojego programisty, która mówi:

„Utworzono witrynę inscenizacyjną. Oto link. Czy możesz zadowolić kontrolę jakości?”

W dreszczyku oczekiwania otwierasz ten link inscenizacyjny i po przewinięciu niektórych stron zauważasz, że witryna wygląda trochę niewłaściwie. Odstępy nie są nawet zbliżone do tego, co sugerował Twój projekt, i zauważasz pewne załamania w układzie: nieprawidłowe kroje i kolory czcionek, a także nieprawidłowe interakcje i stany najechania. Twoje podekscytowanie zaczyna powoli zanikać i zamieniać się w uczucie frustracji. Nie możesz się powstrzymać od zadawania sobie pytania: „Jak mogło do tego dojść?”

Poszukiwanie powodów

Może po prostu w komunikacji między projektantami a deweloperami było sporo niefortunnych nieporozumień. Niemniej jednak nadal zadajesz sobie pytanie:

• Jak wyglądało przekazanie projektów? Czy były tylko jakieś pliki PDF, Photoshop lub Sketch udostępnione przez e-mail z komentarzami, czy też odbyło się rzeczywiste spotkanie przekazujące, podczas którego omawiano różne aspekty, takie jak możliwy system projektowania, typografia, zachowanie responsywne, interakcje i animacje?
• Czy istniały prototypy interaktywne lub ruchome, które pomagają wizualizować określone interakcje?
• Czy stworzono listę ważnych aspektów z określonymi poziomami priorytetów?
• Ile odbyło się rozmów — z projektantami i programistami w tym samym pomieszczeniu?

Ponieważ komunikacja i przekazanie to dwa bardzo ważne kluczowe punkty, przyjrzyjmy się im bliżej.

Komunikacja jest kluczowa

Projektanci i programiści, proszę, rozmawiajcie ze sobą. Mów dużo . Im wcześniej w projekcie i im częściej tym lepiej. Jeśli to możliwe, wspólnie dokonaj przeglądu prac projektowych w toku na wczesnym etapie projektu (i regularnie), aby stale oceniać wykonalność i uzyskiwać informacje interdyscyplinarne. Projektanci i programiści w naturalny sposób skupiają się na różnych aspektach tej samej części i dlatego widzą rzeczy z różnych perspektyw i perspektyw .

Wczesne zameldowanie umożliwia programistom zapoznanie się z projektem, dzięki czemu mogą rozpocząć badania i planowanie z wyprzedzeniem pod względem technicznym oraz przedstawiać swoje pomysły na ewentualną optymalizację funkcji. Częste meldowanie się również łączy zespół na poziomie osobistym i społecznym , a Ty uczysz się, jak podejść do siebie, aby skutecznie się komunikować.

Przekazanie od projektu do rozwoju

O ile organizacja nie postępuje zgodnie z naprawdę zwinnym przepływem pracy, początkowe przekazanie kompozycji projektowych i zasobów (od zespołu projektowego do programistów) prawdopodobnie nastąpi w pewnym momencie projektu. To przekazanie — jeśli zostanie wykonane dokładnie — może stanowić solidną podstawę wiedzy i porozumień między obiema stronami. Dlatego ważne jest, aby nie spieszyć się z tym i zaplanować trochę dodatkowego czasu.

Zadawaj wiele pytań i omawiaj każde wymaganie, stronę, komponent, funkcję, interakcję, animację, cokolwiek — i rób notatki. Jeśli coś jest niejasne, poproś o wyjaśnienie . Na przykład, pracując z zespołami zewnętrznymi lub kontraktowymi, zarówno projektanci, jak i programiści mogą podpisać notatki jako dokument wzajemnego porozumienia do wykorzystania w przyszłości.

Płaskie i statyczne kompozycje projektowe są dobre do pokazania aspektów graficznych i układu strony internetowej, ale oczywiście brakuje im właściwej reprezentacji interakcji i animacji. Poproszenie o prototypy lub działające demonstracje złożonych animacji stworzy jaśniejszą wizję tego, co należy zbudować dla wszystkich zaangażowanych.

Obecnie dostępna jest szeroka gama narzędzi do prototypowania, które projektanci mogą wykorzystać do tworzenia makiet i interakcji na różnych poziomach wierności. W jednym ze swoich obszernych artykułów Javier Cuello wyjaśnia, jak wybrać odpowiednie narzędzie do prototypowania dla swojego projektu.

Każdy projekt jest wyjątkowy, podobnie jak jego wymagania. Ze względu na te wymagania nie zawsze można zbudować wszystkie skonceptualizowane funkcje. Często dostępny czas i środki na zbudowanie czegoś mogą być czynnikiem ograniczającym. Ponadto ograniczenia mogą wynikać z wymagań technicznych, takich jak wykonalność, dostępność, wydajność, użyteczność i obsługa wielu przeglądarek, wymagań ekonomicznych, takich jak budżet i opłaty licencyjne, lub ograniczeń osobistych, takich jak poziom umiejętności i dostępność programistów.

A jeśli te ograniczenia powodują konflikty między projektantami a programistami?

Znajdowanie kompromisów i budowanie wspólnej wiedzy

Aby pomyślnie wysłać projekt na czas i spełnić wszystkie określone wymagania, znalezienie kompromisów między tymi dwiema dyscyplinami jest w większości nieuniknione. Deweloperzy muszą nauczyć się rozmawiać z projektantami w sposób nietechniczny, kiedy wyjaśniają powody, dla których rzeczy wymagają zmian lub nie mogą zostać zbudowane w określonej sytuacji.

Zamiast po prostu mówić „Przepraszamy, nie możemy tego zbudować”, programiści powinni spróbować podać wyjaśnienie zrozumiałe dla projektantów i — w najlepszym przypadku — przygotować sugestie dotyczące alternatywnego rozwiązania , które działa w ramach znanych ograniczeń. Poparcie swojego stanowiska statystykami, badaniami lub artykułami może pomóc w podkreśleniu twojego argumentu. Ponadto, jeśli czas jest problemem, może wdrożenie niektórych czasochłonnych części można przenieść na późniejszą fazę projektu?

Chociaż nie zawsze jest to możliwe, umieszczenie projektantów i programistów obok siebie może skrócić pętle sprzężenia zwrotnego i ułatwić wypracowanie kompromisowego rozwiązania. Adaptację i prototypowanie można wykonać bezpośrednio poprzez kodowanie i optymalizację za pomocą otwartego DevTools.

Pokaż innym projektantom, jak korzystać z DevTools w przeglądarce, aby mogli zmieniać podstawowe informacje i wyświetlać podgląd niewielkich zmian w przeglądarce (np. dopełnienia, marginesy, rozmiary czcionek, nazwy klas) w locie.

Jeśli projekt i struktura zespołu na to pozwalają, budowanie i prototypowanie w przeglądarce tak szybko, jak to możliwe, może dać wszystkim zaangażowanym lepsze zrozumienie zachowania responsywnego i może pomóc wyeliminować błędy i błędy na wczesnym etapie projektu.

Im dłużej projektanci i programiści współpracują ze sobą, tym lepiej projektanci zrozumieją, co jest łatwiejsze, a co trudniejsze do zbudowania programistom. Z biegiem czasu mogą w końcu odnieść się do rozwiązań, które w przeszłości sprawdziły się dla obu stron:

„Użyliśmy tego rozwiązania, aby znaleźć kompromis w Projekcie A. Czy możemy go użyć również w tym projekcie?”

Pomaga to również programistom lepiej zrozumieć, jakie szczegóły projektanci są bardzo konkretni i jakie aspekty wizualne są dla nich ważne.

Projektanci oczekują, że frontend będzie wyglądał (i funkcjonował) jak ich projekt

Plik projektowy Vs. Porównanie przeglądarek

Pomocną techniką zapobiegania frustracji projektantów jest wykonanie prostego porównania od lewej do prawej między przekazanym plikiem projektu a tym, jak wygląda Twój obecny stan rozwoju. Może to zabrzmieć trywialnie, ale jako programista musisz zadbać o tak wiele rzeczy, które muszą działać pod maską, że mogłeś przeoczyć niektóre szczegóły wizualne. Jeśli zauważysz jakieś zauważalne rozbieżności, po prostu je popraw.

Pomyśl o tym w ten sposób: każdy szczegół w Twojej implementacji, który wygląda dokładnie tak, jak został zaprojektowany , oszczędza zarówno Tobie, jak i projektantowi cenny czas i bóle głowy , oraz zachęca do zaufania. Nie każdy może zwracać uwagę na szczegóły na takim samym poziomie, ale aby wytrenować oko w dostrzeganiu różnic wizualnych, dobra pomoc może okazać się krótka runda Nie można zobaczyć.

To nostalgicznie przypomina mi grę, w którą graliśmy dawno temu, zatytułowaną „Znajdź”. Aby zdobyć punkty, trzeba było znaleźć rozbieżności, porównując dwa pozornie podobne obrazy.

Mimo to możesz pomyśleć:

„A co, jeśli w projekcie po prostu nie ma zauważalnego systemu rozmiarów czcionek i odstępów?”

Cóż, dobra uwaga! Doświadczenie pokazało mi, że rozpoczęcie rozmowy z projektantem(ami) może pomóc, prosząc o wyjaśnienia , zamiast radykalnie zmieniać rzeczy na własną rękę i tworzyć później niechciane niespodzianki dla projektanta(ów).

Naucz się podstawowych zasad typograficznych i projektowych

Jak stwierdza Oliver Reichenstein w jednym ze swoich artykułów, 95% informacji w sieci to język pisany. Dlatego typografia odgrywa istotną rolę nie tylko w projektowaniu stron internetowych, ale także w rozwoju. Zrozumienie podstawowych terminów i pojęć typograficznych może pomóc w skuteczniejszej komunikacji z projektantami, a także sprawi, że będziesz bardziej wszechstronny jako programista. Polecam przeczytać artykuł Olivera, który omawia znaczenie typografii w sieci i wyjaśnia terminy, takie jak mikro- i makro-typografia .

W „Przewodniku dotyczącym typografii w projektowaniu witryn mobilnych” Suzanne Scacca dokładnie omawia terminologię typograficzną, taką jak krój pisma, czcionka, rozmiar, gramatura, kerning, interlinia i śledzenie, a także rolę typografii w nowoczesnym projektowaniu witryn internetowych.

Jeśli chcesz jeszcze bardziej poszerzyć swój typograficzny horyzont, warto przeczytać książkę Matthew Buttericka „Praktyczna typografia Buttericka”. Zawiera również podsumowanie kluczowych zasad typografii.

Jedną z rzeczy, które uważam za szczególnie przydatne w responsywnym projektowaniu stron internetowych, jest to, że należy dążyć do średniej długości linii (znaków na linię) od 45 do 90 znaków, ponieważ krótsze linie są wygodniejsze do czytania niż dłuższe.

Czy programiści powinni projektować?

Odbyło się wiele dyskusji na temat tego, czy projektanci powinni nauczyć się kodować, i być może zadajesz sobie to samo pytanie na odwrót. Uważam, że w obu dyscyplinach trudno się wyróżnić i to jest w porządku.

Rachel Andrew ładnie opisuje w swoim artykule „Working Together: How Designers And Developers Can Communicate To Create Better Projects”, że aby współpracować efektywniej , wszyscy musimy nauczyć się czegoś o języku, umiejętnościach i priorytetach naszych kolegów z zespołu, może tworzyć wspólny język i nakładające się obszary wiedzy.

Jednym ze sposobów na zdobycie większej wiedzy w dziedzinie projektowania jest kurs online znany jako „Projektowanie dla programistów”, oferowany przez Sarah Drasner, w którym opowiada o podstawowych zasadach układu i teorii kolorów — dwóch podstawowych obszarach projektowania stron internetowych.

„Im więcej uczysz się poza własną dyscypliną, tym lepiej dla Ciebie [...] jako programisty”.

— Sara Drasner

Centrum Wizualne

Współpracując z projektantami poznałem różnicę między centrum matematycznym a wizualnym. Kiedy chcemy zwrócić uwagę czytelnika na pewien element, naturalny punkt skupienia naszego oka znajduje się nieco powyżej matematycznego środka strony.

Możemy zastosować tę koncepcję na przykład do pozycjonowania modów lub wszelkiego rodzaju nakładek. Ta technika pomaga nam w naturalny sposób przyciągnąć uwagę użytkownika i sprawia, że ​​projekt wydaje się bardziej zrównoważony:

Jesteśmy w tym razem

W dynamicznych i niezbyt zwinnych środowiskach agencji z napiętymi terminami, programiści są często proszeni o wdrożenie w pełni funkcjonalnych responsywnych frontendów opartych na makiecie mobilnej i stacjonarnej. To nieuchronnie zmusza dewelopera do podejmowania decyzji projektowych w trakcie całego procesu. Pytania takie jak „O jaką szerokość zmniejszymy rozmiar czcionki nagłówków?” lub „Kiedy powinniśmy zmienić nasz trzykolumnowy układ na jedną kolumnę?” może powstać.

Ponadto w ferworze może się zdarzyć, że szczegóły, takie jak stany błędów, powiadomienia, stany ładowania, mody lub style stron 404 po prostu wpadają w pułapkę. W takich sytuacjach łatwo zacząć wskazywać palcem i obwiniać ludzi, którzy powinni byli wcześniej o tym pomyśleć. Najlepiej byłoby, gdyby programiści nigdy nie znajdowali się w takiej sytuacji, ale co, jeśli tak jest?

Kiedy słuchałem założyciela i dyrektora generalnego Ueno, Haraldura Thorleifssona, przemawiającego na konferencji w San Francisco w 2018 roku, przedstawił dwie z ich podstawowych wartości:

„Nic tutaj nie jest problemem kogoś innego”.

„Zbieramy śmieci, których nie odłożyliśmy”.

Co by było, gdyby więcej programistów proaktywnie zaczęło w pierwszej kolejności wyśmiewać wyżej wymienione brakujące części, a następnie dopracować je razem z projektantem siedzącym obok nich? Witryny internetowe działają w przeglądarce, więc dlaczego nie wykorzystać jej do tworzenia i udoskonalania?

Podczas gdy brakujące lub zapomniane części skrzydłowe mogą nie zawsze być idealne, z moich wcześniejszych doświadczeń nauczyłem się, że zawsze pomagało nam to szybciej iść naprzód i eliminować błędy w locie — jako zespołowi .

Oczywiście nie oznacza to, że projektanci powinni być w tym procesie pomijani. Oznacza to, że programiści powinni próbować z szacunkiem spotkać projektantów w połowie drogi , wykazując inicjatywę w rozwiązywaniu problemów. Poza tym, jako programista byłem bardziej ceniony przez zespół po prostu za troskę i branie odpowiedzialności.

Budowanie zaufania między projektantami a programistami

Oparta na zaufaniu i pozytywna relacja między zespołem kreatywnym i technicznym może znacznie zwiększyć produktywność i wyniki pracy. Co więc możemy, jako deweloperzy, zrobić, aby zwiększyć zaufanie między tymi dwiema dyscyplinami? Oto kilka sugestii:

1. Zwróć uwagę na szczegóły .
   Budowanie rzeczy dokładnie tak, jak zostały zaprojektowane, pokaże projektantom, że Ci zależy i wywoła uśmiech na ich twarzach.
2. Komunikuj się z szacunkiem .
   Wszyscy jesteśmy ludźmi w profesjonalnym środowisku dążącym do jak najlepszych wyników. Okazywanie wzajemnego szacunku dla dyscypliny powinno być podstawą wszelkiej komunikacji.
3. Melduj się wcześnie i regularnie .
   Zaangażowanie programistów od samego początku może pomóc w szybkim wyeliminowaniu błędów. Dzięki częstej komunikacji członkowie zespołu mogą rozwijać wspólny język i lepiej rozumieć swoje stanowiska.
4. Bądź dostępny .
   Posiadanie co najmniej opcjonalnego 30-minutowego okna dziennie, podczas którego projektanci mogą omawiać pomysły z programistami, może dać projektantom poczucie wsparcia. Daje to również programistom możliwość wyjaśnienia złożonych kwestii technicznych słowami, które osoby niezbyt techniczne mogą lepiej zrozumieć.

Wynik: sytuacja wygrana-wygrana

Konieczność spędzania mniej czasu na QA poprzez efektywną komunikację i właściwe przekazanie projektów daje zespołowi kreatywnemu i programistycznemu więcej czasu na skupienie się na budowaniu rzeczywistych rzeczy i mniej bólu głowy. Ostatecznie tworzy lepszą atmosferę i buduje zaufanie między projektantami a programistami. Głos programistów frontend, którzy wykazują zainteresowanie i wiedzę w niektórych dziedzinach związanych z projektowaniem, będzie bardziej słyszalny na spotkaniach projektowych.

Aktywne przyczynianie się do znajdowania kompromisu między projektantami i programistami oraz rozwiązywanie problemów jako programista może zapewnić szersze poczucie własności i zaangażowania w cały projekt. Nawet w dzisiejszym dynamicznie rozwijającym się przemyśle kreatywnym nie jest łatwo znaleźć programistów, którzy — poza umiejętnościami technicznymi — dbają o szczegóły wizualne i mają oko na nie. To może być Twoja szansa na wypełnienie luki w Twoim zespole.

Powiązane zasoby

• „Jak wybrać odpowiednie narzędzie do prototypowania”, Javier Cuello
• „Poradnik dotyczący typografii w projektowaniu witryn mobilnych”, Suzanne Scacca
• „Praktyczna typografia Buttericka”, Matthew Butterick
• „Współpraca: jak projektanci i programiści mogą komunikować się w celu tworzenia lepszych projektów” — Rachel Andrew
• „Projekt dla programistów”, Sarah Drasner, Frontend Masters
• „Projektowanie stron internetowych to 95% typografia”, Oliver Reichenstein
• „Nie widać” — quiz w przeglądarce, który ćwiczy zmysł rozpoznawania szczegółów wizualnych.