Дизайнеры vs. Девелоперы

Эту тему стараются обходить стороной и не озвучивать, но ее жаркое обсуждение втайне продолжается за закрытыми дверями отделов IT-компаний. Слышны колкие шутки, негодование, жестокая критика, циничный сарказм и личные оскорбления. На повестке дня — извечное противостояние, на первый взгляд, абсолютно разных миров: дизайнеров и разработчиков.


© David Trawin

«Я не понимаю, ну неужели так сложно поставить это на пять пикселей ниже?!», «Откуда здесь взялся жирный шрифт?», «Почему нельзя просто сделать так, как я нарисовал?», «Почему это не работает так как мы придумали?»... «Ну это же программисты, они же только код писать умеют...»

«Это невозможно сделать!», «Для начала оно должно просто работать!», «Нам не нужны эти украшения», "«Какая разница будет оно зеленым или желтым?», «Вы надизайнили, а нам разгребать...», «Оставим пока как есть, а потом поменяем...»

Это то, что я слышу на протяжении 5 лет работы в IT-компаниях... Дизайнеры, получив задание, начинают «творить», частенько забывая о том, как это будет работать в конечном виде. Для инженеров, в свою очередь, дизайн кажется второстепенной, далеко не обязательной частью рабочего процесса.

Игнорирование разработчиками необходимости дизайна в общем рабочем процессе нивелирует ценность десятилетий, которые потратили дизайнеры, изучая вопросы восприятия и ежедневного взаимодействия людей и окружающих их вещей. Да, я говорю о дизайне прежде всего как о продуманном функциональном решении, которое, к тому же, эстетически привлекательно. Это не просто бессистемное создание чего-то красивого и пушистого. Очевидно, что продуманный UX, правильно подобранные цвета, формы, типографика, в конечном счете обязательно повлияют на восприятие продукта.

Люди не обращают внимания на дизайн, который игнорирует их...
— Frank Chimero (www.shapeofdesignbook.com)

Дизайнеры по своей сути это нонконформисты, не желающие принимать во внимание любые ограничения... причем из лучших побуждений. Мы выходим за рамки для того, что бы максимально применить наши умения и знания о том, как люди воспринимают «что-то» и взаимодействуют с ним. Конечно же, дизайнеры должны серьезно работать над тем, что бы предвидеть и осознавать сложности, с которыми придется столкнуться разработчикам, воплощая их идеи в реальность. Но это совсем не означает, что стоит переставать ломать стереотипы и нарушать традиции, придумывая инновационные решения.

Мне кажется, что разрешить извечное недопонимание довольно легко. Достаточно сделать лишь несколько шагов навстречу друг другу. Для начала, пересмотреть существующий процесс разработки продуктов. В настоящее время я вижу определенные проблемы в общем процессе. Дизайнеры придумывают и рисуют (хорошо если проводят юзер-тестирование), затем передают макеты и описание функционала инженерам. После этого начинается непосредственно разработка. На этом этапе связь между отделами становится все меньше и меньше. У дизайнеров уже новые задачи, продукт ушел в тестирование и происходит периодическое исправление ошибок. Это довольно стандартный процесс, который в результате приводит ко множеству претензий и недовольств со всех сторон.

К счастью, такие понятия как юзабилити и UX уже плотно вошли в сознание и дизайнеров, и клиентов, и программистов. Порой, разработчики разбираются в этих вопросах даже больше чем юзабилисты. Ярким примером этого является следование Human Interface Guidelines от Apple при разработке приложений для iPhone. Даже не имеющие навыков дизайна программисты, создают невероятно интересные идеи и концепции. И пускай они будут далеки от эстетики и удобства пользования, но называть их «плохим дизайном»... как по мне, — просто означает быть плохим дизайнером.

Как ни банально это звучит, но достаточно просто больше общаться. Нужно строить диалог между всеми командами. И, как мне кажется, это должно прежде всего лежать на совести дизайнеров. Именно с них начинается разработка продукта, и именно они должны стать ключевым связующим звеном в последствии. На этапе проектирования — общаться с инженерами о возможности реализации тех или иных концепций, выслушивать их идеи и предложения; во время передачи материалов и в процессе разработки — оказывать максимальную информационную поддержку; во время тестирования — принимать активное участие и следить за соответствием результата идее.

Важно помнить, что цель всех команд это разработка качественного и удобного продукта и что все работают на достижение общего успеха.

Для того, что бы сделать процесс общения еще более продуктивным и приятным, обеим сторонам следует изучить хотя бы основы НЕ своей специфики. Например, дизайнерам — понимать в целом, что будет происходить после передачи макетов, инженерам — почитать про типографику или теорию цвета. Мы все можем чему-то научить друг-друга, стать умнее и сделать этот мир лучше!

P. S. Но все-таки сделайте тот отступ на 5 пикселей ниже. :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




133 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

а я думав таке тільки з індусами-дизайнерами

эййй .. автор статьи потерял в этой связке верстальщиков, ИМХО без них связка дизайнер vs кодер не работает.

Если рассматривать только работу каждого специалиста, то разумеется у каждого будет своя правда. Однако если рассматривать продукт в целом, не думаю, что программист возьмет на себя ответственность сделать что-то в одиночку без UX специалиста, и, наоборот, юзабилист-дизайнер справится с проектом без программистов. На рынок продукт можно вывести (ну или сдать заказчику) только работая вместе. Исключение — только в том случае, если обе эти професссии чудесным образом сочетаются в одном человеке.

Ещё момент — не пытайтесь сделать идеально с первого раза. Лучше сделать как попало, тогда и изменения будут восприняты без лишних ссор.

это называется итеративный процесс :)

Итеративный процесс — это понятно. Но не всегда понятно наличие итерации именно на первом шаге. Например узаконить вариант дизайна, моитивируя согласованием с большой шишкой заказчика, и потом требовать его соблюдения. В то время как ещё и функицонал не до конца разобрали.

А именно на первых шагах зачастую и ставятся палки в колёса. Притом такие, что могут и проект завалить.

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

А еще хорошо бы различать шкурку (визуальный дизайн) и скелет (experience дизайн и информационную архитектуру). Первый может быть узаконен на ранней стадии как руководство по стилю. Второй же требует тщательной проработки и тестирования. На ранней стадии единственное, что можно согласовать, это набор основных дизайн-принципов.

Если сошлись на формулировке "руководство по стилю", вопрос выигран.

Гораздо страшнее, когда со стороны заказчика есть человек или подразделение, которое призвано контролировать исполнение, но НЕ ПОЛУЧАЕТ никаких выгод от внедрения, мало того - не получает никаких проблем в случае срыва сроков или вообще провала. Единственное что их заботит - чтобы не наказали.

Схема смерти примерно такова: у заказчика есть юзер - вполне заинтересованное лицо. Но жалуется он не в сапорт исполнителю, а в саппорт заказчика. Те фиксируют проблему. Для решения она передаётся в то самое "проверяющее" подразделение. И уже они выставляют претензию - которая как правило уже не содержит "лишних деталей" самой жалобы юзверя, а на N страницах витиевато написано "чтотонеработает-глючит-интернетпропал-иничегонеработает-когдасделаете-тывиноват-выввсевиноваты".

Ладно если бы это касалось гос.заказов. Но бывает попадается во вполне с виду жизнеспособных организациях. Хотя... это как рак: когда он очевиден, уже слишком поздно.

Вопрос лишь в том, чтобы на ранней стадии эти грабельки видеть, и если это действительно палки в колёса - глубоко в недрах своей конторы предсказать сценарий [риск] срыва проекта. И сделать так, чтобы эта зараза не передалась в собственную организацию.

А что бюрократия заразна - знаю точно, сам видел. Стоит только возложить потом этот срыв на конечных исполнителей - и тот кто возложил с удивлением для себя отметит, что "проканало", и последствии ещё не раз применит такое "решение".

Это общая проблема компаний, у которых не поставлен процесс разработки и которые сами не понимают для кого они работают.

Как сказал одни мой знакомый: "Мы здесь не для того, чтобы нравится начальству".

Проблема не в компаниях, а в людях. В человеческой природе. И обойти её очень сложно, даже понимая всё что произойдёт.

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

Что в действительности при этом наступает - смотреть фильм Брюс Всемогущий. Только в реальности потом и сам чёрт не развяжет эту петлю на шее компании.

Плюс сто пиццот тыщ главной идее статьи: достаточно просто больше общаться!

Пока эти конфликты идут — результат будет. Как только «умный» начальник запретит разговаривать на эти темы — топор войны уйдёт в подарок заказчику с саппортом. А то и вовсе зароют (вместе с продажами продукта)

Представьте себе на минутку, что боксёр на ринге исполняет чётко только то, что предписал ему тренер. Зрителям даже посмотреть будет нечего: первый раунд бой проигран.

А поводу борьбы Дизов и Прогерров, решается все очень просто Структура работы приложения это не дело Дизайнера, они зачастую только рисовать умеют. Вот и нечего им доверять это делать. В одном проекте прежде чем давать дизайнеру задание я собрал схематически приложение с предполагаемым функционалом, и дал дизайнеру задание просто отрисовать все состояния объектов которые он видит, но нет ...ть прибежал (не)удачник UX и вообще не глядя на мой труд сразу побежал рассказывать дизайнеру что надо переделать при чем переделать не согласно той структуре которую я давал, а именно отрисовку начала менять, при чем новая отрисовка требовала новых и нестандартных компонентов, НО МНЕ ОБ ЭТОМ НЕ СООБЩИЛИ!таким образом я два месяца ждал финальную версию дизайна так как (не) уважаемый UX все что-то лепетал дизайнеру про юзабилити, и заставлял переделывать дизайн (при этом менялась логика поведения компонентов), неопытный ПМ никак не препятствовал проделкам именитого UX приглашенного со стороны в проект. И вот получив через два месяца дизайн я был в шоке! Вся архитектура выстроенная мной была изменена, и все, что я кодил пока рисовался два месяца дизайн, оказалось бесполезным! В итоге я еще и оказался виноват, потому как проект делается уже три месяца и нет результата, я жил и ночевал в офисе неделю в прямом смысле слова. Проект сдал через две недели, меня оштрафовали, я был очень уставшим, а проект был не оттестирован и очень сырой.

Итого, чисто по человечески жаль инвестора, ведь:
1. Проект до сих пор спустя 9 месяцев после моего ухода стоит на месте если не похоронен окончательно и это при огромной рекламной прокачке по всему Киеву и в сети!!!
2. Релизы версий под андроид появились лишь спустя полгода после моего ухода (а работа начиналась над ними за 2 месяца до того как начал я, да и на маркете лишь один отзыв в размере 2 бала за 9 вылетов из 10 случаев запуска и это бета версия, при очень убогом интерфейсе, говорит сам за себя, а ведь меня типа уволили когда еще и альфы не было, хотя как оказалось я сделал за месяц то что другие делали год!!!), а под иос так и не вышли в свет (как по мне очевидно что из-за бездарности личностей руководивших процессом).
3. Та часть которую делал я считаю тоже в плохом состоянии так как никто ее не протестил и не пожелал нормально доработать (типа итак 3 месяца делал), не говоря уже о том что такое убожество только и можно что переделать, а не доработать :)

4. За что платил инвестор два месяца зарплату мне, пм, и дизайнеру, пока UX фантазировал на тему как же по его мнению должно все выглядеть, чтобы он остался доволен? На месте инвестора я бы заставил UX отработать зарплаты всех трех позиций, а ведь сумма где-то 6-7 косарей зелени и это без зп самого UX.

П.С. Если я такой плохой девелопер то почему в течении полугода после моего ухода ушли два серверных, дизайнер, и !!! UX c ПМ ушли :) При этом они успели похоронить еще один проект, который теперь тянет на себе другая девочка без всяких опытов ПМ и UX :)

МОРАЛЬ сей басни такова проблемы между дизайнерами и прогерами только там где нет нормального ПМ и типа навороченные UX, не дизайнера пилят, а еще до этапа отрисовки продумывают архитектуру юзеринтерфейс, обсуждая возможность ее реализации программистами именно в том виде как им видится :) Нуи дизайнерам кстати не мешало бы иметь мануал и описание основных компонентов, который используются в ЮИ, и описание всех их состояний, а то смотреть на финальную PSD просто страшно, я уж не говорю о том чтобы посадить дизайнера за тот же Flash Catalyst и заставить распарсить его гадкий psd «по полочкам» :)

А инвестору наука надо брать на такие проекты нормальных ПМ, а не ... в общем если у ПМ нет реального айти опыта и реальных проектов не сливайте деньги в трубу, а UX платите зарплату только по количеству скачек и положительных отзывов на маркете :)

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

Вы поговорили с тем UX, которого критикуете?

Во-первых не вижу смысла разговаривать с человеком, который не разговаривает, а высказывает да еще позволяя себе использовать ненормативную лексику :) Поработать с проф УХ я буду только рад, так как с удовольствием бы пополнил свой багаж еще небольшой сумочкой знаний :) Во-вторых моей личной обиды как таковой нет, так как я без проблем нашел новое место работы более перспективное, интересное, высокооплачиваемое и человечески относящееся :) Кстати возвращаясь к теме «а поговорить» — до того как ПМ и УХ (я считаю позорно смылись с проекта) в течении полугода с подачи этой парочки уволили (или сами ушли) контент менеджера, сеошника, флешера, дизайнера, двух серверных программистов ПРИ ШТАТЕ 8 человек!!! Т.е. 6 из 8 ушли из команды из-за «гениальной» работы двоих. Я бы не был столь критичен если бы этот гениальный ух-мастер не светился на разных докладах и не руководил киевским филлиалом типа специализирующейся фирмы по ух :)

Думаю, всем бы хотелось работать в команде, где лиды и не только всех дисциплин и направлений могут сесть за одним столом в обсудить рабочие вопросы. Мне бы лично этого хотелось.

Коментар порушує правила спільноти і видалений модераторами.

Сорри, но после: «Вся архитектура выстроенная мной была изменена»... из-за UI — возникла мысль про консерваторию.

Украинские UX лажа полная! Не буду называть фамилии, но это типа не последние люди и работают не в последних компаниях, но... в общем не буду никого поливать грязью, просто повторюсь Украинские UX лажа полная!

Очень содержательный и обоснованный комментарий.

этот человек перед хакатонами давал указания через ютуб :)

Специалисты по UX и прочему, давно заигрались, и в своей игре в нужность забыли об одном простом гении: Все гениально — просто.

И к тому же специалисты этого сайта меня убили своим не юзабельным дизайном! >

между дизайнерами и разработчиками должны обязательно находиться html верстальщики.

паттерны MVP и MVC всем в помощь и не будет надуманных проблем.

дело не всегда только в разделении труда.. перечитайте тему еще раз )

как веб разработчик согласен с Алексеем, между программистом и дизайнером есть верстальщик и проблемы отступа на 5 пискеселей меня не очень волнуют. с дизайнером вполне хрошие отношеняи, сео сотрудники досталяют больше забот, после их рекомендаций приходится неслабо перелопатить весь проект только потому что не по феншую для гугла.

но статья обобщенная для всей области разработки поэтому где то более актуальна, где то менее.

Очень правильно сказано. для разработки структуры приложения изначально очень важно взаимодействие дизайнера и разработчика. только дизайнер должен быть правильный. есть процесс оформления (красивостей по готовому продукту) — для этого достаточно подключить дизайнера на поздних этапах. А есть то самое страшное слово «юзабилити», которое, как ни крути, должно появиться в самом начале работы над проектом. чтобы не пришлось потом хвататься за голову и добавлять дополнительные кнопочки и поля, когда уже некуда, приложение уже как бы работает, и нечего тут ерундой стадать.

Мне кажется, что на момент начала проекта (project initiation) должна быть собрана команда из разных профессионалов: бизнес-аналитика (кто как не он может понимать клиента), дизайнера (по описанным бизнес-аналитиком юз кейсам предложить правильный функциональный дизайн приложения), архитектора и ТЛя (согласитесь, люди технические тоже важны — от забраковать бестолковые идеи, до выбора технологий довольно таки много ответственности ложится и на них). При этом к людям техническим стоит прислушиваться всегда, однако фильтровать, что они говорят. Ведь, программисты люди ленивые, им бы сделать попроще да из наработок, которые уже имеются. Если архитектор и ТЛ категорически против предложенного интерфейса, дайте им обосновать свое мнение. Если аргументы убедительны, отказывайтесь (да, пускай пострадает дизайнерская гордость). Если не убедительны, даже не думайте менять интерфейс. В таком противостоянии все забывают, что главное все-таки это проект, то есть сделать систему такой, какая нужна клиентам (а клиенты тоже люди, могут не объяснить как надо, что им нужно. Вот тут-то и пригодится бизнес-аналитик).

К сожалению ИТ сфера прямо наполнена «недооцененными специалистами». Работала и работаю с людьми, которые считают, что их не ценят так, как они того заслуживают. У самой иногда проскакивают подобные мысли. Исходя из этого, понимаю, что противостояние — это один из шагов выделиться, заставить кого-то воспринимать тебя как следует. Только от этого бывает хуже( Ну не будет программист считать дизайнера креативным и талантливым, если тот упрется рогом и не пойдет на конструктивный диалог.

Коментар порушує правила спільноти і видалений модераторами.

когда дизайнеры рисуют не просто картинку ради картинки а именно продуманный интерфейс — проблем вхаимодействия не возникает вовсе

Могу поделиться опытом, как решается эта проблема в гейм деве, где противостояние художник-программист особенно обостренно.
Основной фокус заключается в том, чтобы найти прокси-специалиста, который является наполовину дизайнером наполовину программистом. В геймдеве такие люди называются техникал артисты.
Найти такого человека довольно тяжело, но как только он найден, решается много проблем.
По большому счету, все сводится к тому, чтобы люди общались на одном языке, и в этом случае, специалист, который знает оба языка, упрощает всем жизнь.
Дальше уже дело техники, программисты объясняют свои ограничения и требования любым подходящим способом(документация, примеры, гайдлайны, да просто на пальцах) техникал артисту, и он уже в переваренном виде эту информацию предоставляет художникам.
Еще одно важное требование — работа художника прежде чем попасть в к программистам, должна быть просмотрена техникал артистом и на этом этапе решается 90% недоразумений.

Это конечно не решает проблем личностных отношений между программистами и дизайнерами, но по крайней мере это не мешает продакшену.

вечная борьба дизайнеров со всеми: дизайнеры vs печатники, дизайнеры vs технологи, дизайнеры vs художники... иногда дизайнеры vs заказчики и нередко дизайнеры vs здравый смысл... не надоело жаловаться? это профессия, которую вы выбрали, со своими достоинствами и недостатками. быть хорошим дизайнером значит также быть готовым к тому, что твою работу будут оценивать все, кому не лень. дизайн, как любая конструкция, имеет свое устройство, свои компоненты и правила по их применению. знай их, используй правильно, обосновывай грамотно собственные решения, и к тебе не будет претензий.
главное требование к работе дизайнера — адаптация выходного продукта к особенностям технологии с которой он работает. этим он отличается от художника, и именно поэтому не канают аргументы типа «я художник, я так вижу» (мы таких называли «творюками» за отношение к собственному творчеству). если ты не смог донести до следующего этапа конвеера, почему твои 5 пикселей так важны — ты не дизайнер, ты продвинутый пользовать фотошопа.

а польза знания типографики и теории цвета для рядового программиста — нулевая, если только он не хочет стать дизайнером. у девелопера своих проблем выше крыши, а тут ему еще разбираться чем Pragmatica отличается от Helvetica? или почему зеленый круче синего? пусть каждый занимается своим делом.

Простите, а где вы заметили, что бы кто-то жаловался? Лично я получаю удовольствие от работы. Конечно бывают разные моменты, но это не влияет на общее восприятие выбранного рода деятельности.

Исходя из вашего комментария, возник вопрос: почему

главное требование к работе дизайнера — адаптация выходного продукта к особенностям технологии с которой он работает.

, но при этом:

польза знания типографики и теории цвета для рядового программиста — нулевая

? То есть вы считаете одностороннее вовлечение в процесс нормальным? Почему вторая сторона не должна вникать в специфику?

совершенно верно, потому что первое есть requirements, а второе даже не nice to have. у дизайнера достаточно возможностей влиять на конечный результат, не привлекая для этого дополнительные ресурсы. вы же предлагаете, чтобы дизайнер на своем этапе делал работу на 80%, а остальные 20% (пропорции могут варьироваться) возложить на других. ибо если в UI спецификации размеры шрифтов и толщина линий указаны в пунктах (потому что в любимой программе дизайнера так установлено по умолчанию), а границы контейнеров и их аттрибуты не указаны вообще, то к дизайну приходится неоднократно возвращаться на различных этапах имплементации, а значит вовлекать недизайнерские ресурсы к работе, которой можно было бы избежать. почему вы считаете, что делать свою работу на 100% и сразу не есть вашей обязанностью? возможно, потому что вы избалованы безответственностью и безнаказанностью за собственную лень? к сожалению, стоимость исправления ваших огрехов трудно подсчитать.
у дизайнеров, работающих с материальным воплощением их труда, завершение работы над макетом есть рубеж, за которым начинается материальная ответственность, а за тираж, ушедший в брак по вине дизайнера, последнего могуть лишить половины зарплаты или вообще с позором выгнать с работы. почему, работая в полиграфии, я не считал для себя зазорным знать особенности растрирования и отличия между глубоким черным и чистым черным? работая с упаковкой, наведаться в цех и воочию убедиться, как толщина флексографической формы и диаметр барабана, на который она наклеивается, влияют на деформацию изображения. работая с шелкотрафаретом, лично поучаствовать в процессе смешения красок и ознакомиться с тем, как меняется цвет в зависимости от поверхности, на которую она наносится? и за большое количество лет пребывания в шкуре дизайнера мне ни разу не приходилось рассчитывать на дизайнерские таланты тех, кто воплощает в материю результаты моей работы.
собственно, а чем вы лучше? и за какие заслуги вам положены привелегии, которых требуете?

Руслан, мне кажется вы сейчас создали какую-то картинку абстрактного дизайнера в уме, который вам не нравится и метете всех под одну гребенку. Какие привилегии кто требует, вы о чем?

Попробуйте посмотреть на вещи с другой стороны. Все мы люди и люди бывают разные.

Конструктор розробляє геніальну машину, несе креслення на завод, де дядя Ваня за токарним станком чухає потилицю, і робить деталь А12 вдвічі меншою, а сусідню із складним профілем перетворює в пластину.

Щось подібне нагадує суперечка «чи має програміст дотримуватися замислу дизайнера». Дизайнер малює інтерфейс, добре, якщо хтось перед ним, або він сам проробляє так зване usability, дизайн узгоджується, можливо із участю програміста, і приймається. Від цього моменту дизайн має бути непорушним. Навіть якщо ради іншого кольору кнопки доводиться створювати іще одну табличку в БД. Немає проблем — ви сідаєте, виписуєте проблеми, підраховуєте час, не забуваєте складні місця в проекті, і «пред’являєте рахунок» менеджерам чи хто там у вас приймає рішення. Якщо, для прикладу, стільки часу вам не можуть надати, приймається рішення або урізати функціонал, або змінити дизайн. Але це уже не ваші проблеми. Дизайн розробник міняти не має права! Інакше отримаємо черговий, мільйонний по рахунку, компроміс між «хотіли» і «могли».

Дизайнер і програміст — творчі, але елементи вирішення проблем. Як на виробництві. Не треба створювати проблем, сприймаючи професії крізь призму «обкурених» митців та бородатих геніїв кодування. Є задача, її треба вирішити. І все.

Дизайнеров испортил квартирный вопрос доступ к широким возможностям электронных интерфейсов.

Дизайнер промышленных продуктов был ограничен стандартным набором форм, законами реального мира. С учётом массовости производства. Чересчур оригинальные дизайны невозможно было производить массово. Чересчур вычурное оформление не выдерживало испытания физикой. Появление электронных интерфейсов прорвало сдерживаемую суровой реальностью плотину креатива.

Подумайте, ваш продакт-аунер, прожект менеджер или заказчик согласится на затраты времени и ресурсов в виде создания таблицы БД для изменения цвета кнопки?

Дизайн не должен быть священной коровой, доступ к телу которой имеют только его смиренные жрецы-дизайнеры. Не должен быть цельновырубленным из хаоса произведением искусства. Он должен быть гибким, модульным, состоять из ладно подогнанных, но всё же компонентов подчинённых стандартам. Кнопка это кнопка, текстфилд это текстфилд, а не размытое облако цветных пятен. Разработчики через годы работы и головной боли шли к понятию рефакторинга. К этому же пришли и дизайнеры — редизайн требует бережного отношения к существующему содержимому привычному для пользователя. Стандарты это хорошо; слава яйцам, что что Эппл сделал существенный шаг в этом направлении.

Суммирую: дизайн и реализация продукта взаимозависимы.

Это как раз то, почему я и написал эту статью. Очень много проблем исчезают сразу, как только начинаешь смотреть на них с более высокого уровня, в частности с уровня конечного продукта. Если все хотят сделать, что бы было красиво, удобно, быстро, правильно, то многие личностные вопросы уходят на второй план. И начинается осознавание не временных/ресурсных (а-ля «мне на это потребуется миллион времени») затрат, а какое влияние это окажет на финальный результат.

Ні, напевне не погодиться. Але про таку проблему, про втрати в часі, в швидкодії, в гнучкості чи модульності ви повинні загодя, на стадії узгодження, попередити всіх, хто приймає рішення, в тому числі і дизайнера. Можливо, заходити до останнього на чай в кінці дня ще в процесі розробки дизайну. Щоб дизайн, як ви і сказали а я погодився, був гнучким, модульним і підігнаним компонентами, підпорядкованих стандартам.

Я про іншу болючу проблему — коли дизайн прийняли. Програміст отримує його в розпорядження, і починається «творчість» — тут посунемо вліво, тут заберемо рамку, кольору тут не треба, і так далі. Дизайн міняється. А мінятися він категорично не повинен. На етапі верстки/натягування функціоналу він повинен бути саме «священною коровою». Інакше отримаємо продукт, зручний програмісту. Складні, але ефективні вирішення підуть в корзину. А так не повинно бути. Але так, на жаль, є.

Я вважаю що дизайн то також ітеративного плану штука... Не варто задвигати складне спочатку. Нехай для початку буде «попроще». Напр: дизайнер намалював супер-дропдаун бокс — а засобами ХТМЛ неможливо таке відобразити. Программер почитає жостко мучитись з сss/html/js щоб добитись всього-навсього поведінки випадаючого списку. Воно того варте?

Конструктор который разработает «гениальную» машину каждую деталь которой дяде Васе придется изготавливать пол дня или которую Вася вообще не в состоянии изготовить, а изготовить ее может только Петр Захарович, который один на весь завод, будет уволен по причине профнепригодности. Дизайнер, если это конечно хороший дизайнер, должен представлять возможности технологий которыми его дизайн будет реализован. Тогда и проблем не будет.

По-перше, далеко не кожну деталь. По-друге, якщо цього вимагає конструкція, наприклад, одна деталь із складним профілем значно міцніша, ніж закручені-загвинчені-зварені, доведеться шукати того єдиного Васю. Мені не раз в радянській пресі та книгах про космос та авіацію та заводи, які власне втілювали все в метал, зустрічалися слова про цінних працівників, які одні на весь завод, і які незамінні. Так що кого звільнять, ще питання.

Якщо користувачеві буде зручно виконати певну дію за два ходи замість десяти, але для цього треба програмісту напружити свої звивини, значить доведеться напружити. Імхо, але дизайнерів, які роблять «речі в собі», і не здатні підлаштовуватися під можливості технологій, на порядок менше, чим програмістів, які вважають себе вправі вносити зміни з дизайн, якими б невеликими вони їм не здавалися. При чому за часту навіть без погодження.
Я програміст, якщо що.

«Это невозможно сделать!», «Для начала оно должно просто работать!», «Нам не нужны эти украшения», "«Какая разница будет оно зеленым или желтым?», «Вы надизайнили, а нам разгребать...», «Оставим пока как есть, а потом поменяем...»

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

У вас большое эго, не надо сидеть на шее — делайте свои продактс на своих баджетах, слабо?

На мой взгляд, чтобы устранить проблему, нужно:
1. Наладить правильный рабочий процесс
2. Понять,что дизайнер и программист видят все с разных сторон: дизайнер — со стороны того, как это вопринимается пользователем, программист — со стороны того, как это реализовать технически и как это будет работать. Оба ракурса — субъективны и являтся крайностями. Суть в том, что бы совместными усилиями сформировать максимально объективное воприятие.

Только тогда может получиться гармоничный продукт.

Очевидно, что продуманный UX,

Может UI ???

Сори я провтыкал! UX тоже бывает )

Я понимаю, как сложно работать с подобными людьми, но грамотную и логичную аргументацию никто не отменял. Главное, найти подход! Я уверен в том, что все решаемо.

интересно вообьще, а почему дизайнера должно интересовать, как вы будете это реализовывать? если дизайнер знает, что это вполне реализуемо, ну просто вот мож чуток сложнее, то почему это каким-либо образом должно трогать дизайнера? при этом программист считает себя в праве просить дизайнера перелопачивать все из-за того, что вот на эту штучку уйдет на час/день/неделю больше. ну и чо?
лучшие экземпляры пытаются найти компромисс и, допустим, попытаться что-то упростить, при этом не теряя в эстетике (которую при современной конкуренции нужно учитывать в гораздо большей степени, чем.. ну скорость, допустим). хотя нет, не так, лучшие, конечно же, просто делают. худшие же делают по-своему.

p.s. именно такие «гении», которых не интересует, как вы это сделаете (опять же, если это в принципе возможно) и не ищут компромиссов, а просто хотят получить то, что хотят, — как раз что-то и создают. неважно вообще, дизайнер это или кто.

Потому что от того КАК это будут реализовывать зависит напрямую и СКОЛЬКО по времени это будут реализовывать.

ну.. кому-то важнее «сколько», конечно, не спорю. тут весьма кстати приходится треугольник качество-сроки-цена

Ребята, надо искать консенсус и идти друг другу на уступки. Не бывает командной игры, если каждый тянет одеяло на себя, поверьте.

eval(

если дизайнер знает, что это вполне реализуемо,
)

false.

Для начала нужно хорошее ТЗ, о том как будет дизайн взаимодействовать с программной частью, и посредником между дизайнером и программистом должен быть хороший ПРОДЖЕКТ МЕНЕДЖЕР, а не м\ж -менеджер которая сама\сам толком тех.части незнает.

Т.е должна быть третья сторона принимающая решение и знающая основы и специфику работы обоих команд.

Кстати об искусстве и цели, есть еще связующее звено верстальщик, который делают то, что потом тот же программист может изменить, не говоря уже о «войне браузеров» которая будет еще долго холиваром.

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

Хорошее ТЗ — это из области советской фантастики, часто клиенты говорят «хочу как у них» и в процессе многое меняется.

Да, хорошего, адекватного дизайнера, также тяжело найти как и программиста...
Пока искал — попадались красавцы изучившие пару эффектов в photoshop’e и весь дизайн состоял из раскидывания картинок по экрану... На просьбу доработать, последовал ответ: «Рисовать я ничего не буду! Мы об этом не договаривались».
ИМХО. Хороший дизайнер, как минимум должен уметь рисовать от руки, а в идеале иметь художественное образование или просто быть художником. К такой базе подтянуть юзабилити.

Угу, прежде всего адекватного руководителя найти надо. Такого, который сможет и команду организовать, и поймёт, кого стоит оставить в этой команде, кого перевоспитать надо, а кого и выгнать не грех.

ИМХО дизайнер интерфейса и художник — это разные люди с разными скилами.

Хороший дизайнер (и вообще дизайнер чего?) не обязательно должен уметь рисовать но обязан уметь объяснить разработчику что должно получиться любым способом.

Как «чего» дизайнер ? Морды софта. Чего же еще .... Не женского же белья

очередная подмена понятий. я не смогу нарисовать даже птичку от руки. ок, даже еще проще — котика не смогу. но я хороший дизайнер. извините, если вызвала когнитивный диссонанс.

Прочитал статью и комментарии. Неужели, один я читал про MVC?

А при чём тут MVC? При любой архитектуре, скажем, веб-приложения с дизайном приходится иметь дело сначала верстальщику, а потом и программисту. Кто же ещё, так сказать, «натянет шкурку на данные»?

ИМХО: Нет. Это при жёсткой архитектуре или её отсутствии. Если есть архитектура проекта и используется паттерн MVC то действия разработчика и дизайнера могут быть очень слабо связаны, практически при хорошем проектировании дизайнер может вообще ничего не знать о работе разработчика.

Проблема с дополнительными полями, пикселами, шрифтами и т д, в этой парадигме, не существует. Но разработка архитектуры это затраты. Соответственно необходимо сравнивать затраты для конечной реализации на построение грамотной архитектуры и затраты на коммуникации команды в случае спагетти-кода. Если последние меньше, то надо больше корпоративов и теннисных столов в офисе.

Коментар порушує правила спільноти і видалений модераторами.

В ASP.NET MVC 3 я отдаю вот такое @TitleHome. Это может быть всё что угодно — перечисление объектов, текстовое поле, картинко, время, деньги — дизайнер видит это из контекста и подсказки. Мне абсолютно всё равно, что он с этим сделает — какую таблицу или див или график. Про шрифты, фон и скругленные уголки я тоже ничего не знаю. В чём наивность?

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

В том что дизайн это не только скругленые уголки, картинка на фоне и шрифты.
В твоём же примере. Ты формируешь некий

@TitleHome
. Ну и? Ты готов сформировать абсолютно любой?

Что значит любой? Есть ещё UI. Есть бизнес-логика приложения. Но дизайнер в общем случае получает жменю чистого контента и может делать с ним всё что хочет. В установленных рамках )

Дык, у тебя дизайнер работает с тем что получил. Это неправильный дизайнер. Ручной. Вы ему покреативить дайте — и вот тогда посмотрим как он порвёт все твои контроллеры.

Да нет же!
Пусть рвёт как хочет. В MVC хатээмэль теги, яваскрипт и сиэсэс. И жменя контента. Пусть в этих рамках рвёт что хочет. Разумеется если он не настолько «креативный» что кроме как во флеше (сильверлайт) его дизайн нигде больше реализовать нельзя.

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

Та блин. Ну и при чём тут MVC как панацея? Вью влияет на контроллер. Точка.

А если дизайнер сдерживает свой креатив — это другое.

Дизайнер всегда сдерживает свой креатив. MVC не панацея, но позволяет формализовать отношения дизайнеров и разработчиков до такой степени что они могут не знать о существовании друг друга.
Вью не влияет на контроллер, самостоятельно. Есть архитектор который проектирует UI и бизнес-логику. Появляются M и V и C. После этого дизайнер может резвиться.
Если дизайне хочет работать вне рамок технологии или приложения, то он может рисовать масляными красками или песком.
Если дизайнер подключится на стадии проектирования приложения то тоже ничего плохого не будет, хотя наверное он должен включаться после всех.

Я не спорю, но мне кажется, что MVC больше всего подходит для разрешения этого конфликта. Правда, требует затрат.

Посмотрите на CMS Drupal, как на пример успешной реализации паттерна и архитектуры MVC.
В этой CMS дизайнер может не знать как выглядит разработчик, но при этом сами «шкурки» могут быть какие угодно и уж точно разработчик не задаёт в Drupale шрифтов или положения контента.

Мне (программисту) наверное тяжело понять все эти проблемы из-за того, что жена у меня дизайнер UI и юзабилити специалист. А может и по причине того, что я всегда использовал стандартные средства представления или же сторонние. Но никогда не нуждался в нарисовывании чего бы то нибыло дополнительно. Или заказчик предоставлял, или пользовалось стандартное. Иконки рисовались в гимпе с прозрачностью — это максимум :-)

И не удивительно, ведь UI дизайн это ни разу не скругленные уголки и не яркие градиенты — это сбалансированный и продуманный лейаут, обеспечивающий своевременный доступ к необходимой пользователю информации и функциональности, предотвращение возможных ошибок и так далее. А стандартные или кастомные элементы — это всего лишь кирпичи, это то, что вы называете «шкурку натянуть». Чобы шкурка хорошо лягла, нужен скелет и мышцы.

на одной из моих бывших работ чуть не доходило до таких сцен, как на картинке. это была жесть! во-первых, дизайнер не удосуживалась сделать отдельные пнг-файлы для раных кнопок и других элементов. все это приходилось выуживать самостоятельно с помощью фотошопа который висел ужасно, отнимая кучу времени. потом, были версии приложения для айфон и андроид, а дизайн рисовался один — айфонский, а вы господа андроидщики «ешьте что дают» и приспосабливайте айфонский для своих нужд. мало того, что вид был не айс, т.к масштабы разные и градиенты, которые смотрятся красиво в айфоне, на андроид устройствах выглядят отвратно. Так что приходилось мне вручную перерисовывать иногда. Я нанималась логику клепать, а не градиенты рисовать дурацкие! Ну и, последний штрих, диалог.
Я: — В какую папку ты закоммитила дизайны? (замечу, по названиям фиг поймешь).
Дизайнер: — НЕ ЗНАЮ.

Занавес.

Благо, сейчас все нормально, т.к. дизайнер не только рисует, но и заведует функционалом ЮИ в целом и сам по себе человек адекватный.

бей их!!111

Общение! Прежде всего — общение! И дизайнеры, и программисты должны время от времени спускаться каждый со своего неба и нормально и профессионально обсуждать общие задачи. И будет всем счастье!

Проблемы начинаются, если не понимать специфики работы. Программист это реализатор по своей сути. Они какбэ приземлённее дизайнера, его задача спроэцировать полёт мысли последнего на реальный мир стандартов и технологий. Большой ошибкой является поэтапная разработка типа «концепт-дизайн-реализация», при которой специалисты от каждого этапа не участвуют на протяжении всего процесса, программист принимает работу только в финальной стадии, а потом начинает ломать голову над реализацией. Каждый специалист должен участвовать на каждом этапе минимум в качестве консультанта. И тут дело даже не в том, что что-то нельзя реализовать, а в том, что тонкости реализации не знакомы дизайнеру и какая-нибудь финтифлюшка может обернуться часами работы. Далеко не факт, что продакт-аунеру (который тоже не всегда занком со спецификой) это так уж нужно.

Наверняка, со стороны дизайнеров есть подобные аргументы, но пусть они их и приводят )

И тут дело даже не в том, что что-то нельзя реализовать, а в том, что тонкости реализации не знакомы дизайнеру и какая-нибудь финтифлюшка может обернуться часами работы.

да! в точку.

хорошо если часами...

Тю. Это дизайн. Мы — программеры и наше дело — выполнить задумку дизайнера. Зачем браться за работу, если не можете ее сделать хорошо? И да, всегда в том же эппл-девелопменте дизайнеры руководили технарями, посему и реализации весьма интересны (признаю, что иногда над одной анимацией можно трахацца пару дней, чтобы сделать ее дийсно классной, но ведь за это же нам платят, чтобы было классно и так, как хочет заказчик и его дизайнер, а не так, как нам удобно и быстрее сделать). По причине же главенства технарей над дизайнерами в андроид программинге, приложения андроида унылы. ТАк же и на десктопах, так что, господа и дамы, прекращайте леницца и делайте работу хорошо, не?

есть некий баланс между качеством, стоимостью и скоростью. да как и везде в нашей жизни )

Только каков этот баланс решать не программеру, которому лень напрягацца, а заказчику и дизайнеру с их стороны и менеджеру со стороны программера.

Если же менеджером является сам программер, то, в таком случае плохой из него менеджер выходит, если он запиливание дизайн фич режет (заведомо ухудшая качество продукта) и не получает за них денег.

Ну а если программер взял работу, зная заранее о дизайне и на фиксед-прайс и начал потом выть, что сложно, дескать, посему делать не будет, то ему пора уходить в дворники, не?

Так что, как по мне, стоит таки перестать леницца и начать делать так, как желает тот, кто лучше программера разбираецца в интерфейсах и юзабилити.

решать менеджеру и заказчику. программер не бог, а менеджер в распоряжении имеет далеко не всегда «спицнасс» а бойцов разного гатунку. короче — это моя последняя реплика. мне нечего добавить

>мне нечего добавить

Та вы не добавляйте, вы хотя бы оформите в удобочитаемый вид то, что уже написали. Что обозначает вот эта сентенция поясните, пжалст:

«программер не бог, а менеджер в распоряжении имеет далеко не всегда „спицнасс“ а бойцов разного гатунку.»

«далеко не каждый программист способен творить чудеса на работе (ну в силу разных обстоятельств). А менеджеру приходится иметь дело с тем штатом специалистов, который доступен ему сейчас. Вот и получается что приходится идти на компромис между красотой дизайна и трудоемкостью воплощения его в программе (потому как сроки завалят если силы не рассчитают)». я уже молчу о том что квалификация некоторых спецов не такая высокая и они могут делать таск ну совсем долго (в дворники им не пора они просто джуниоры пока что и многого не знают)

Хммм... То есть, описанные вами причины сиравно вне компетенции программера, которому надо просто педалить код, если так было решено его менеджером и заказчиком, да? Я говорил далеко не о квалификации джунов, а о том, что в дворники пора профнепригодным, которые жизнерадостно дали неправильные эстимейты, а птом начали выть, что делать что-то сложно.

которые жизнерадостно дали неправильные эстимейты, а птом начали выть, что делать что-то сложно.

c Вами (будь Вы программером, дизайнером или менеджером), лично, никогда не случалось такого? готовы пойти в дворники?

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

Итак, изначально, было сказано:

>>>Ну а если программер взял работу, зная заранее о дизайне и на фиксед-прайс и начал потом выть, что сложно, дескать, посему делать не будет, то ему пора уходить в дворники, не?

Это я чисто так. Напоминаю.

>>которые жизнерадостно дали неправильные эстимейты, а птом начали выть, что делать что-то сложно.

>c Вами (будь Вы программером, дизайнером или менеджером), лично, никогда не случалось такого? готовы пойти в дворники?

А теперь лирика. Да, у меня ни разу не было, что из — за неправилньых эстимейтов я отказывался выполнять работу, мотивируя это какими — либо причинами, в т.ч. и тем, что слишком сложно. Посему, мне метла пока не нужна, а вот судя по тому, как вы защищаете свое право взять деньги, наделать обещаний, а потом отказывацца работать ,мотивируя это сложностью и своим непрофессионализмом в областях, за которые вы беретесь, по вам давно уже плачет не то, что метла, плачет лом, дабы плац подметать.

Насчет «работать пока не сделаешь и пофиг на сложность и неправильный эстимейт» это иногда катит, а иногда — нет. Если сидишь фрилансером дома и можешь за «спасибо» поработать (те человеко-часы на которые промахнулся) то можно и пососать лапу. А если промахнулся по-серьезному и сроки поджимают (и приходит понимание что не сделаешь в разумные сроки) то нужно как-то совместно (с заказчиком) решать тупиковый вопрос. И возможно от чего-то отказаться на данном этапе (да-да «повыть что сложно»)

Ну закончу на позитивной ноте )

Все описанное мною (в этом посте), конечно же, к Вам не относится.

Мы — программеры и наше дело — выполнить задумку дизайнера.

Очень распространенная ошибка. Задача и программиста и дизайнера выполнять задумку продукт манагера/овнера.

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

Больше да чем нет но все-таки но.
Пример. Задача (хтмл/ДжС):

Сделать текстовое поле в котором будет выбор даты + время (в формате Ам/Пм). Требования: поддержка браузеров и ИЕ7+, поддержка секции 508 (кто знает что это уже отказывается :) ), нормальный деструктор.

Нормального готового решения не нашлось (если знаете, буду благодарен). Остается писать самому. А это 1700+ строк ДжС кода (виджет в ДжКвериУИ), которые надо написать и поддерживать — это время. Данный контрол надо поменять в 5-10 местах — время на разработку + время на проверку (пару мест стремные + время на починку багов) + время на додизайн остальных мест. Серверный код — это реально мелочи.

На данный момент остановились на простом решении: оставить как есть: поле для даты и 2 дропдауна (время и Ам/Пм) и фиксированная ширина панели с этим контролом.

выбрано и утверждено межуд заказчиком и дизайнером

Хочу в ваш мир, ибо в моем это далеко не всегда так.

Тю. ДЫк вперед ко мне на фриланс.

И да, как уже было сказано, какая разница, сколько займет реализация, если заказчик за это платит деньги почасово. Если же фиксед прайс и неправильный эстимейт, то почему ваш ПМ все еще жив?

Заказчик в продуктовых конторах называетсо продукт-овнер, учитывая что он часть конторы, он не готов платить за разработку такой хны, поэтому и остановились на втором варианте.

Тю. ДЫк вперед ко мне на фриланс.

Да мне и тут пока тепло.

>Заказчик в продуктовых конторах называетсо продукт-овнер, учитывая что он часть конторы, он не готов платить за разработку такой хны, поэтому и остановились на втором варианте.

Не знаком со спецификой. Обычно, работаю с дизайнером заказчика и самим заказчиком. Что дано мне дял выполнения, то все азказчик хочет и за все готов платить.

>Да мне и тут пока тепло.

Дык, вы ж хотели в идеальный мир, я его показал ,ан нет, уже и не хоцца.

Можно какой-нить пруф-линк на

ибо программер — самое нижнее звено в цепочке.

? Это звено нижнее тоже должно иметь обратную связь. Заказчик может быть несведущим человеком в ИТ. Прикиньте если придется писать на javacript что-то типа photoshop’a. Как доказать заказчику что производительность js кода и прозводительность десктоп приложения это разные вещи? А фиг тут докажешь — мешает субординация (еще «выслугу лет» сюда влепить нужно).

Это, мягко говоря, неправильное понимание. Заказчику прежде всего нужен полный продукт, а не дизайн. И если у заказчика продукт ассоциируется исключительно с дизайном, то это бракованый заказчик, меняйте его по гарантии.

Фокус в том, что если, с точки зрения заказчика, дизайн очевиден, то внутри продукта происходит непонятная магия. Значит надо делать продукт прозрачнее для заказчика и воспитывать культуру заказа, которая будет играть на руку всем сторонам проекта. Это не значит, что заказчик должен вникать в тонкости алгоритмов. Однако, ему можно объяснить, что на этом, том и ещё вот том ухищрении дизайнера можно сэкономить достаточно времени и денег.

«Это невозможно сделать!», «Для начала оно должно просто работать!», «Нам не нужны эти украшения», "«Какая разница будет оно зеленым или желтым?», «Вы надизайнили, а нам разгребать...», «Оставим пока как есть, а потом поменяем...»

Перевожу эти фразы:
Для вас — это сделать кнопку другого цвета, а для разработчика:
— поменять БД (добавить поле)
— добавить отображение
— часто: добавить тяжелую логику вычисления того какого цвета должна быть кнопка
— из предидущего пункта, переколбасить представление и клиентскую логику чтобы этим можна было пользоваться
— написать на это все тесты
— пофиксить баги
И это все в контексте того что есть и более «интересные задачи».

Надо научится слушать то что человек хочет сказать, а не то что он говорит.

Далее по тексту:

Дизайнеры, получив задание, начинают «творить», частенько забывая о том, как это будет работать в конечном виде.

Уволить! И нанять нормального.

Для инженеров, в свою очередь, дизайн кажется второстепенной, далеко не обязательной частью рабочего процесса.

Уволить! И нанять нормального.

Дизайнеры по своей сути это нонконформисты ... Мы выходим за рамки для того ...

Здаетсо мне, шо Нам надо обратится к доктору :)

Именно с них начинается разработка продукта, и именно они должны стать ключевым связующим звеном в последствии.

У Нас точно мания величия, Мы путаем Себя с ПМами.

Кстати, с этими самими ПМами проблем побольше в плане зеленых кнопок и «выведи сюда цифирку» :)

Естественно, что рабочий процесс у всех разный. Но это специфика работы, разве не так? Если нужно добавить поле в форму, или добавить элемент, который действительно сделает интерфейс более удобным или более простым (представим, что эта идея вдруг родилась у дизайнера, когда он сидел в очереди к доктору), неужели это не стоит того, что бы сделать продукт лучше?

Мне очень импонирует ваш максимализм! Он настраивает на позитивный лад :) Но относительно кадрового вопроса, вы скорее выдаете желаемое за действительное.

неужели это не стоит того, что бы сделать продукт лучше?
Я говорил обратное? Просто добавить элемент — стоит времени и не всегда затраты оправдывают результат.
Мне очень импонирует ваш максимализм!
Вы это где прочитали?

Никогда подобного не слышал.Каждый работает над свими делами. Такое возможно наверно только в маленьких начинающих конторках по разработке сайтов.

Такое везде возможно. И пренебрежительный тон неуместен.

Хотелось бы хоть слегка прочувствовать то, о чем пишет автор.

К сожалению в корпоративных монструозных проектах вышеупомянутые специальности пересекаются не часто)

лучше не надо прочувствовать, это иногда ужас какой-то. подробній рассказ віше

Одной стороной продукт смотрит в компьютер (код), второй в другие продукты (форматы передачи/хранения данных, API), а третьей в человека.(пользовательский интерфейс).

Проблемы начинаются, когда одной из частей не уделяется должного внимания. Это не rocket science.

но в команде из 3х фронт-эндщиков, 3 бек-эндщиков и одного дизайнера угадайте в какую сторону возможен перевес?

Что значит перевес? Время на разработку распределяется голосованием?

скорее на распределение приоритетов

всем понятно, что время разработчика, как и время дизайнера ограничено и времени на полировку интерфейса, перекрашивание кнопок и 5 пикселей в 80% случаев не хватает

При нормальной организации процесса разработки, таких проблем не возникает.

Вот-вот. Проблема не в людях, а в процессе, при котором дизайнеры и девелоперы не работают в одной команде и общаются только в краткий момент «передачи макета и описания функционала».

А разве не люди строят процесс? Разве сложно встать из за стола, и пойти переговорить с коллегой? Ведь всегда можно организовать свой микропроцесс, в котором именно вам будет работаться комфортно и продуктивно. Зачем ждать, что кто-то решит за вас?

Попробую объяснить со своей колокольни. Мне обычно очень тяжело конкурировать с людьми, у которых больше свободного времени, которые работают от силы несколько часов в неделю, и то, в основном, «ртом» на всяческих митингах. Мне, кроме того что говорить, еще и работать надо.

Во-вторых, при вербальной согласовке спорных моментов часто бывают ситуации, когда одна из сторон со временем морозится в стиле «я этого не говорил». По этой причине лично я предпочитаю письменное общение, да хоть е-мейлом, но чтобы всегда было возможно процитировать оппонента при необходимости.

В-третьих, когда человек пытается выразить свою мысль письменно, он обычно более точен в формулировках.

В-четвертых, письменное общение лаконичней, в нем меньше «мусора», «шума» в терминах теор.информации.

Да что вы, совсем нет! Это же напрягаться надо с организацией и все такое, намного же проще просто «сбросить» ответственность на кого-то «как-то» это мотивировать для начальства и все дела! :D

таке відчуття що статтю писав дизайнер :)

Да-да! Дизайнеры хорошие, разработчики — плохие, не хотят на пять пикселей ниже что-то сделать))) А то что по вине дизайнеров зачастую срываются сроки, потому как к ним почему-то не приходит муза и они не то что скрин, а даже банальную иконку для таб бара не в состоянии вовремя сделать, то такое ;-) И то что многие из них настолько самоуверены в свое «чувстве вкуса», что им незачем читать гуйд лайн по платформе с которой надо работать, потому лепят как попало и что папало... это тоже, так, мелочи... Ну о трудовой дисциплине среди дизайнеров, я вообще молчу, не явиться на митинг или прийти под конец — это само — собой разумеется...

P.S.:Я не говорю что все бойци UI/UX фронта такие, есть и такие что ненарадуешься... Просто накипело ;-)

«А ведь именно пешеходы...»
Ребята, что за бред. «По вине дизайнеров». По вине конкретных людей, в конкретных ситуациях.

Вы до конца дочитали? Если нет, то special for You: "

Я не говорю что все бойци UI/UX фронта такие, есть и такие что ненарадуешься...

"

Статистика говорит об обратном. Я управлял несколькими крупными проектами, PM. И мелких куча. Верстка — техническое, есть ТЗ и макеты — ок. Все прозрачно. Программирование, тоже самое. Дизайн... Завал. Потому что у нас дизайнеры до сих пор не поняли, что рисовать пикселы это не вся работа. Нужно еще уметь кодить, понимать ограничения (природные так сказать). И так далее.

дураков везде хватает ))) не ну серьезно ... самый распространенный вид в природе )

Я сам UI дизайнер, и немного программист. Я задолбался объяснять начальству на каждой работе, и клиентам. Что бы они забивали на пиксели. Дизайн должен быть быстрым. Чистым. Понятным. А оформление (всякие стили кнопочек и прочего), это уже второй вопрос. Совсем вторй. Если не третий. Но среди дизайнеров я не мейнстрим, и перфекционисты будут и дальше потухать по пикселям, вместо продумывания UI, как такового.

Хорошая статья, увидел нотки происходящего рядышком ;)

Отлично написано и очень по делу

Спасибо, было интересно. Хотя это все описано во множестве книг по проектированию и дизайну интерфейсов.

Хотя сделать на 5 пикселей ниже или что бы градиент был «плавней» иногда очень трудоемкая и ну ОЧЕНЬ НУДНАЯ работа :)

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

неповерите, но и у дизайнеров бывает

ну ОЧЕНЬ НУДНАЯ работа

например, ресурсы нарезать, но делать ее все же надо

Перерисовать 150 иконок в 5-ти разных размерах тоже не самая развеселая задача ;) Это все к тому же... к специфике работы. У каждого своя.

Підписатись на коментарі