Potrzeby kontra współpraca. Jak wytłumaczyć współpracownikom własne potrzeby projektowe?

Badania potrzeb użytkowników są nieodłącznym elementem badań UX. Czy można zatem, bez nich zrobić wartościowy projekt? Czy możemy bez tego udzielić solidnej rady? Chyba wszyscy zgodzą się, że nie. Jednak… jak często Tobie — drogi designerze, deweloperze, managerze — zdarzyło się pójść na kompromis?

Nie, nie będę namawiała Cię, żeby odpuszczać lub stawiać na swoim za wszelką cenę. Zależy mi jedynie, abyś w swojej codziennej pracy nie zapomniał o swoich potrzebach i o głównym założeniu naszego zawodu.

Komunikacja w zespole

„Projektowanie może opierać się na estetyce swojego medium, a rozwój może opierać się na kodzie, ale oba wykorzystują teorie wydajności do tworzenia efektywnych wyników” – mówi Cassie McDaniel, wiodąca projektantka UX Mozilli w swoim znakomitym artykule Smashing Magazine na temat współpracy między projektantami i twórcami.

Najlepsze kreatywne projekty wynikają z podziału obciążenia, ale utrzymują bliskie relacje między wszystkimi członkami zespołu. W przedsiębiorstwie efektywna komunikacja może być trudna, biorąc pod uwagę ogromną liczbę zespołów i niefortunną rzeczywistość biurokracji. Komunikacja jest niezbędnym elementem każdego udanego projektu. To właśnie ona prowadzi do celu nas i naszych potencjalnych klientów. Chociaż projektanci mogą nie rozumieć w pełni cyklu programowania, ważne jest, aby traktowali programistów jako członków tego samego zespołu ds. Produktu — w przeciwnym razie twój projekt padnie ofiarą niepotrzebnych kompromisów i przykrych niespodzianek a Ty sam, po długiej i owocnej pracy spojrzysz na efekt końcowy krytycznym okiem. Burza mózgów jest wrażliwym procesem, w którym ludzie zastanawiają się nad sobą i mogą osobiście przyjąć odrzucenie. Wspieraj środowisko otwartości i koleżeństwa, ponieważ zawsze lepiej jest mieć zbyt wiele pomysłów niż ich za mało.

Nie zawsze łatwy kompromis

Projektanci i programiści mogą wyrażać swoje pomysły w różny sposób, ale pamiętaj, że każdy ma na uwadze najlepszy interes projektu. Kompromis jest częścią współpracy i nie możesz brać niczego osobiście. Jako projektant Twoja rola nie ogranicza się tylko do projektowania. Programiści mogą napisać kod, ale jest to tylko środek do osiągnięcia celu – ten „koniec” jest produktem końcowym, a nie produktami dostarczanymi. Jeżeli jesteś w trakcie projektu, nie uczestniczysz w nim od początku lub po prostu wcześniej nie chciałeś nic w swojej pracy zmieniać — dobrym momentem na dyskusję ze współpracownikami będą testy użyteczności. To one mają na celu wskazanie problemów lub potencjalnych obszarów problemowych, ale nie zawsze generują rozwiązania. Dlatego konieczna jest praca zespołowa i dalsza dyskusja w celu wypracowania najlepszych, indywidualnych rozwiązań.

Budowanie zaufania

Przekazywanie i otrzymywanie opinii jest dowodem na to, jak dobrze współpracujesz z programistami. Po pierwsze, sposób, w jaki wzajemnie się krytykujesz oraz stopień, w jakim te krytyki są realizowane, jest od razu wyznacznikiem tego, jak dobrze współpracujesz. Ponadto masz opinie od innych — przede wszystkim od użytkownika. Zacznijmy od omówienia opinii w zespole, a następnie zapoznaj się z otrzymywaniem opinii od użytkowników. Idealnie, ze względu na te same cele biznesowe, projektant i programista powinni mieć możliwość dzielenia się i wygłaszania krytyki bez incydentów. Po prostu kolejny mechanizm dobrze naoliwionej maszyny. Jednak w rzeczywistości wszyscy jesteśmy tylko ludźmi, a uczucia i ego sprawiają, że dzielenie się opiniami jest nieco niepożądane. Innym skrótem do budowania zaufania jest zapewnienie, że niektóre odpowiedzi nie są rejestrowane. Informacja zwrotna jest tak przydatna, jak uczciwa. Zmniejszenie presji reperkusji pozwoli deweloperowi mówić szczerze. Otworzy to wiele drzwi na temat potencjalnego ryzyka i prawdziwej krytyki, które, choć nieprzyjemne, są najlepsze dla projektu. Jak sugeruje Goodwin, może się okazać, że niektórzy programiści traktują projektantów ostrożnie ze względu na ich wcześniejsze doświadczenie w realizacji prawie niemożliwych projektów wyłącznie ze względu na oryginalność. Doskonale podkreśla, że ​​zamiast pytać, co jest wykonalne, a co nie, pytaj, co jest trudne i dlaczego. To niewielkie ulepszenie języka może uspokoić umysły programistów, którzy w przeciwnym razie mogliby odczuwać presję, by zaangażować się tak wcześnie w procesie opracowywania produktu. To, jak wyjaśnisz swoją opinię — nie tylko w formie frazowania, ale w kontekście — wpłynie na sposób jej otrzymania. Jedną podstawową zasadą jest unikanie zbyt wielu szczegółów lub żargonu, które mogą się mylić. Projektanci i programiści często mówią różnymi językami, więc staraj się wyrażać swoje pomysły w sposób laicki, aby każdy mógł zrozumieć.

Cykl projektu

Jako projektant Twoim zadaniem jest nie tylko tworzenie perfekcyjnych pikseli, ale także wyjaśnienie, w jaki sposób działają. Staraj się budować zdezynfekowane makiety, które każdy może zrozumieć. Wszystkie strony powinny aktywnie pracować nad wyjaśnieniem swoich zamiarów i postrzeganiem każdego problemu z punktu widzenia innych. Zachowaj jednak ostrożną równowagę między uczeniem się, jak działa kod, a uczeniem się kodowania. Podczas pracy nad dużymi projektami korporacyjnymi wszyscy członkowie zespołu powinni być zaangażowani na wszystkich etapach całego procesu. Najlepszym sposobem na płynną współpracę jest użycie narzędzi i odpowiedniej terminologii. Każdy projektant powinien zapoznać się z procesem rozwoju. Podstawowa wiedza o tym, jak naprawdę działają interfejsy, może poprawić jakość makiet projektowych. Podobnie programiści powinni zapoznać się z językami projektowania i przewodnikami po stylu, aby wizualnie komunikować swoje pomysły.

Otwarta współpraca i komunikacja to najlepszy sposób na przeforsowanie pracy nad projektem poprzez utrzymanie konkretnego poziomu koncentracji. Mamy nadzieję, że te wskazówki i zasoby pomogą Ci i członkom zespołu współpracować zgodnie, kładąc większy nacisk na każdą fazę kreatywnego projektu.