Projektowanie z kodem: nowoczesne podejście do projektowania (wyzwania rozwojowe)

Ten artykuł został życzliwie poparty przez naszych drogich przyjaciół z UXPin, których misją jest zapewnienie najlepszych doświadczeń użytkownikom poprzez połączenie projektowania i inżynierii w jeden świat lepszego i szybszego rozwoju produktów. Dziękuję Ci!

Tarcia we współpracy między projektantami i programistami napędzają wciąż rozwijającą się dyskusję tak starą jak sama branża. Przeszliśmy długą drogę do miejsca, w którym jesteśmy dzisiaj. Nasze narzędzia się zmieniły. Zmieniły się nasze procesy i metodologie. Ale podstawowe problemy często pozostawały takie same.

Jednym z powtarzających się problemów, które często widzę, niezależnie od rodzaju i wielkości zespołu, jest utrzymanie wiarygodnego źródła prawdy . Nawet zatrudnianie najlepszych ludzi i korzystanie ze sprawdzonych rozwiązań branżowych często pozostawia nam niesmak, że coś zdecydowanie można było zrobić lepiej. Niesławna „wersja ostateczna” jest często rozpowszechniana w dokumentacji technicznej, plikach projektowych, arkuszach kalkulacyjnych i innych miejscach. Utrzymywanie ich wszystkich w synchronizacji jest zwykle żmudnym i zniechęcającym zadaniem.

Uwaga : ten artykuł został napisany we współpracy z zespołem UXPin. Przykłady przedstawione w tym artykule zostały stworzone w aplikacji UXPin. Niektóre funkcje są dostępne tylko w płatnych planach. Pełny przegląd cen UXPin można znaleźć tutaj.

Problem z narzędziami do projektowania

Mówiąc o utrzymaniu źródła prawdy, nieefektywność narzędzi projektowych jest często wskazywana jako jeden z najbardziej bolesnych punktów. Nowoczesne narzędzia do projektowania ewoluują i ewoluują szybko dzięki ogromnym wysiłkom. Ale jeśli chodzi o budowanie pomostu między projektowaniem a rozwojem, nierzadko można odnieść wrażenie, że wiele z tych wysiłków opiera się na błędnych założeniach.

Większość nowoczesnych narzędzi projektowych opiera się na innych modelach niż technologie wykorzystywane do późniejszej realizacji projektów. Są zbudowane jako edytory graficzne i tak się zachowują. Sposób, w jaki układy są budowane i przetwarzane w narzędziach do projektowania, ostatecznie różni się od tego, co mają do zaoferowania CSS, JavaScript i inne języki programowania. Budowanie interfejsów użytkownika przy użyciu grafiki wektorowej (a nawet rastrowej) to ciągłe zgadywanie, jak i czy to, co zrobisz, powinno zostać później przekształcone w kod.

Projektanci często lamentują, że ich kreacje nie zostały wdrożone zgodnie z przeznaczeniem. Nawet najśmielsze wysiłki zmierzające do uzyskania perfekcyjnych projektów nie rozwiązują wszystkich problemów. W narzędziach projektowych prawie niemożliwe jest wyobrażenie sobie i objęcie wszystkich możliwych przypadków. Obsługa różnych stanów, zmieniająca się kopia, różne rozmiary rzutni, rozdzielczości ekranu i tak dalej, po prostu zapewnia zbyt wiele zmieniających się zmiennych, aby objąć je wszystkie.

Do tego dochodzą pewne techniczne ograniczenia i ograniczenia . Będąc projektantem bez wcześniejszego doświadczenia programistycznego, niezwykle trudno jest wziąć pod uwagę wszystkie czynniki techniczne. Zapamiętaj wszystkie możliwe stany wejść. Poznaj ograniczenia obsługi przeglądarek. Przewiduj wpływ swojej pracy na wydajność. Design pod kątem dostępności, przynajmniej w pewnym sensie znacznie szerszy niż kontrast kolorów i rozmiary czcionek. Mając świadomość tych wyzwań, przyjmujemy pewną dozę domysłów jako zło konieczne.

Ale programiści często muszą też polegać na zgadywaniu. Interfejsy użytkownika wyśmiewane za pomocą edytorów graficznych rzadko odpowiadają na wszystkie ich pytania. Czy jest to ten sam komponent, który już mamy, czy nie? Czy powinienem traktować to jako inny stan, czy jako odrębny podmiot? Jak ten projekt powinien się zachowywać, gdy X, Y lub Z? Czy możemy zrobić to trochę inaczej, bo byłoby szybciej i taniej? Jak na ironię, pytanie o to, kto w ogóle stworzył projekty, nie zawsze jest pomocne. Nierzadko, oni też nie wiedzą.

I zazwyczaj nie na tym kończy się zakres rosnącej frustracji . Bo wtedy są też wszyscy inni . Menedżerowie, interesariusze, liderzy zespołów, handlowcy. Z ich uwagą i zdolnościami umysłowymi rozciągniętymi na wszystkie narzędzia i miejsca, w których znajdują się różne części produktu, bardziej niż ktokolwiek inny walczą, aby go dobrze zrozumieć.

Poruszanie się po prototypach, zrozumienie, dlaczego niektórych cech i stanów brakuje w projektach oraz rozróżnienie między tym, czego brakuje, co jest w toku, a tym, co zostało świadomie wyłączone z zakresu, wydaje się prawie niemożliwe. Szybkie powtarzanie tego, co już zostało zrobione, wizualizowanie opinii i przedstawianie własnych pomysłów również wydaje się prawie niemożliwe. Jak na ironię, coraz bardziej wyrafinowane narzędzia i procesy mają na celu lepszą współpracę projektantów i programistów ; stawiają poprzeczkę jeszcze wyżej, a aktywny udział w procesach dla innych jeszcze trudniej.

Rozwiązania

Niezliczeni szefowie naszej branży pracowali nad rozwiązaniem tych problemów, co zaowocowało nowymi paradygmatami, narzędziami i koncepcjami. I rzeczywiście wiele się zmieniło na lepsze. Przyjrzyjmy się pokrótce i jakie są niektóre z najczęstszych podejść do przedstawionych wyzwań.

Projektanci kodowania

„Czy projektanci powinni kodować?” to banalne pytanie omawiane niezliczoną ilość razy w artykułach, wystąpieniach konferencyjnych i we wszystkich innych mediach, z nowymi głosami w dyskusji pojawiającymi się od czasu do czasu ze stabilną regularnością. Panuje powszechne założenie, że gdyby projektanci „umieli kodować” (nawet nie zastanawiajmy się nad tym, jak w pierwszej kolejności zdefiniować „umiejętność kodowania”), łatwiej byłoby im tworzyć projekty, które czerpią z technologicznego z uwzględnieniem ograniczeń i są łatwiejsze do wdrożenia.

Niektórzy poszliby jeszcze dalej i powiedzieliby, że powinni brać aktywną rolę we wdrażaniu. Na tym etapie łatwo jest pochopnie dojść do wniosku, że nie byłoby bez sensu całkowicie pominąć korzystanie z narzędzi projektowych i po prostu „projektować w kodzie”.

Choć pomysł może brzmieć kusząco, rzadko sprawdza się w rzeczywistości. Wszyscy najlepsi projektanci kodowania, których znam, nadal używają narzędzi projektowych. I to na pewno nie z powodu braku umiejętności technicznych. Aby wyjaśnić, dlaczego ważne jest podkreślenie różnicy między ideacją, szkicowaniem i budowaniem rzeczywistej rzeczy.

Dopóki istnieje wiele prawidłowych przypadków użycia „projektowania w kodzie” , takich jak wykorzystanie predefiniowanych stylów i komponentów do szybkiego zbudowania w pełni funkcjonalnego interfejsu bez zawracania sobie głowy narzędziami do projektowania, narzędzia projektowe oferują nieograniczoną swobodę wizualną nadal ma niezaprzeczalną wartość. Dla wielu osób szkicowanie nowych pomysłów w formacie oferowanym przez narzędzia projektowe jest łatwiejsze i bardziej dopasowane do charakteru procesu twórczego. I to się nie zmieni w najbliższym czasie. Narzędzia projektowe są po to, aby pozostać i pozostać na dobre.

Systemy projektowe

Wielką misją systemów projektowania, jednym z największych modnych słów w cyfrowym świecie projektowania w ostatnich latach, zawsze było dokładnie to: ograniczenie domysłów i powtórzeń, poprawa wydajności i łatwości konserwacji oraz ujednolicenie źródeł prawdy. Systemy korporacyjne, takie jak Fluent lub Material Design, wykonały wiele pracy w obronie pomysłu i nabrały tempa w przyjęciu koncepcji zarówno przez dużych, jak i małych graczy. I rzeczywiście, systemy projektowe pomogły wiele zmienić na lepsze. Bardziej ustrukturyzowane podejście do opracowania określonego zbioru zasad projektowania, wzorców i komponentów pomogło niezliczonym firmom stworzyć lepsze, łatwiejsze w utrzymaniu produkty .

Niektóre wyzwania nie zostały jednak rozwiązane od razu. Projektowanie systemów projektowych w popularnych narzędziach projektowych utrudniało wysiłki wielu osób zmierzające do osiągnięcia jednego źródła prawdy. Zamiast tego stworzono mnóstwo systemów, które choć zunifikowane, nadal istnieją w dwóch oddzielnych, niekompatybilnych źródłach: źródle projektowym i źródle programistycznym. Utrzymanie wzajemnej parytetów zwykle okazuje się bolesnym obowiązkiem, powtarzając wszystkie najbardziej znienawidzone problemy, które systemy projektowe próbowały rozwiązać w pierwszej kolejności.

Integracje projektu i kodu

Aby rozwiązać problemy związane z konserwacją systemów projektowych, wkrótce pojawiła się kolejna fala rozwiązań. Koncepcje, takie jak tokeny projektowe, zaczęły zyskiwać na znaczeniu. Niektóre z nich miały na celu synchronizację stanu kodu z projektami, na przykład otwarte API, które umożliwiają pobieranie określonych wartości bezpośrednio z plików projektowych. Inne miały na celu synchronizację projektów z kodem, np. poprzez generowanie komponentów w narzędziach projektowych z kodu.

Niewiele z tych pomysłów kiedykolwiek zyskało szerokie zastosowanie. Wynika to najprawdopodobniej z wątpliwej przewagi ewentualnych korzyści nad koniecznymi kosztami wejścia wciąż wysoce niedoskonałych rozwiązań. Automatyczne tłumaczenie projektów na kod nadal stanowi ogromne wyzwanie dla większości profesjonalnych zastosowań. Poważnie ograniczone zostały również rozwiązania umożliwiające łączenie istniejącego kodu z projektami.

Na przykład żadne z rozwiązań umożliwiających importowanie zakodowanych komponentów do narzędzi projektowych, nawet jeśli wizualnie jest zgodne ze źródłem, nie będzie w pełni replikować zachowania takich komponentów. Do tej pory brak.

Scalanie projektu i kodu z UXPin

UXPin, jako dojrzała i w pełni funkcjonalna aplikacja do projektowania, nie jest nowym graczem na scenie narzędzi projektowych. Jednak najnowsze osiągnięcia, takie jak technologia scalania, mogą zmienić szanse na to, jak myślimy o narzędziach projektowych i programistycznych.

UXPin z technologią Merge pozwala nam wprowadzać do projektu rzeczywiste, działające komponenty, zachowując zarówno ich wygląd, jak i funkcjonalność — a wszystko to bez pisania nawet jednej linii kodu. Komponenty, nawet jeśli są osadzone w plikach projektowych, powinny zachowywać się dokładnie tak, jak ich rzeczywiste odpowiedniki — ponieważ są ich prawdziwymi odpowiednikami. Pozwala nam to nie tylko osiągnąć bezproblemową zgodność między kodem a projektem, ale także utrzymać je w nieprzerwanej synchronizacji.

UXPin obsługuje biblioteki projektowe komponentów React przechowywanych w repozytoriach git, a także solidną integrację ze Storybook, która umożliwia korzystanie z komponentów z niemal każdego popularnego frameworka front-end. Jeśli chcesz sam spróbować, możesz poprosić o dostęp do niego na stronie UXPin:

• Poproś o dostęp do UXPin z technologią Merge →

Łączenie żywych komponentów z projektami w UXPin to zaskakująco kilka kroków. Po znalezieniu odpowiedniego komponentu możesz jednym kliknięciem umieścić go na kanwie projektu. Będzie się zachowywał jak każdy inny obiekt w twoich projektach. To, co czyni go wyjątkowym, to fakt, że mimo iż jest on integralną częścią projektów, możesz go teraz używać i dostosowywać w taki sam sposób, jak w kodzie .

UXPin zapewnia dostęp do właściwości komponentu, umożliwia zmianę jego wartości i zmiennych oraz wypełnienie go własnymi danymi. Po uruchomieniu prototypu komponent powinien zachowywać się dokładnie zgodnie z oczekiwaniami, zachowując wszystkie zachowania i interakcje.

W swoich projektach możesz mieszać i dopasowywać nieograniczoną liczbę bibliotek i systemów projektowania . Oprócz dodawania własnej biblioteki, możesz także wybierać spośród szerokiej gamy dostępnych gotowych bibliotek open source, takich jak Material Design, Fluent UI lub Carbon.

Użycie komponentu „tak jak jest” oznacza również, że powinien zachowywać się zgodnie ze zmianą kontekstu, na przykład szerokości rzutni. Innymi słowy, takie komponenty są w pełni responsywne i elastyczne.

Uwaga : jeśli chcesz dowiedzieć się więcej o tworzeniu naprawdę responsywnych projektów za pomocą UXPin, gorąco zachęcam do zapoznania się z tym artykułem.

Kontekst może również oznaczać motywy. Ktokolwiek próbował zbudować (i utrzymać!) tematyczny system projektowania w narzędziu do projektowania lub przynajmniej stworzyć system, który pozwala łatwo przełączać się między jasnym i ciemnym motywem, wie, jak trudne jest to zadanie i jak niedoskonałe jest to zadanie. wyniki zwykle są. Żadne z narzędzi do projektowania nie jest dobrze zoptymalizowane pod kątem tworzenia szablonów po wyjęciu z pudełka, a dostępne wtyczki mające na celu rozwiązanie tego problemu są dalekie od rozwiązania go w pełni.

Ponieważ UXPin z technologią Merge korzysta z rzeczywistych, aktywnych komponentów, możesz je również motywować jako rzeczywiste, aktywne komponenty . Nie tylko możesz utworzyć tyle motywów, ile potrzebujesz, ale przełączanie ich może być tak szybkie, jak wybranie odpowiedniego motywu z listy rozwijanej. (Możesz przeczytać więcej o przełączaniu motywów za pomocą UXPin tutaj.)

Zalety

UXPin z technologią Merge zapewnia rzadko spotykany poziom parzystości między projektem a kodem. Bycie wiernym źródłu w procesie projektowania przynosi nienaganne korzyści dla wszystkich stron procesu. Projektanci mogą projektować z pewnością, wiedząc, że to, co tworzą, nie zostanie źle zinterpretowane lub źle opracowane. Deweloperzy nie muszą tłumaczyć projektów na kod i przedzierać się przez niejasne przypadki brzegowe i odkryte scenariusze. Co więcej, każdy może brać udział w pracach i szybko prototypować swoje pomysły przy użyciu żywych komponentów, bez jakiejkolwiek wiedzy o kodzie źródłowym. Osiągnięcie bardziej demokratycznych, partycypacyjnych procesów jest znacznie bardziej w zasięgu ręki.

Połączenie projektu z kodem może nie tylko poprawić współpracę projektantów z innymi elementami zespołu, ale także udoskonalić ich wewnętrzne procesy i praktyki. UXPin z technologią Merge może zmienić zasady gry dla tych, którzy koncentrują się na optymalizacji wysiłków projektowych na dużą skalę , czasami określanych jako DesignOps.

Korzystanie z właściwego źródła prawdy w niewytłumaczalny sposób ułatwia zachowanie spójności między pracami różnych osób w zespole, pomaga w ich ujednoliceniu i rozwiązuje właściwe problemy przy pomocy wspólnego zestawu narzędzi. Koniec z „odłączonymi symbolami” z kilkoma niechcianymi odmianami.

W ostatecznym rozrachunku otrzymujemy ogromną oszczędność czasu . Projektanci oszczędzają swój czas, pewnie korzystając z komponentów i ich funkcjonalności wychodzących z pudełka. Nie muszą aktualizować plików projektowych, gdy zmieniają się komponenty, ani dokumentować swojej pracy i „machać rękami”, aby wyjaśnić swoje wizje reszcie zespołu. Deweloperzy oszczędzają czas, pozyskując komponenty od projektantów w natychmiast przyswajalny sposób, który nie wymaga zgadywania i dodatkowego majsterkowania.

Osoby odpowiedzialne za testowanie i kontrolę jakości oszczędzają czas na szukaniu niespójności między projektami i kodem oraz zastanawianiu się, czy implantacja odbyła się zgodnie z przeznaczeniem. Interesariusze i inni członkowie zespołu oszczędzają czas dzięki sprawniejszemu zarządzaniu i łatwiejszej nawigacji takimi zespołami. Mniej tarcia i bezproblemowe procesy ograniczają frustrację członków zespołu.

Niedogodności

Korzystanie z tych korzyści wiąże się jednak z pewnymi kosztami początkowymi. Aby efektywnie korzystać z narzędzi, takich jak UXPin w swoim procesie, musisz mieć istniejący system projektowania lub bibliotekę komponentów . Alternatywnie możesz oprzeć swoją pracę na jednym z systemów open-source, który zawsze zapewnia pewien poziom ograniczeń.

Jeśli jednak jesteś zaangażowany w tworzenie systemu projektowego w pierwszej kolejności, wykorzystanie UXPin z technologią scalania w swoim procesie przyniosłoby niewielkie lub żadne dodatkowe koszty. Przy dobrze zbudowanym systemie projektowania, przyjęcie UXPin nie powinno być problemem, podczas gdy korzyści z takiej zmiany mogą okazać się drastyczne.

Streszczenie

Powszechne przyjęcie systemów projektowania dotyczyło problemów, z którymi współpracują twórcy mediów i projektanci. Obecnie obserwujemy zwrot w kierunku bardziej ujednoliconych procesów , które nie tylko przekształcają medium, ale także sposób, w jaki je tworzymy. Korzystanie z odpowiednich narzędzi ma kluczowe znaczenie dla tej zmiany. UXPin z technologią Merge to narzędzie projektowe, które pozwala łączyć projektowanie z komponentami kodu na żywo i drastycznie zmniejsza lukę między projektowaniem i rozwojem domen.

Gdzie dalej?

• Scalanie UXPin: integracja z książką
  Dowiedz się, jak integracja Storybook może pomóc Twojemu zespołowi produktowemu i wypróbuj to!
• Scalanie UXPin: integracja z Git
  Poproś o dostęp, aby zobaczyć, jak działa integracja z repozytorium Git.
• Krótkie objaśnienie wideo na temat UXPin Merge
  W ramach „Interactive Design Systems: Webinar with Johnson & Johnson”.
• Projekt z kodem: samouczek łączenia UXPin
  Samouczek wprowadzający do UXPin z technologią Merge.
• Responsywny projekt z UXPin Merge
  Przewodnik po prototypowaniu w pełni responsywnych doświadczeń z UXPin z technologią Merge.