Я не мог в своих рассуждениях обойти стороной дизайн. Потому что дизайн это часть фронтенда, вот возьми оторви дизайн. От фронта и получишь Node.js на сервере. Но мы же тут обсуждаем другие темы
Так вот из-за того что фронтенд и дизайн не разделимы. Остается важным взаимодейстиве разработчиков и дизайнеров. Позиция дизайнер всегда прав, или разработчик всегда прав. Это очень узское место.
Смотрите.
Мы покупаем глазами, тоесть если будет лежать два яблока, одно вкусное другое, нет. Мы возьмем то которое красивое. Соственно мы являясь чуть более развитиыми чем все остальные млекопитащие, имеем ряд слабостей. И хоть мы и считаем, что поступаем рационально / правильно. Зачастую это не так.
Так вот картинку поставлет дизайнер, возможно ее продают какому то "заказчику". Вот о скажем заинвестировал нам за счет картинки x$, неважно. Мы начинаем считать, что он собственно и должен получить такой дизайн. Только продукт. Только на JS / HMTL / CSS + что то там на бэке.
Но это же не так. Он же хочет получить инструмент - такой же хороший как молоток. Только решаюший какуюто другую задачу, или кейс который навязали ему сэйлы. И вот драфтовый маркетинговый дизайн скорее всего неучитывает миллион нюансов, которые ты узнаешь разрабатывая фичу. И как бы возможно этот дизайн хорош на плакатах, но прям адово сложный в реализации, и реально неудобный при использовании его каждый день.
Надо же стараться жить дружно. Например дизайнер тратит X времени на создания присэйловой штуки. И 2X, на создание типо того дизайна что мы будем делать в проекте. То девелопер потратит от 10X - 50X на реализацию. И если UX в дизайне плох, непродуманы места для дополнительных контролов (на будующее). А так же поведение дизайна при эктримальных ситуациях, много данных / мало данных. Маленький экран и тп.
То вот когда мы начнем переделывать дизайнер потратит X, так как у него уже будут наработки, будет больше практически готовых требований, с набросками решений. А вот для разработчика уже будет двойная цена 20X - 100X. Переделывать в коде оч дорого.
В идеальном мире - дизайнер обладет полным набором данных, может провести UX исследование, с UX специалистом. Это может быть один человек. Anyway.
Он так же как разрабочик должен говнякать прототип и согласовывать с разработчиками фронта. Возможно получая требования в тексте. Они в месте ищут хорошее решение, подключая бэк.
Мне очень нравиться как внедрили кросс дизайн в яндексе. 10 продуктов, о кторых я знаю, парочка продуктов. Переросли в отдельные компании и были проданы. Но везде все по брэндбуку. У них не может появится какого то UI, абстрактного коня в вакууме, который как бельмо на глазу.
Я понимаю, что тут виноваты разработчики а так же люди из бизнеса, которые пинками форсируют появление той или иной фичи. И вот, я как то общался с парнем из Яндекс денег. Общение с ним показало мне как важно внедрять некие весчи такие как BEM на увроне идеалогии.
Например мы говорим. Ребята нам надо работать чуть больше, это важно для нашего бренда. У нас все размеры кратны 8. В дизайне, и тп и тд. Давайте использовать идеалогию БЕМ. А потом мы идем к Дизайну и там это навязываем.
Мы делаем брэндбук, это как канституция, ее можно распечатать и пложить перед глазами. Разработчики бьют по рукам дизайнера, дизайнер разработчиков.
C течением времени, основные цвета, основные размеры, шрифты. Въедаются на подсознании. Разбуди вас ночью и вы расскажете наизусть 6 цветов яндекса в hex, rbg, hla формате.
Вообще внедрение таких методологий важно. Так как их легко изучить. Zero cost. Их легко поддерживать и сопровождать. Не надо изобретать велосипеды. Просто все должны это вобрать в себя через код ревью.
Сейчас например есть: storybook. И дам можно напрягать дизайнеров им пользоваться де изменений экспериментов и тп и тд.
Я лично считаю, что если ты дизайнер, приложений - ты должен быть вовлечен в разработку приложений, шарить достаточно что бы кое как написать приложение. Аналогично для веба, VR, кухонной техники, одежды.
Если ты просто графический дизайнер то без пониманий базы в голове у тебя всегда будет на выходе, что то с виду красивое но на деле отвратительное. И к сожалению ты не сможешь понять где же проблема зарыта. Невозможно найти проблему из нутри.
Девопсить модно везде, теперь и в дизайне designops-airbnb, для решения проблем большой вовлеченности в разные процессы на разных позициях в разных частях приложения. И синхронизации между ними. Покрайнеймере выглядит любопытно.