Istnieje wiele artykułów , które uczą, jak projektanci mogą odmówić . Chodzi głównie o freelancerów i sposób interakcji z trudnymi klientami. Znajdują się tam również artykuły ze wskazówkami dotyczącymi postępowania z Product Managerami. Co jednak, gdy wspierasz system projektowania? Co zrobić ze sprzecznymi żądaniami innych projektantów lub programistów.

Nie wiem jeszcze co robię…

Jeśli nie jesteś ekspertem i dopiero zaczynasz tworzyć od podstaw system projektowy dla swojej firmy, możesz nie wiedzieć, w jakim kierunku podążać. Możesz oczywiście przeczytać kilka artykułów z przepisami na temat „ jak zacząć ”, ale czasami nie ma nic lepszego niż osobiste doświadczenie. Próbowanie czegoś, czasami popełnianie błędów i uczenie się na błędach. Otwartość na nowości. Bądź osobą typu „Tak, spróbujmy”.

W takiej sytuacji trzeba być jak najbardziej elastycznym. Udokumentuj jednak swoje decyzje, jeśli nie chcesz, aby udane decyzje pozostały „czarną magią”, a nieudane pozostały nieznanym zbiegiem okoliczności.

Nie chodzi mi tylko o zapisanie samej decyzji, ale o to, jak ty (lub inni) się tam dostaniesz. Argumenty itp. Tak, czasami może to być trudne. Zwłaszcza, gdy decyzja była intuicyjna (przeczucie). Jeśli jednak nauczysz się kwestionować siebie i innych, możesz w końcu zacząć rozumieć źródło tego pomysłu.

Taka dokumentacja pozwoli ci lepiej zrozumieć związki przyczynowo-skutkowe i dowiedzieć się, co działa, a co nie. A następnym razem, jeśli zobaczysz, że nowa propozycja pasuje do znanego schematu (lub idzie w tym samym kierunku) — będziesz mógł zwrócić na to uwagę innym. Oznacza to, że nauczysz się podawać uzasadnione powody przeciwko ryzykownym rozwiązaniom.

Gdzieś już to widziałem…

Zawsze możesz poprosić społeczność o przykłady złych decyzji . Projektanci (i wiele innych zawodów) lubią robić listy rzeczy, których nie należy robić .

Istnieje duży przekrój artykułów w kategorii „ 10 najgorszych decyzji projektowych ” i tym podobnych. Jednak w przypadku systemów projektowych najważniejsze będą opisy „dobrych/złych” praktyk, „wzorców”, „zaleceń i zakazów” itp. A najlepiej szukać ich w dokumentacji otwartych systemów projektowych.

Często takie dokumenty zawierają zwięzłe, ale zwięzłe argumenty za lub przeciw danemu rozwiązaniu i mogą bardzo pomóc w analizie sytuacji pojawiających się w twoim systemie. A nawet w codziennej pracy projektowej.

„Zalecania i zakazy” to kluczowy element dokumentacji projektowej każdego systemu, a im wcześniej zaczniesz dokumentować „dobre/złe” praktyki w swoim systemie, tym więcej pytań i nieporozumień będziesz w stanie uniknąć.

„ Jeśli coś nie jest udokumentowane, to nie istnieje ”

Dokumentacja to zobowiązanie. Ale także wskazówki „co mogę/powinienem zrobić”. W końcu projektanci często podejmują wątpliwe decyzje, ponieważ nie są świadomi tego, co należy, a czego nie należy robić w ramach systemu projektowego. Pod jego nieobecność stwierdzenie „wszystko jest możliwe” jest rozsądną myślą.

Ale tutaj należy podkreślić: w dokumentacji nie chodzi o zakazy. Dokumentacja ma za zadanie wyjaśnić, jak działa system i rozsądnie wskazać, co warto, a co nie. W związku z tym, jeśli projektant (lub programista) kieruje się tylko „tak mi się podoba” i jest to sprzeczne z dokumentacją — masz rozsądny i uzasadniony powód do odmowy, powołując się na dokumentację.

Dokumentacja pomaga innym dawać dobry przykład argumentowania ich pomysłów. Zamień pomysły w rozwiązania, które pomogą przenieść Twój system projektowy na wyższy poziom.

Biblioteka projektowa ≠ System projektowy

Często pojawiają się problemy, gdy użytkownicy (lub współautorzy) nie rozumieją, czym jest system projektowy i myślą o nim jak o bibliotece projektowej. Wielu projektantów jest przyzwyczajonych do pracy z gotowymi bibliotekami projektów i konieczności ich modyfikowania, aby odpowiadały ich potrzebom.

„Podoba mi się ten UI-Kit, ale został stworzony bez uwzględnienia moich przypadków użycia, więc muszę go dostosować”. Brzmi całkiem rozsądnie, prawda? Tak, jeśli mówimy o rozwiązaniach firm trzecich, z których ty (lub ktoś inny) będziesz korzystać tylko z niewielkiej części. Ale w przypadku wewnętrznego systemu projektowego może to prowadzić do chaosu.

Coś podobnego do tego, ale trochę innego….

Moim zdaniem najtrudniejsze jest, gdy użytkownicy proszą o drobne zmiany. Dość małe zmiany:

• Dodaj możliwość używania ikon w nagłówkach.
• Zmień kolejność bloków na liście.
• Pokaż 3 przyciski zamiast 2 (zdefiniowane przez komponent).

• Spójność podejścia z innymi komponentami.
• Złożoność implementacji w kodzie i komponentach projektowych (Figma, Sketch itp.).

Najpierw musisz dowiedzieć się, czy wzór przecina się z jakimś innym komponentem. Aby to zrobić, musisz albo znać na pamięć wszystkie komponenty i ich zachowanie, albo przejrzeć każdy z nich i sprawdzić, czy propozycja nie koliduje z innymi komponentami. W przypadku najmniejszych konfliktów konieczne jest omówienie propozycji nie w odosobnieniu, ale w kontekście zachowania kilku komponentów. Może to często wymagać zaproszenia większej liczby osób do dyskusji.

Złożoność wdrożenia

Bardzo często to, co wygląda na proste rozwiązanie w projekcie, może wymagać ogromnego wysiłku w rozwoju. Być może dlatego, że obecna architektura nie jest wystarczająco elastyczna. Być może jest to po prostu sprzeczne z podstawowymi standardami/podejściami stosowanymi w programowaniu. Teoretycznie prawie wszystko jest możliwe, ale niektóre rzeczy będą wymagały większego wysiłku. W takiej sytuacji może być konieczne zrozumienie, jak ważne są te zmiany: „Miło mieć” lub „krytyczne potrzeby”.

Jesteśmy sługami, a nie dyktatorami

System projektowy jest produktem . Ale to jest bardzo specyficzne. Podczas gdy sukces większości produktów można mierzyć tym, ile zarabiają, w przypadku systemu projektowego głównym wskaźnikiem jest to, ilu użytkowników go używa i jak bardzo ułatwia im życie. Innymi słowy, system projektowy to „Najbardziej uczciwy produkt” . A to wiąże się z dużą odpowiedzialnością. Musimy nie tylko jak najlepiej wykorzystać to, czego chcą klienci, ale także pomóc im zrozumieć konsekwencje każdej wątpliwej decyzji:

• brak elastyczności w perspektywie
• opóźnienia w rozwoju rozwiązania (ze względu na złożoność rozwiązania i jego utrzymanie)
• potrzeba kaskadowych zmian w innych komponentach lub umowach
Wkład Stewarding Design System

Ostatecznie system projektowania dotyczy użytkowników (projektantów i programistów). Trzeba więc na nie bardzo uważać. W końcu bez nich jesteśmy nikim. A jeśli zmiany są rozsądne i niczego nie psują — dlaczego ich nie zrobić?

Wszystkie powody, by powiedzieć „nie”, dotyczą tylko upewnienia się, że tworzymy produkt, którego potrzebują użytkownicy, a nie taki, jakiego chcą.

Zapytany o wkład klientów w rozwój Forda Model T, Henry Ford powiedział: „Gdybym zapytał ludzi, czego chcą, powiedzieliby, że szybszych koni”.

Dziękuje za przeczytanie! Zostańmy w kontakcie! Połącz się ze mną na LinkedIn i śledź mnie na Dribbble oraz tutaj na Medium , aby uzyskać więcej treści związanych z projektowaniem.