Comments 5
дизайнер — это не токсик, желающий сделать максимально сложные решения только чтобы испортить жизнь разработчику
В корне не согласен
Вообще, если серьезно, проблемы возникают не из-за "душнила-не душнила". У душнил проблемы с дизайнерами/разработчиками далеко не на первом месте по серьёзности.
Проблемы возникают когда дизайнер не думает а реализации.
Частенько бывает такое, что мне дизайнер шлёт макет, а в макете, помимо нарушений UI style guide еще и неверстабельные элементы.
Например, какой-нибудь хитрый микроскопический треугольник, который участвует в тени другого элемента. Тень теперь не прямоугольная, а многоугольная.
Эта проблема решаемая, конечно, но зачем портить жизнь - непонятно.
Считаю, что дизайнеры, чтобы избегать вышеописанных моментов, должны, хотя бы поверхностно, уметь делать то, что они дизайнят.
Как в архитектуре. Там нет такого, что дизайнер задумал дом на десяти шпильках по 10мм каждая. И не потому, что некрасиво - а потому, что, блин, упадёт же.
Веб-дизайнер, по-хорошему, должен уметь верстать. Хотя бы базово. И когда он умеет верстать, он трижды подумает, а нужна ли тут эта рюшка и сколько боли она может принести. И, поняв, что она не нужная, а боли принесет много - большинство дизайнеров её уберут.
Спасибо за прекрасную статью!
Хочется только поправить один моментЭто не проблема на проектах-прототипах, которые делаются всего три месяцаПроблема таких проектов-прототипов, что они довольно быстро перерастают в проекты на пять лет с жутким легаси. И именно из-за отсутствия документации на самых ранних этапах.
Если что простите за невежество. Возможно я не так понимаю, но...
Я сам далек от дизайна, работаю с БД и если программирую что то для себя то это мелкие утилитки, в виде классических WindowsForms или cmd-style. Читал давно еще, что дизайнер это не тот кто просто нарисовал в PSD, PDF или еще как-то и отдал разработчику, а тот кто и нарисовал для себя набросок а потом реализует его уже в UI со всеми элементами в самом проекте, и в каждом элементе прописано имя события им вызываемого. Разработчик же пишет приложение которое выполняет какой то функционал по вызываемому событию, и даже может не представлять как внешне выглядит приложение визуально, но это утрированно.
в статье мы видим попытки решить проблему не там, где она формируется (оргструктура), но там, где она проявляется.
Менеджеры, мыслящие категориями “утилизации ресурсов” создали проблему выделением дизайнеров в отделы. Симптомы порождаемой проблемы хорошо описаны тут : https://opentextbc.ca/socialpsychology/chapter/ingroup-favoritism-and-prejudice/
Эти же менеджеры потом делают дополнительные фазы проверки-переделки.
Ваша статья делает больно. Надо составить дизайн-бинго из указанных пунктов!
Ты надизайнил, а мне делать: как наладить взаимодействие между отделами дизайна и разработки