Коммуникация с командой Ч.2

Первая часть тут

Общаемся с разработкой

Бывает такое, сидишь себе на очередном грумминге с разработкой и тут начинают сыпаться странные термины «микрофронты», «апи», «дергать ручку», «кафка». Сидишь и думаешь — Чегоооо бл#*ь? Если так, то этот лонгрид спешл вор ю.
 

Сразу спойлер: я не разработчик (дизайнер), никогда им не была и имею поверхностное представление о работе кода. НО, даже такого уровня достаточно, чтобы не впадать в тильт на рабочих созвонах и уверенно отстаивать свои идеи.
 

Итак, зачем дизайнеру понимать термины разработки? 

Первое и самое базовое — так быстрее вникать в задачу. Когда вам приходит таска, а из информации только схемы бизнес-процесса и куча писанины что с чем связывается и кто что дёргает, приходится тратить добрые часы на выяснение. 

Умением читать аналитические диаграммы (сиквенсы процессов) вы упрощаете себе жизнь в 10 000 раз. Вам не нужно отвлекать разработку, не нужно ставить созвоны на пояснения странных слов. Просто выписываете текстом, что вам не ясно из процесса и идете обсуждать предметно. Экономия времени и вам и команде 

Пример диаграммы

Еще пример

Второе и не менее базовое — появляется понимаете, о чем говорят ваши коллеги. Следовательно, лучше знаете свой продукт и его ограничения . Теперь гипотезы генерятся качественнее.

Третье — вытекает из второго, теперь вы можете проектировать лучше и точнее. Нет ничего обиднее, чем потратить спринт впустую, потому что не учли тех. особенности. Нарисовать можно все, но не пошлют ли вас ваши же разрабы?))  Проектируя лучше и точнее, ну вы сами знаете, лучше будет опыт и вот это все… 

Четвертое — уважение в команде. Сколько написано статей про передачу макетов, термины дизайна для недизайнеров, кажется уже все всё знают. Только дизайнеры почему-то не особо хотят вникать в смежную предметную область и предпочитают сидеть в свое мани-мирке. Без обид. Я сама так делала до недавнего времени.

Показывая заинтересованность разработчику, вы растопите его сердце и он станет вам лучшим другом, будет активнее к вам прислушиваться, начнет читать ваши спеки и просто позовет пить пиво вместе и согласиться на дизайн-ревью) Проверенно.  

Заботливо собрала для вас понятные видео и статьи о базовых терминах в разработке:   

И не забываем
Если вам ничего не понятно, конечно спрашивайте у разработчика, это нормально. Вы точно не покажитесь глупым, скорее наоборот (но сначала попробуйте погуглить). Взаимный интерес к работе друг друга и поддержка сильно влияют на конечный продукт.

@OpenSource_ux
Лайк, шэр, подписка))