Systemy projektowania dotyczą relacji

Systemy projektowania mogą być niezwykle pomocne. Zapewniają elementy wielokrotnego użytku i wytyczne do budowania spójnego „wyglądu i stylu” produktów. W rezultacie użytkownicy mogą wykorzystać to, czego nauczyli się z jednego produktu, i zastosować to w innym. Podobnie zespoły mogą wdrażać dobrze przetestowane wzorce do nawigacji lub recenzji, dzięki czemu produkty będą bardziej godne zaufania. Skuteczne systemy projektowania rozwiązują nudne problemy w powtarzalny sposób, dzięki czemu programiści i projektanci mogą skupić się na rozwiązywaniu nowych problemów.

Jednak kiedy ktoś używa terminu „system projektowania” na spotkaniu, nigdy nie jestem pewien, jakiej reakcji się spodziewać. Widziałem ciekawość i podekscytowanie próbowaniem nowego sposobu pracy, ale widziałem też frustrację i zaniepokojenie ideą systemu ograniczającego kreatywność projektantów. Niektórzy projektanci twierdzą, że systemy projektowania osłabiają kreatywność lub są rozwiązaniami poszukującymi problemu. Systemy projektowe mogą z czasem ulegać fragmentacji, powodując, że zespoły przestają z nich korzystać.

Jednak systemy projektowania nie znikają. Według jednej ankiety w 2018 r. tylko 15% organizacji nie posiadało systemu projektowania. To spadek z 28% w poprzednim roku. Niektóre zespoły używają dużych systemów projektowania ogólnego przeznaczenia, takich jak Material Design firmy Google, podczas gdy inne używają mniejszych, bardziej dostosowanych do potrzeb systemów, takich jak Cedar REI i Protokół Mozilli.

Systemy projektowania powinny wzmacniać zespoły, a nie je ograniczać. Aby tak się stało, musimy zacząć myśleć bardziej holistycznie. System projektowania to nie tylko kod, projekty czy dokumentacja. To wszystkie te rzeczy, plus relacje między ludźmi, którzy tworzą system, a ludźmi, którzy go używają. Obejmuje nie tylko pliki CSS i dokumenty Sketch, ale także zaufanie, komunikację i współwłasność. Jak się okazuje, istnieje cała dziedzina badań poświęcona badaniu takich systemów.

Wielkie zdjęcie

Artykuł z 1960 roku zatytułowany „Systemy społeczno-techniczne” badał interakcje między technologią, ludźmi i większym środowiskiem, w którym one istnieją. Enid Mumford wyjaśniła, że ​​naukowcy zaczęli od zbadania, jak budować lepsze relacje między menedżerami a pracownikami, ale w latach 80. skupili się na tym, aby praca była bardziej wydajna i opłacalna. W 2011 roku Gordon Baxter i Ian Sommerville napisali, że te badania pomogły zainspirować projektowanie zorientowane na użytkownika i że pozostało jeszcze wiele do zrobienia.

Baxter i Sommerville argumentowali, że dzisiaj nadal istnieje napięcie między badaniami „humanistycznymi”, które koncentrują się na jakości życia pracowników, a badaniami „menedżerskimi”, które koncentrują się na ich produktywności. Wyjaśnili również, że ważne jest, aby wziąć pod uwagę zarówno technologię, jak i interakcje międzyludzkie: „wydajność systemu zależy od wspólnej optymalizacji podsystemów technicznych i społecznych”.

Twierdzę, że systemy projektowe są systemami społeczno-technicznymi. Obejmują interakcje między osobami, które tworzą system, osobami, które tworzą produkty za pomocą systemu, oraz użytkownikami końcowymi, którzy wchodzą w interakcję z tymi produktami. Wywołują również to samo napięcie między wydajnością a humanizmem, które widzieli Baxter i Sommerville.

Systemy projektowe składają się nie tylko z obrazów i kodu; obejmują rozmowy między projektantami, programistami, menedżerami produktu, prezesami i przypadkowymi osobami na GitHub. Te interakcje zachodzą w różnych kontekstach — w firmie, społeczności open source, w domu — i mają miejsce ponad kulturami i granicami organizacyjnymi. Budowanie zespołu może oznaczać łączenie ludzi z takich dyscyplin, jak animacja, projektowanie dźwięku, wizualizacja danych, haptyka i copywriting. Stworzenie udanego systemu projektowania wymaga równej części wiedzy technicznej i umiejętności miękkich.

A jednak przejrzyj projekt lub agregatory wiadomości inżynieryjnych, a prawdopodobnie zauważysz wyraźny nacisk na ten „podsystem techniczny” — kod i narzędzia, a nie na ludzi i rozmowy. Które narzędzie kreatywne najlepiej śledzi tokeny projektowe? Jakie technologie JavaScript powinny być używane do tworzenia komponentów wielokrotnego użytku — React, komponenty webowe czy coś innego? Które narzędzie do budowania jest najlepsze?

Odpowiedź na te pytania brzmi oczywiście „to zależy!” Kto zaprojektuje, zbuduje i będzie używał systemu? Jakie są ich potrzeby? Pod jakimi ograniczeniami działają? Z jakimi narzędziami i technologiami czują się komfortowo? Czego chcą się nauczyć?

Aby odpowiedzieć na tego rodzaju pytania, Baxter i Sommerville zalecają dwa rodzaje działań:

• Działania uwrażliwiające i uświadamiające
  Poznawanie różnych ludzi, którzy będą tworzyć i uczestniczyć w systemie oraz udostępnianie tych informacji na szeroką skalę.
• Konstruktywne zaangażowanie
  Komunikowanie się między rolami, budowanie prototypów i uwzględnianie zarówno technicznych, jak i społecznych części systemu.

Kopanie w

Na początku 2019 roku byłem częścią zespołu – nazwijmy go „niebiescy” – który budował system projektowania dla dużej organizacji. Ułatwiałem nieformalne rozmowy z tym zespołem i „team green”, który wykorzystywał system projektowania do budowy aplikacji webowej. Co kilka tygodni zbieraliśmy wszystkich programistów i projektantów przy stole i rozmawialiśmy o tym, co tworzymy i jakie problemy próbujemy rozwiązać. Te czaty były naszymi „działaniami uczulającymi i uświadamiającymi”.

Nie mieliśmy pozwolenia na upublicznienie naszego systemu projektowania, więc zrobiliśmy kolejną najlepszą rzecz: potraktowaliśmy go jak mały projekt open source w organizacji. Umieściliśmy kod w repozytorium, do którego oba zespoły miały dostęp i poprosiły o wkład. Zespół niebieski był odpowiedzialny za sprawdzenie i zatwierdzenie tego wkładu, ale każdy z obu zespołów mógł wnieść swój wkład. Team blue również budował własną aplikację, więc w pewnym sensie byli zarówno użytkownikami, jak i opiekunami systemu projektowania.

Te interakcje pomogły zespołom budować lepsze produkty, ale co równie ważne, zbudowały zaufanie między zespołami. Zespół niebieski dowiedział się, że ludzie korzystali z systemu w sposób przemyślany i na jego bazie budowali nowe, sprytne pomysły. Zespół Green dowiedział się, że system naprawdę był dostosowany do ich potrzeb, więc mogli z nim pracować, a nie przeciwko niemu. Baxter i Sommerville mogliby nazwać tę pracę „konstruktywnym zaangażowaniem”.

Odkryliśmy, że oba zespoły były pod presją uczenia się nowych technologii i szybkiego dostarczania kompletnego produktu. Innymi słowy, działali już pod dość znacznym obciążeniem poznawczym. W rezultacie oba zespoły zgodziły się skoncentrować na tym, aby system był łatwy w użyciu. Oznaczało to ominięcie całej debaty o komponentach internetowych, skupienie się głównie na CSS i zapewnienie, że nasza dokumentacja jest przejrzysta i przyjazna.

Kładąc wszystko razem

Organizacje dowolnej wielkości tworzą elementy projektu wielokrotnego użytku, aby pomóc zespołom w tworzeniu bardziej spójnych, eleganckich aplikacji. Potrzeby i dynamika różnych organizacji są wyrażane w ich systemach projektowania. Oto tylko kilka przykładów:

• Material Design firmy Google ma kilka implementacji w różnych platformach i językach. Jest używany przez różne osoby w Google i poza nim, więc zawiera obszerną dokumentację i różnorodne zestawy narzędzi do aplikacji do projektowania.
• System Fluent Design firmy Microsoft jest przeznaczony dla czterech bardzo różnych platform. Podobnie jak Material, zawiera zestawy narzędzi dla projektantów UX i obszerną dokumentację.
• Protokół Mozilli jest zaimplementowany w Sass i vanilla JavaScript. Koncentruje się na internacjonalizacji. Alex Gibson mówi, że ten system pomaga Mozilli „tworzyć strony internetowe związane z marką w szybszym tempie przy mniej powtarzalnej pracy ręcznej”.
• Cedar REI jest zbudowany z komponentów Vue.js i nie może być używany z innymi frameworkami JavaScript. Cedr jest używany głównie przez wewnętrznych programistów REI i jest ściśle związany z marką firmy. Kod systemu projektowania jest open source, ale jego czcionki nie są.
• Salesforce Lightning Design System to framework CSS niezależny od JavaScript. Może być opcjonalnie używany razem z Lightning Component Framework, który obejmuje dwie implementacje JavaScript: jedna wykorzystująca komponenty internetowe, a druga korzystająca z zastrzeżonego frameworka Salesforce Aura.
• PatternFly firmy Red Hat został stworzony w celu zapewnienia spójnego doświadczenia użytkownika we wszystkich produktach platformy chmurowej firmy, dzięki czemu ma stosunkowo dużą gęstość informacji i zawiera różnorodne komponenty wizualizacji danych. Zespół PatternFly niedawno przeszedł z Angulara na React po kilku eksperymentach z komponentami internetowymi. PatternFly zawiera również implementację niezależną od JavaScript przy użyciu HTML i CSS. (Pełne ujawnienie: jestem byłym Czerwonym Kapelusznikiem.)
• IBM Carbon Design System oferuje implementacje w React, Vue, Angular i vanilla JavaScript, a także zestaw narzędzi do projektowania dla Sketch. Zespół Carbon eksperymentuje z komponentami sieciowymi. (Wskazówka dla Jonathana Speeka za odnalezienie tego repozytorium.)

Takie systemy są spójne i niezawodne, ponieważ ludzie z różnych zespołów i ról pracowali razem, aby je zbudować. Systemy te rozwiązują rzeczywiste problemy. Nie są wynikiem tego, że programiści próbują narzucić swoją wolę projektantom i odwrotnie.

Josh Mateo i Brendon Manwaring wyjaśniają, że projektanci Spotify „widzą swoją rolę jako głównych współtwórców i współtwórców wspólnego systemu — takiego, którego są właścicielami”. Mina Markham opisuje siebie jako „tłumaczkę między inżynierią a designem” w systemie projektowania spodni. Jina Anne zagłębia się w dynamikę zespołu i badania użytkowników stojące za systemami projektowania: „Uwaga, spoiler! Będziesz potrzebować czegoś więcej niż tylko projektantów”.

Zbudujmy trochę rzeczy!

Teraz, gdy przeszliśmy przez badania i kilka przykładów, porozmawiajmy o tym, jak zbudować nowy system projektowania. Zacznij od rozmowy z ludźmi. Dowiedz się, kto będzie używał i wnosił wkład w Twój system projektowania. Ci ludzie prawdopodobnie będą obejmować różne dyscypliny — projektowanie, rozwój, zarządzanie produktami, biznes i tym podobne. Dowiedz się o potrzebach i celach ludzi i poproś ich, aby podzielili się tym, nad czym pracują. Rozważ zaplanowanie nieformalnego spotkania z przekąskami, kawą lub herbatą, aby stworzyć przyjazną atmosferę. Nawiąż regularną komunikację z tymi ludźmi. Może to oznaczać dołączenie do udostępnionego pokoju rozmów lub planowanie regularnych spotkań. Zachowaj swobodny i przyjazny ton i skup się na słuchaniu.

Kiedy mówisz o tym, nad czym pracujesz, szukaj wspólnych problemów i celów. Może się okazać, że zespoły muszą wyświetlać duże ilości danych, dlatego badają narzędzia do wyświetlania tabel i generowania raportów. Ustal priorytety rozwiązań tych problemów.

Poszukaj również powtarzających się wzorów i wariacji na podobne tematy. Może się okazać, że przyciski i formularze logowania wyglądają nieco inaczej w różnych zespołach. Jakie jest znaczenie tych odmian? Jakie odmiany są zamierzone — na przykład przycisk główny czy przycisk pomocniczy — i jakie odmiany powstały przypadkowo? Twój system projektowania może nazwać i skatalogować zamierzone wzory i odmiany, a także wyeliminować „przypadkowe” odmiany.

Celem jest stworzenie szybkiej pętli informacji zwrotnej z osobami korzystającymi z systemu projektowania. Szybsze informacje zwrotne i mniejsze iteracje mogą pomóc uniknąć posunięcia się zbyt daleko w złym kierunku i konieczności radykalnej zmiany kursu. PJ Onori nazywa te nagłe, duże zmiany „thrash”. Mówi, że niektóre thrash są dobre — to znak, że się uczysz i reagujesz na zmiany — ale to zbyt wiele może być destrukcyjne. „Nie powinieneś bać się thrashu”, mówi, „ale musisz wiedzieć, kiedy jest użyteczny i jak pomóc złagodzić jego wady. Jednym z najlepszych [sposobów] na złagodzenie wad thrashu jest zaczynanie od małych rzeczy – od wszystkiego ”.

Rozważ rozpoczęcie od małego, konfigurując kilka podstawowych elementów:

• System kontroli wersji do przechowywania kodu. GitHub, GitLab i Bitbucket to świetne opcje. Upewnij się, że każdy, kto korzysta z systemu, może uzyskać dostęp do kodu i zaproponować zmiany. Jeśli to możliwe, rozważ stworzenie kodu open source, aby dotrzeć do jak najszerszego grona odbiorców.
• Kod CSS do wdrożenia systemu. Użyj zmiennych Sass lub niestandardowych właściwości CSS do przechowywania „tokenów projektu” — wspólnych wartości, takich jak szerokości i kolory.
• Plik package.json, który definiuje sposób, w jaki aplikacje mogą budować i instalować system projektowania.
• Dokumentacja HTML, która pokazuje, jak korzystać z systemu projektowania, najlepiej przy użyciu własnego CSS systemu.

Dokumentacja node-sass dla frameworka CSS Bulma opisuje te kroki bardziej szczegółowo. Możesz pominąć instalację i import Bulmy, jeśli chcesz zacząć od zera, lub możesz ją dołączyć, jeśli chcesz zacząć od podstaw.

Być może zauważyłeś, że nie wspomniałem tutaj nic o JavaScript. Możesz chcieć dodać ten element w końcu, ale nie potrzebujesz go, aby zacząć. Łatwo jest zejść do króliczej nory, badając najlepsze i najnowsze narzędzia JavaScript, a zagubienie się w tych badaniach może utrudnić rozpoczęcie pracy. Na przykład „5 powodów, dla których składniki sieci Web są idealne do systemów projektowania” i „Dlaczego nie używam składników sieci” są słuszne, ale tylko Ty możesz zdecydować, które narzędzia są odpowiednie dla Twojego systemu. Zaczynając od CSS i HTML, możesz zbierać opinie z prawdziwego świata, które pomogą Ci podjąć tę decyzję, gdy nadejdzie czas.

Gdy wydajesz nowe wersje systemu, aktualizuj numer wersji systemu, aby wskazać, co się zmieniło. Użyj wersji semantycznej, aby wskazać, co się zmieniło, za pomocą liczby, takiej jak „1.4.0”. Zwiększ ostatnią liczbę w przypadku poprawek błędów, środkową liczbę w przypadku nowych funkcji i pierwszą liczbę w przypadku dużych, destrukcyjnych zmian. Kontynuuj komunikację z osobami korzystającymi z systemu projektowania, zapraszaj opinie i wkłady oraz wprowadzaj drobne ulepszenia w miarę postępów. Ten oparty na współpracy, iteracyjny sposób pracy może pomóc zminimalizować „thrash” i stworzyć poczucie współwłasności.

Na koniec rozważ opublikowanie systemu projektowania jako pakietu w npm, aby programiści mogli z niego korzystać, uruchamiając polecenie npm install your-design-system . Domyślnie pakiety npm są publiczne, ale można również opublikować pakiet prywatny, opublikować pakiet w prywatnym rejestrze lub poprosić deweloperów o zainstalowanie pakietu bezpośrednio z systemu kontroli wersji. Korzystanie z repozytorium pakietów ułatwi wykrywanie i instalowanie aktualizacji, ale instalowanie bezpośrednio z poziomu kontroli wersji może być łatwym, krótkoterminowym rozwiązaniem ułatwiającym zespołom rozpoczęcie pracy.

Jeśli chcesz dowiedzieć się więcej o inżynierii rzeczy, system budowania swojego projektu Katie Sylor-Miller zapewnia fantastyczne, głębokie nurkowanie. (Pełne ujawnienie: pracowałem z Katie.)

Zawijanie

Systemy projektowe składają się z kodu, projektów i dokumentacji, a także relacji, komunikacji i wzajemnego zaufania. Innymi słowy, są to systemy socjotechniczne. Aby zbudować system projektowania, nie zaczynaj od pisania kodu i wybierania narzędzi; zacznij od rozmowy z osobami, które będą korzystać z systemu. Poznaj ich potrzeby i ograniczenia oraz pomóż im rozwiązywać problemy. Podejmując decyzje techniczne, projektowe lub strategiczne, weź pod uwagę potrzeby tych ludzi, a nie teoretycznie „najlepszy” sposób robienia rzeczy. Zacznij od małych rzeczy, powtarzaj i komunikuj się w miarę postępów. Utrzymuj swój system tak prostym, jak to tylko możliwe, aby zminimalizować ilość śmieci, i zachęcaj do zgłaszania opinii i wkładów, aby stworzyć poczucie współwłasności.

Przywiązując równą wagę do kwestii inżynieryjnych i interpersonalnych, możemy czerpać korzyści z systemów projektowych, unikając jednocześnie pułapek. Możemy pracować w sposób wydajny i humanitarny; nie musimy wybierać jednego nad drugim. Możemy wzmocnić zespoły, zamiast je ograniczać. Wzmocnione zespoły ostatecznie pomagają nam lepiej służyć naszym użytkownikom — i właśnie dlatego tu jesteśmy.

Dalsze czytanie na SmashingMag:

• Wskazówki dotyczące zarządzania systemami projektowania
• Dołączanie animacji do systemu projektowania
• Poza narzędziami: jak budowanie systemu projektowania może poprawić Twoją pracę
• Budowanie systemu projektowania na dużą skalę dla rządu USA (studium przypadku)