Deweloperzy „posiadają” kod, więc czy projektanci nie powinni „posiadać” doświadczenia?

Opublikowany: 2022-03-10
Szybkie podsumowanie ↬ Wszyscy tam byliśmy. Spędziłeś miesiące na gromadzeniu wymagań biznesowych, opracowywaniu złożonych podróży użytkowników, tworzeniu precyzyjnych elementów interfejsu i testowaniu ich na reprezentatywnej próbce użytkowników tylko po to, aby zobaczyć produkt końcowy, który ma niewiele wspólnego z pożądanym doświadczeniem.

Wszyscy tam byliśmy. Spędziłeś miesiące na gromadzeniu wymagań biznesowych, opracowywaniu złożonych podróży użytkowników, tworzeniu precyzyjnych elementów interfejsu i testowaniu ich na reprezentatywnej próbce użytkowników, aby zobaczyć produkt końcowy, który w niewielkim stopniu przypomina pożądane wrażenia .

Może powinieneś był być bardziej stanowczy i nalegać na zwinne podejście, pomimo przekonania, że ​​organizacja nie była gotowa? Być może powinieneś zrobić lepszą robotę ze swoimi portfelami wzorców, upewniając się, że programiści wykorzystali twoją modułową bibliotekę kodu, zamiast tworzyć pięć różnych odmian karuzeli. A może nawet powinieneś codziennie siedzieć obok zespołu programistów, upewniając się, że to, co zaprojektowałeś, faktycznie się spełni.

Dalsze czytanie na SmashingMag:

  • Dlaczego powinieneś uwzględnić swojego programistę w procesie projektowania
  • Współpraca zespołowa i zamykanie luk w wydajności w projektowaniu responsywnym
  • Projektanci i programiści grają ładnie
  • Jak skutecznie komunikować się z programistami

Zamiast tego zostajesz z mieszanką elementów interfejsu użytkownika, z całą subtelnością. Czy nie widzieli, że pracowałeś przez kilka dni, aby uzyskać odpowiednie przejścia, tylko po to, aby wrzucili domyślną bibliotekę animacji? I skąd wziął się ten dodatkowy etap wymeldowania. Założę się, że marketing wrzucił to w ostatniej chwili. Wiedziałeś, że integracja będzie trudna i trzeba będzie iść na kompromisy, ale my mamy tu ułatwiać życie użytkownikom , a nie zespołowi technicznemu.

Więcej po skoku! Kontynuuj czytanie poniżej ↓
Kiedy w projekt zaangażowanych jest wiele osób, bardzo ważne jest, aby upewnić się, że mają wspólne zrozumienie problemu i jego rozwiązania.
Kiedy w projekt zaangażowanych jest wiele osób, bardzo ważne jest, aby upewnić się, że mają wspólne zrozumienie problemu i jego rozwiązania. (Źródło zdjęcia: The Next Web)

Oczywiście istnieje wiele dobrych powodów, dla których ta strona jest taka. Różne zespoły o różnym poziomie umiejętności pracujące nad różnymi częściami projektu, kilka zmian w ostatniej chwili skracających cykl rozwoju oraz cała masa wyzwań technicznych. Dlaczego jednak zespół programistów nie mógł przyjść i poprosić o radę w sprawie zmian w interfejsie użytkownika? Nie zadzierasz z ich kodem, więc dlaczego muszą zmieniać twoje projekty? Zwłaszcza, gdy wpływ na biznes może być ogromny! Jesteś tuż za rogiem i byłbyś szczęśliwy mogąc pomóc, gdyby właśnie o to poprosili.

Chociaż powyższa historia może być fikcyjna, jest to sentyment, który słyszę ze wszystkich zakątków świata designu, zarówno po stronie wewnętrznej, jak i agencji. Starannie wykonane doświadczenie zrujnowane przez ciężko pracujący zespół programistów.

To doświadczenie przypomina mi historię, którą kilka lat temu widziałem na lokalnym kanale informacyjnym w USA. Na jarmarku powiatowym organizowano zawody wytrzymałościowe, w których ostatnia osoba, która pozostała z ręką na pickupie, wygrała nagrodę. Często myślę, że projektowanie jest jak wielka gra „dotknij ciężarówki” , w której zespół programistów zawsze odchodzi z kluczami na koniec konkursu. Podobnie jak ostatnie słowo w kłótni, ostatnia osoba, która zetknie się z witryną, ma całą władzę i może dyktować jej działanie lub wygląd. Zwłaszcza jeśli twierdzą, że określone doświadczenie docelowe nie jest „technicznie możliwe”, co często jest skrótem od „naprawdę trudne”, „nie będę się przejmować robieniem tego w ten sposób” lub „myślę, że jest lepszy sposób na zrobienie tego więc wyciągnę kartę dewelopera”.

Teraz wiem, że jestem tutaj niesprawiedliwie surowy w stosunku do programistów i nie chcę być. Jest kilku niesamowicie utalentowanych technologów, którzy naprawdę dbają o użyteczność i chcą zrobić wszystko, co najlepsze dla użytkownika. Jednak często wydaje się, że istnieje asymetryczny poziom szacunku między dyscyplinami ze względu na przekonanie, że projektowanie jest łatwe i dlatego każdy może mieć swoje zdanie, podczas gdy rozwój jest trudny i tylko dla specjalnie wtajemniczonych. Tak więc, podczas gdy projektanci są zachęcani (czasem oczekuje się), aby angażowali wszystkich w proces projektowania, często nie zapewnia się im tego samego luksusu.

Szczerze mówiąc, nie obwiniam ich. W końcu znam wystarczająco dużo rozwoju, aby być niebezpiecznym, więc byłbyś idiotą, jeśli chciałbyś poznać moją opinię na temat struktury bazy danych i wydajności kodu (poza tym, że w dużej mierze uważam, że wydajność to dobra rzecz). Z drugiej strony wiem wystarczająco dużo, aby powiedzieć, kiedy programiści coś fałszują i zawsze fajnie jest wrócić do nich z działającym prototypem czegoś, co powiedzieli, że jest niemożliwe lub wdrożenie zajmuje miesiące — ale dygresja.

Problem w tym, że myślę, że wielu programistów ma takie samo stanowisko w kwestii projektowania — po prostu nie zdają sobie z tego sprawy. Kiedy więc wprowadzają zmianę w elemencie interfejsu na podstawie tego, co usłyszeli na konferencji kilka lat temu, może brakować im ważnego kontekstu. Może to było coś, co już przetestowałeś i zdyskontowałeś, ponieważ działało słabo. Być może wybrałeś ten element zamiast innego z konkretnego powodu, na przykład dostępności? A może opinie programistów były po prostu błędne, oparte na tym, jak postrzegają sieć jako superużytkownicy, a nie przeciętny Jo.

Teraz zróbmy coś prosto tutaj. Nie mówię, że programiści nie powinni wykazywać zainteresowania projektowaniem ani wkładu w proces projektowania. Mocno wierzę w parowanie między funkcjami i uważam, że niektóre z najlepszych rozwiązań użyteczności pochodzą od zespołu technicznego . Jest też wielu utalentowanych ludzi, którzy działają w wielu różnych dyscyplinach. Jednak w pewnym momencie doświadczenie musi być własnością i nie sądzę, że powinna być własnością ostatniej osoby, która otworzy plik HTML i „dotknie ciężarówki”.

Tak więc, jeśli dobrzy projektanci szanują umiejętności i doświadczenie, jakie wnoszą do stołu świetni programiści, co powiesz na odrobinę parytetu? Jeśli projektanci są zadowoleni z tego, że programiści są „właścicielami kodu”, dlaczego nie okazać podobnego szacunku i pozwolić projektantom na „posiadanie doświadczenia” ?

Komunikacja jest kluczowa, więc bądź dostępny.
Każdy ma swoją opinię. Jednak nie jest to wystarczający powód, aby po prostu zanurzyć się i zacząć wprowadzać zmiany. Źródło obrazu: Open Source Way

Zrobienie tego jest dość proste. Jeśli kiedykolwiek znajdziesz się w sytuacji, w której nie masz pewności, dlaczego coś zostało zaprojektowane w określony sposób, i uważasz, że można to zrobić lepiej, nie zanurkuj i nie zacznij wprowadzać zmian . Podobnie, jeśli natrafisz na techniczną przeszkodę i myślisz, że zaprojektowanie czegoś w inny sposób ułatwiłoby ci życie, porozmawiaj ze swoim projektantem. Mogą być całkowicie w porządku z sugerowanymi przez Ciebie zmianami lub mogą chcieć odejść i pomyśleć o innych sposobach rozwiązania tego samego problemu.

W końcu współpraca przebiega w obie strony. Jeśli więc nie chcesz, aby projektanci zaczęli „optymalizować” twój kod na serwerze, poza twoimi procesami kontroli wersji, przestań robić to samo z ich projektem.