UX среща в планината – когато UX-ът се сблъска с dev-a

През изминалия уикенд (29.06.2024г.) бях поканена на една неконвенционална среща или по-конкретно – на неконвенционална локация – UX среща в планината, организирана от UX България.

Организирана за втора година, срещата събира дизайнери (и не само) и ги отвежда на user journey-та в полите на Витоша. Извадени от комфортната си зона (а може би планината не е извън тази зона?), хора от различни възрастови групи, от различни компании и с различен опит обменят идеи, говорят за софтуер и споделят както несгоди, така и успехи.“

Сигурно вече се питаш – какво прави един developer на такава среща?

Като човек с над 11 години опит в сферата на уеб разработването смея да твърдя, че съм видяла много – неясни процеси, липса на процеси, промяна на дизайн система в последния момент, липса на дизайн система, дизайн, който е невъзможно да бъде реализиран (макар и в програмирането да няма невъзможни неща), недообмислени интеракции, множество вариации на един и същ компонент с минимални разлики, 50 нюанса сиво (не, не книгата :D) и какво ли още не. (Допълнете в коментарите какво пропускам, защото знам, че има още.)

Вярвам, че навременната и ясна комуникация е предпоставка за далеч по-малко проблеми от описаните по-горе. А как се стига до тях?

Има ли ябълка на раздора?

Нека ти дам една ситуация, погледната през две различни позиции – тази на дизайнера и тази на разработчика.

Дизайнер: след подробна discovery фаза съм създал иновативен, интерактивен и креативен дизайн за този проект. Всичко е tailor made и отговаря на нуждите на бизнеса. Интеракциите следват потребителската пътека и изпълняват целите си. Цялото съдържание е организирано по начин, който следва определен ред, който пък е лесен за разбиране както от страна на потребителя, така и от страна на редактора на съдържание. Нямам търпение да го видя резлизиран!

Разработчик: този уебсайт трябва да е модулен, как да имплементирам тези две секции в два автономни блока, след като са обвързани с UI елементи; хм, тук има transition на background от един цвят в друг при скролиране, но какво ще стане ако (аз или клиента) разменя местата на секциите? Можех да си спестя всичко това, ако бях видял/вникнал в дизайна преди да започна.

Има ли виновен?

Не. Нито едно от звената не носи пряка и еднолична отговорност за забавяне, преправяне или в най-лошия случай – провал на даден проект. Но има начини за избягване на ситуации като изброените по-горе, както и за създаване на един по-бърз и ефективен процес по разработване на проекта, така че крайния резултат да удовлетворява всички замесени страни.

Как да подобрим процесите и да ги направим по-ефективни

Тук се изкушавам да кажа само една дума – КОМУНИКАЦИЯ.

Но това далеч не описва всичко, което е важно да се случва при и между двете звена, а именно:

Дизайнерите трябва да разбират какво правят разработчиците

Не, тук не казвам, че всеки дизайнер трябва да може да пише React компоненти, да създава сложни изчислителни функции, или пък да пише комплексен Sass.

Добре е обаче един дизайнер да знае основите на процесите, през които минава техният дизайн, за да се реализира в уеб, както и технологиите, които се използват. Такива технологии са: HTML, CSS и JavaScript.

В началото на тази година проведох три обучения (workshop-и), по време на които превръщахме дизайн, реализиран във Figma, в интерактивен уеб сайт. Множество UX/UI дизайнери се включиха тъкмо защото бяха осъзнали нуждата да научат повече за процесите при разработка и реално какво се случва с дизайна им, когато попадне в ръцете на разработчика.

Колаборация на ранен етап

Друг важен аспект от подсигуряването на лек и безпроблемен процес по разработването на даден проект е своевременната колаборация между дизайн и дев екипите (хората).

Няма да те карам да си го представяш, давам ти пример от живия живот: дизайнерът се вдъхновява от няколко сайта в AWWWARDS, създава интерактивен дизайн, който се влияе от прогрес на скрол по страницата от страна на потребителя и няма търпение да го види имплементиран. Стигнал до ръцете (или монитора) на разработчика, дизайнът претърпява множество промени – дали заради tech stack-a, който не е бил комуникиран в началото, дали заради естеството на проекта и как ще се администрира и още куп причини.

За да се избегнат подобни ситуации е критично важно разработчика (или представител на екипа, ако са повече души) да присъства на срещи дори на ниво wireframes. На такъв тип срещи обикновено се дискутира кое е изпълнимо и кое – трудно изпълнимо, кое би повлияло на скоростта на зареждане, кое би било предпоставка за усложнение по време на разработка и т.н. Все въпроси, чийто отговори накланят везните в дадена посока – дали по-дълъг срок за разработка, дали по-голям бюджет…

Разработчиците трябва да имат достъп до дизайн проекта

Още от момента на стартиране на даден проект е добре разработчиците да имат достъп до неговия дизайн (обикновено до Figma проекта). Добре е да има и ясно дефинирана и лесна за използване система за контрол на версиите (да, дизайнерите също използват такава, в коментар представители на този отдел могат да разкажат повече).

Зелена светлина от разработчик = показваме на клиент

Преди да се покаже дизайн на уебсайт, дизайн на страница, или дори отделен компонент на клиент, има една важна стъпка, която не бива да бъде пропускана – съгласуване с разработчик кое е реализируемо и кое – не.

Представи си следната ситуация – дизайн екипа работи по нов прототип, project manager-a се влюбва в идеята и е нетърпелив да я покаже на клиент, за да дискутират. Клиента също се очарова от концепцията и вече си я представя имплементирана в проекта си. След което отива и към дев екип за изпълнение. Но там се появява спънка – имплементирането на този даден прототип ще усложни проекта х10, или пък ще забави стартовата дата с еди-колко-си-дни.

По-добра комуникация = по-лек за изпълнение и по-приятен за работа проект

На края на деня всички ние търсим удовлетворение от работата си и от това, което сме създали. Когато подсигурим добра комуникация с колегите си от различните звена и ясно дефинираме процеси, които да ни помагат, а не пречат – това удовлетворение няма риск да бъде опорочено.

Лично за мен най-голямото удовлетворение е когато чуя дизайнера да каже „точно така си го представях„.

Вместо зкалючение

UX срещата в планината ме накара да се замисля колко важно е да общуваме – да споделяме идеи, да бъдем поставяни в неформална среда, да сме любопитни за работата на другите.

Специални благодарности към Милен Донев както за поканата, така и за това, че ме допусна и представи пред едно изцяло ново за мен общество, с което има какво да си дадем взаимно.

P.S. Обучения сезон есен ’24

През октомври 2024 започва новият сезон с обученията на {dev} blondie; Планирала съм ви модулна програма, състояща се от 5 обучения, като всеки може да си избере нещо за себе си, или пък да мине през пълната пътека на front-end разработчика.

Запиши се в списъка с абонати, които първи ще научат за новата програма.