Rozmowy projektowe: lepsza współpraca projektantów i programistów z Aarronem Walterem z InVision

Witamy w naszej serii Design Talks poświęconej dzieleniu się spostrzeżeniami liderów myśli i najlepszych ludzi zajmujących się projektowaniem z całego świata. Przeprowadzamy wywiady z ekspertami, którzy pracują nad projektowaniem w różnych kontekstach, mając różne cele i stosując różne podejścia. W tych seriach mamy nadzieję dostarczyć intelektualną i twórczą inspirację wszystkim naszym czytelnikom.

Projektanci często mają trudności ze współpracą z programistami i na odwrót. Drużyny po obu stronach mogą się od siebie wiele nauczyć, ale warstwy oporu pozostają. W tym tygodniu gościem jest Aarron Walter, wiceprezes ds. edukacji projektowej w InVision. Porozmawiamy o współpracy projektantów i programistów.

Aarron czerpie z 15-letniego doświadczenia w prowadzeniu zespołów produktowych i nauczaniu projektowania, aby pomóc firmom wprowadzać najlepsze praktyki projektowe. Założył praktykę UX w MailChimp i pomógł rozwinąć produkt z kilku tysięcy użytkowników do ponad 10 milionów.

Jego wskazówki projektowe pomogły Białemu Domowi, Departamentowi Stanu USA oraz dziesiątkom dużych korporacji, start-upów i firm venture capital. Jest autorem bestsellerowej książki Designing for Emotion z książki A Book Apart. Znajdziesz @aarron na Twitterze, w którym możesz podzielić się przemyśleniami na temat projektowania, a więcej informacji o Aarronie znajdziesz na aarronwalter.com.

W podkaście Design Better, Aarron Walter i Eli Woolery, przeprowadzają wywiady z liderami projektowania i wpływowymi osobami, które dzielą się historiami o rozwiązywaniu problemów i ścieżce kariery. Wśród gości są między innymi David Kelley (współzałożyciel IDEO i założyciel Stanford d.school), Julie Zhuo (wiceprezes ds. produktu i projektowania na Facebooku) i Jake Knapp (autor bestsellerów Sprint).

Witaj Aarron, miło mi Cię gościć na blogu Toptal Design. Czy deweloperzy z Marsa i projektanci z Wenus?

Z mojego doświadczenia wynika, że ​​projektanci i programiści prawdopodobnie mają ze sobą więcej wspólnego, niż sądzą, ale zdecydowanie istnieją wyraźne różnice w sposobie, w jaki myślimy o rzeczach. Projektanci uwielbiają myśleć o systemach projektowania, a programiści myślą o kodzie modułowym, który jest łatwy w utrzymaniu. Ale sposób, w jaki do tego podchodzimy, może być nieco inny.

Deweloperzy znaleźli sposoby na rozbicie swojej pracy na mniejsze części, a projektanci mają tendencję do myślenia o całości jako o „całym torcie” i o tym, jak je całe ciasto.

To jest moment, w którym zaczynają się walić. Inżynierowie chcą być w stanie dostarczać kod małymi krokami i robić coś bardzo szybko w ramach metodologii Agile. Projektanci zazwyczaj chcą zrobić duży krok naprzód w sposób całościowy — chcą zapewnić spójne środowisko. To może być punkt sporny dla tych dwóch grup.

Co projektanci mogą zrobić, aby nieco przybliżyć programistom naszą perspektywę? W jaki sposób projektanci mogą sprawić, że programiści zrozumieją, że każda drobna dostarczona funkcja dotyczy również doświadczenia?

Obie strony mają okazję się tutaj zgiąć. Projektanci czasami próbują przekonać dewelopera, że ​​musimy poczekać i zbudować całość, a potem wyrzucić ją za drzwi jako to piękne, kompletne doświadczenie.

Ale jeśli cykl tworzenia jest zbyt długi, produkty mogą zostać zabite. Ludzie zaczynają tracić zainteresowanie. Mogą powiedzieć: „Czy to rzeczywiście tworzy wartość dla firmy? Poświęcamy na to mnóstwo czasu, energii i zasobów, dlaczego trwa to tak długo?” Projektanci muszą więcej myśleć o cyklu biznesowym.

Jeśli Apple dostarczy telefon — sprzęt, który ma problem — może to kosztować ich miliardy dolarów, ale jeśli oprogramowanie zostanie wysłane i wystąpi problem, możemy go po prostu załatać, naprawić i wysłać ponownie. Podejście do procesu w ten sposób pozwala nam bardziej elegancko wrócić do cyklu prac rozwojowych.

Projektanci mogą również spróbować wypełnić lukę między tymi dwiema grupami, angażując inżynierów w proces projektowania na wczesnym etapie, aby czuli się uwzględnieni we wczesnej fazie tworzenia pomysłów, a nie tylko na dalszych etapach. Projektanci mogą powiedzieć: „Wpadliśmy na ten genialny pomysł, zrób go dla nas!” i to sprawia, że ​​programiści czują, że nie są częścią procesu tworzenia pomysłów. To tylko ręce, a ktoś inny to mózg.

Najbardziej dysfunkcyjne relacje między projektantami a programistami mają miejsce, gdy istnieje wyraźny podział pracy. Im więcej zaczyna się mieszać i te zespoły współpracują ze sobą, tym lepiej. W rezultacie istniałoby wiele perspektyw i współwłasności, co jest naprawdę kluczowe dla efektywnej współpracy projektantów i programistów.

O lepszym zrozumieniu przestrzeni siebie nawzajem…

Co zespoły mogą zrobić, aby lepiej zrozumieć swoją przestrzeń? Czy projektanci powinni zapoznać się z rozwojem i odwrotnie?

Po pierwsze, projektanci i programiści mogli więcej rozmawiać z klientami i wspólnie dowiedzieć się o problematycznej przestrzeni . Mogli rozmawiać z trzema do czterech klientów rano przy kawie; każdy mógł się bardzo szybko nauczyć i dojść do wspólnego zrozumienia obaw.

Po drugie, jeśli chodzi o proces pracy, ważne jest, aby projektanci i programiści posiadali — może nie płynność — ale rozumieli nawzajem swój język. Nie chodzi mi o to, że projektant musi umieć kodować lub że programiści muszą opanować typografię, ale przynajmniej istnieje wspólne zrozumienie.

Gdyby projektanci mogli opisywać rzeczy w języku zrozumiałym dla programistów — „to a to nie działa, a to jest złe dla biznesu” — wtedy programiści szybko zrozumieliby problem. Nie jest to coś, co przychodzi projektantom naturalnie, ale muszą lepiej komunikować wartość swojej pracy w ujęciu ilościowym , a nie tylko jakościowym . Zespół sprzedaży, zespół marketingowy, inżynieria, produkt, dyrektorzy, wszyscy ci ludzie mówią w liczbach, mówią ilościowo .

To powiedziawszy, wierzę, że projektowanie przynosi coś bardzo wartościowego, że są rzeczy, które się liczą, których nie można policzyć. Doświadczenie klienta, radość, miłość do produktu są bardzo cenne i trudno to oszacować.

Może to być jednak wymierne, w dalszej kolejności ten komponent jakości przyniesie wymierny zwrot z inwestycji.

Tak, możemy obniżyć koszty obsługi klienta dzięki projektowi, możemy zmniejszyć churn, możemy zwiększyć szybkość onboardingu. Posiadanie takich metryk, na które warto zwrócić uwagę, pomaga projektom dostosować wysiłki do celów biznesowych. Im więcej projektanci będą w stanie to zrobić, tym bardziej będą zrozumiani. Im bardziej wzornictwo jest cenione w firmie jako przewaga konkurencyjna, tym większy będzie potencjał do cięższych inwestycji.

O pułapkach współpracy projektantów i programistów…

Jakie są niektóre z największych pułapek, na które napotykają współpracujący ze sobą projektanci i programiści?

Jedną z największych pułapek jest brak wspólnego języka, brak wspólnych celów i bardzo nieproporcjonalne wskaźniki. Czasami istnieją zespoły wielofunkcyjne z jednym projektantem i 75 inżynierami. Brzmi to szalenie, ale to dość powszechne.

Zdecydowana większość tych sytuacji nie jest dobra. Ten samotny projektant jest emigrantem. Są obcy w obcym kraju, w którym nigdy nie pasują do kultury… a ich system wartości różni się od systemu wartości wszystkich ich kolegów.

W takim środowisku argumentacja za funkcją UX jest niezwykle trudnym wyzwaniem dla projektanta: „Powinniśmy mieć tę animację w produkcie, ponieważ stworzy ona bardziej przekonujące wrażenia…”, podczas gdy 75 inżynierów mówi: „To o 250 więcej linijki kodu i dwa dodatkowe dni pracy. Czy naprawdę warto?” I prawdopodobnie nie jest. Dla nich będzie to wyglądać jak „lukier”. Ale te animowane mikro-interakcje z projektantem UX naprawdę kształtują wrażenia klientów. Nie są jedyną rzeczą, ale są ważne.

Kiedy masz te nierówne proporcje między projektantami a programistami, staje się to naprawdę problematyczne. Są jednak rozwiązania. Firmy takie jak Slack rozwiązują ten problem za pomocą „sparowanego projektu”. Jeśli w jednym zespole jest jeden projektant na 10 inżynierów i ten sam stosunek w innym zespole, ci indywidualni projektanci spędzają około ośmiu godzin tygodniowo pracując razem, prezentując sobie nawzajem rozwiązania: „Oto jak rozwiązuję ten problem, czy to ma dla ciebie sens? Czy jest na to lepszy sposób?” Mogą pomóc sobie nawzajem uwolnić się i nie czuć, że są na wyspie.

O projektantach, którzy podkreślają znaczenie UX…

W jaki sposób projektanci mogą podkreślać znaczenie projektowania skoncentrowanego na człowieku z programistami, którzy tak naprawdę nie rozumieją HCD? Na przykład, w jaki sposób projektanci przekazują, że dodawanie funkcji niekoniecznie służy klientowi, że wrażenia z używania produktu są ważniejsze niż jego cechy?

Jest na to kilka skutecznych sposobów. Większość projektantów prawdopodobnie zrobiła to w nieefektywny sposób, mówiąc bezpośrednio programistom: „Hej, dodanie większej liczby funkcji nie poprawia wrażeń. Ludzie mówią, że tego chcą, ale tak naprawdę to tylko komplikuje produkt”, a programiści prawdopodobnie odpowiedzą: „Nie sądzę, że masz rację, to opinia. Słyszymy to od naszych klientów, więc powinniśmy za nimi podążać”.

Najlepiej nie zajmować się tym bezpośrednio, ale zrobić to z boku i powiedzieć: „Zrozummy lepiej razem problematyczną przestrzeń”. Kupiłem dla nas jutro lunch i umówiłem się, że pokażę Wam pięciu naszych klientów korzystających z naszego produktu.

Widziałem inżynierów skręcających się w fotelach, gdy obserwują klienta, który faktycznie używa produktu, i uświadamiają sobie: „Stworzyliśmy coś, co jest dość trudne w użyciu, a ludzie są z tego powodu sfrustrowani”. Inżynierowie chcą wykonywać świetną pracę, podobnie jak projektanci. Często po prostu nie mają możliwości zobaczenia wyników swojej pracy.

Prawdopodobnie słyszałeś o głoszeniu Jeffa Gothelfa, że ​​powinniśmy koncentrować się na „wynikach, a nie rezultatach”. To kolejny sposób, w jaki możemy przeformułować nasze myślenie, że wynik to: „dostarczyliśmy jeszcze pięć funkcji” w porównaniu z wynikiem: „zmniejszyliśmy liczbę rezygnacji o 10%”.

O przyszłości współpracy projektantów i programistów…

Rozmawiasz z wieloma firmami i widzisz, jak wiele zespołów projektowych i programistów pracuje razem. Zmieniają się narzędzia, środowiska i metodologie. Jaka przyszłość czeka relacje projektant-deweloper?

Rozwija się słonawa woda — gdy woda słona i słodka mieszają się razem — następuje połączenie narzędzi inżynieryjnych i projektowych. Zamiast procesu, który wydaje się być przekazaniem, w którym wszystko, co jest projektowane, jest tutaj, a wszystko, co inżynierskie, jest tam, zaczynają się łączyć.

W tym zakresie widzimy, jak projektanci spędzają dużo czasu w Jira, myśląc o historyjkach użytkowników, a także zaczynają myśleć z inżynierskim nastawieniem. I vice versa, widzimy inżynierów używających narzędzi takich jak InVision Inspect, gdzie widzą specyfikacje i awarię systemu projektowego oraz rozumieją komponenty tego, jak to wszystko do siebie pasuje. Dzięki tym narzędziom i połączeniu dyscyplin rozwija się wspólne zrozumienie.

Niezależnie od tego, czy jesteś programistą, czy projektantem, możesz zacząć rozumieć perspektywę swojego kluczowego partnera. Nie oznacza to, że jako projektant musisz być doświadczonym programistą. Ale nie zabije projektanta, jeśli będzie wiedział trochę o tym, jak używać Gita i jak napisać trochę HTML i CSS, może trochę JavaScript. Pomoże to projektantom zrozumieć, w jaki sposób rzeczy są budowane, i wesprze lepszą współpracę projektantów i programistów.

Dalsza lektura na blogu Toptal Design:

• Jak podejść do projektowania dla programistów
• Rozmowy o projektowaniu: Badania w działaniu z Caitria O'Neill ., badaczką UX
• Rozmowy projektowe: emocjonalnie inteligentny projekt z Pamelą Pavliscak
• Rozmowy projektowe: dążenie do projektowania opartego na wartościach z Nickiem Disabato
• Jak przejść od UX Designera do UX Consultant