Разработчик — дизайнерам. Фром харт ту харт

    Всем хэй-хо!
    Намедни, играл сам с собой в игру «Прием у психотерапевта». Осознал, что если добрый доктор в уютной обстановке тихим вкрадчивым голосом предложит прилечь на диван, расслабиться и рассказать ему о том, что меня волнует, я начну полный эмоций рассказ о…
    Фраза крайней степени эмоциональности, но без обсценной лексики
    <огромные_красные_буквы>рассказ о том, как же мне, как разработчику приложений для iOS, иногда хочется взять автора того дизайна, который приходится использовать, да ударить со всего размаху фаллическим веслом ему по лицу, повалить, и прыгать по его спине в тяжелых ботинках, прыгать, прыгать...</огромные_красные_буквы>

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

    Обычная история

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

    Идеальный сценарий


    Основны

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

    Размеры

    Невероятная удача — разрешений у айфонов всего два, если с айпэдом, то три (привет, андроидщики!). И если дизайн предполагается только для айфона, то достаточно нарисовать его размерами 640 x 1136, а разработчик дальше уже по накатанной схеме и для экрана старых моделей адаптирует. Но вот мой коллега буквально на днях показывал дизайн, сделанный под ширину 666 пикселей. Дизайнером из ада, не иначе.
    Кроме того, есть такие стандартные элементы как верхний бар навигации, нижний бар вкладок (тех. русск. — навигейшнбар и таббар соответственно), рисовать которые желательно стандартных размеров, которые можно легко найти в интернете, например, вот. Единственное, надо учитывать, что если размеры указываются в точках (pts), то их надо умножать на два, потому что у дисплеев Retina на одну точку приходится четыре пикселя.

    Кнопочки

    Самый любимый повод для ненависти.
    Интуитивно понятно, что у кнопки есть как минимум два состояния — обычное и нажатое. Там, где на кнопочку можно нажать курсором, есть еще состояние наведенного курсора. Может быть я просто неудачник, но во всех дизайнах, с которыми мне за несколько лет работы пришлось иметь дело, для кнопок нажатое состояние было нарисовано в 5 % случаев. Да, операционная система сама по умолчанию немного изменяет внешний вид кнопки, если он не указан явно, но часто это все смотрится крайне убого. И становится причиной претензий к, как ни странно, разработчику, а не дизайнеру.
    Раньше, когда в моде был выпуклый дизайн, я приноровился делать фоновые изображения для нажатой кнопки из фона для обычного состояния путем реверса градиента слоя. Копировал группу слоев, ответственных за кнопку, открывал стиль фона кнопки и ставил одну галочку — абсолютно не сложно. Да, уважаемые дизайнеры, абсолютно не сложно.
    Теперь, кстати, с приходом эры плоского дизайна, без наличия тонкого чувства прекрасного своими силами сделать нажатую кнопочку сложновато, приходится ругаться. Когда ругаешься, отсутствие чувства прекрасного — это только плюс.
    И последнее, что бы хотелось сказать о кнопочках (и не только), это скорее не совет, а просьба. Мольба, если хотите. Не переусложняйте. Понятное дело, конечной инстанцией в одобрении дизайна будет заказчик и только заказчик. Но в ваших силах постараться, чтобы тот дизайн, который ему в конце концов понравится, был бы прост и изящен. Они же так податливы в руках умелого психолога, эти заказчики. Тем паче, казуальность нынче в трендах.
    Показать, какие кнопки для разработчика в радость, а какие наоборот, я постарался на картинке:
    image
    Пришлось залить на гуглдрайв, ибо Habrastorage 2.0, хоть убей, не показывал мне ссылку на вроде как успешно залитый файл

    Если предполагается, что все однотипные кнопки будут одного размера, то сойдет любой плод ваших высокохудожественных изысканий. Но такое редко случается, потому что на кнопке скорее всего будет висеть какой-нибудь поясняющий текст, на разных кнопках — текст разной длины, а то может быть еще и на разных языках. Так что дружелюбная кнопка должна иметь такое пространство, которое может безболезненно растягиваться по горизонтали. Если высота кнопок тоже должна варьироваться, то такое безболезненно тянущееся пространство должно иметься и для вертикального направления. В противном случае бедняге разработчику придется нарезать фоновых картинок на все случаи жизни. Или, например, отрисовывать кнопки на лету, силами графических библиотек. Это, конечно, тру-способ, да и конечный билд будет на несколько сотен килобайт меньше в объемах, но, я, например, не настолько суров, чтобы мне такой подход нравился.

    Послесловие

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

    UPD Пользователи denisbalyko и designiac указывают на отсутствие в статье важной ссылки по теме — ilovepsd.ru. Очень полезный ресурс в первую очередь для дизайнеров, которые хотят добиться респекта, автор вроде как Николай Беринг burning. Вот его пост на хабре
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 37

      +10
      Воистину, это относится не только к мобильному дизайну!
      Говорю как разработчик, потративший не один час за фотошопом в попытках отыскать нужный слой, нарезать правильно слайсы и дорисовать недостающие градиенты.
        +9
        codereview designreview для дизайнеров надо устраивать
          0
          Дизайн ревью по аналогии с codereview кстати наверное полезная штука была в компаниях где есть младшие/старшие дизайнеры.

          Вообще зависит от сетапа проектов, но повозможности обговорить с заказчиком порядок принятия работы дизайнера (acceptance). Если процесс постоянный, разработчик мог бы договориться с заказчиком что одним из этапов принятие работы дизайнера является подтверждение со стороны разработчика. А чтобы дизайнер не просил допольнительно $$$ на доработки, ему вначале выслать требования/типичные ошибки, то есть там где требование явно нарушается — дизайнер дорабатывает бесплатно.
          +1
          Ресайз под нормальный размер из ретины тоже нужно делать дизайнерам. Потому что зачастую там элементы из вектора, которые нужно тянуть, пока они не растризованы.
            +4
            Странно, если когда разработчик находит какае-то косяки в моем дизайне он мне пишет «слышь, ты там че, сделал надпись растровой? А мы когда переводить будем, как, тоже картинкой ее поставим?» и готово, через 10 минут ему приходит свежий файл с исправленной надписью. После 5-го интерфейса под айфон этих шероховатостей в дизайне почти не остается, дизайнер получает левел-ап, а разработчик — внятный макет.

            А вот по-поводу называния слоев это, конечно, проблема — пока работаешь, их количество уже может тысячами исчисляться, а реально, разработчику из них нужно, дай бог чтоб 5-ть штук. Три иконки и две картинки. Но, опять таки, с опытом приходит понимание, что нужно называть и групировать, а на что можно забить. Да и вообще я считаю что это, скорее, работа дизайнера сделать тайлящиеся элементы для всех кнопок не заставляя разработчика копаться во всяких мудреных смарт-обьектах.
              +2
              Я бы с радостью работал с таким дизайнером как вы :)
              Но проблема в том, что часто конспираторы-заказчики стараются не давать разработчику никаких выходов на дизайнера. Поэтому запрос на какие-то доработки идет через несколько кругов ада в лице всяческих менеджеров, и ответ тем же путем. Эффективность взаимодействия стремится сами понимаете куда.
                +1
                Про основы, размеры и кнопочки: здесь всё, как и с программистами, называющих переменные var1, непродумывающих разные варианты событий (коннект к базе отвалился) и т. д. В общем, дело в аккуратности, внутренней дисциплине, порядке и светлой голове.

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


                Понимаете, разработчик — тоже дизайнер. Здесь стоит процитировать 2 вещи.

                Плохой технолог:
                1. Не вникает в смысл дизайна, забывает о полезном действии и верстает макет по пикселям, в лоб.
                2. Полагается только на свои силы. Надолго застревает на сложных элементах и не обсуждает решение или возможность упрощения. Не заботится о деградациях. «Кроссбраузерно» для него — одинаково во всех браузерах.
                3. Не готов править вёрстку и скрипты, разрезанные на шаблоны. Ничем не интересуется. Не делает собственные проекты.
                4. Притворяется хорошим.


                Хороший технолог:
                1. Мастерски верстает сайты, пишет скрипты, общается с коллегами, планирует время, делает работу в срок без начальника с палкой.
                2. Не просит дизайнера отрисовать макет для разной ширины браузера, а сам предлагает разумную «резину». Придумывает уместные анимации интерфейса, не требуя разжевать каждый кадр.
                3. С удовольствием исследует новые области, любит нестандартные элементы интерфейса. Щёлкает рутинные задачи автоматизацией, готовыми решениями, снипетами и миксинами.
                4. Видит, в чём сегодня был недостаточно хорош, и завтра становится лучше.


                Проще говоря, не стоит быть неандертальцем.
              +2
              Блин! После такой фразы я был готов к как минимум десятку советов, и даже уже нажал Ctrl+C в адресной строке, и загадал парочку хороших но всё таки дизайнеров :)
                –2
                По-моему вы забываете что дизайн, это не то что вам присылает визуализатор, а то что получает заказчик в виде конкретного решения его проблемы. Пока вы это не поймете, всякие мелочи будут постоянно тянуть вас назад, почему бы просто не переговорить с дизайнером заказчика 15 минут по скайпу и не выработать общий подход к проекту, кто там что должен рисовать и как сдавать. А лучше тыкнуть в одно из автоматизационных решений для фотошопа которое и все само порежет и ретину сделает.
                  0
                  По поводу «переговорить с дизайнером» — это здорово, но есть маленький нюанс, который я описал в ответе к комментарию чуть выше
                  А вот автоматизационными решениями вы меня заинтриговали. Можно какие-нибудь ссылки? Если я пребывал до этого в лимбе, нарезая ресурсы вручную, а что-то стоящее действительно есть, я назову в вашу честь сына. Мне на ум из автоматизации процесса приходит разве что утилита, которая автоматически уменьшает в 2 раза картинки для ретины и сохраняет их.

                  P.S. Простите, про сына я преувеличил, без обид, но имя Кирилл мне совсем не нравится :)
                    0
                    www.pngexpress.com/
                    www.cutandslice.me/
                    witstudio.net/assistor/
                    Если не дают выходов, значит мало понимают процесс разработки, попытаться объяснить, если опять не дают попросить немножко денег за адаптацию макета.
                      0
                      Спасибо за ссылки. Глянул видеопрезентацию pngexpress. К сожалению, магию он творит только при условии, что дизайнер передал psd в просто идеально структурированном порядке, а это совсем нереальный вариант развития событий. Тем более для каждого элемента скорее всего все равно придется выставлять какие-то настройки. Я при таких условиях и вручную по полминуты на элемент потрачу. Единственный плюс — то, что приложение, если требуется, автоматически нарезает картинки для нескольких разрешений. Если надо больше чем изображения для iPhone и iPhone Retina, это преимущество будет ощутимым.
                        +1
                        К слову в обновлении 14.1 к Фотошопу тоже добавили подобную автоматизацию: ты приписываешь суффикс с расширением и параметром сохранения, а при нажатии на одну кнопку все скопом экспортируется.
                    –2
                    Ненависть — это просто два ништяка в два слоя:)
                      +1
                      Есть отличный сайт Photoshop Etiquette.

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

                        Привязка к сетке. Привязать к пикселю. Привязать пока ничего не осталось, чтобы привязать к. Удары быть от от пикселя * Ах ужас! *.
                          0
                          Так и есть. Автоматический гугловский перевод.
                          Но если Вы работаете в английской версии фотошопа, то почти все и так понятно. Если нет то еще один стимул учить английский язык.
                            0
                            «почти все и так понятно...» вот именно что почти… Русский разработчик кидает ссылку русскому дизайнеру, на англоязычный сайт, что бы дизайнер научился работать в фотошопе… Если дизайнер не знает того, что там написано — скорее всего это начинающий дизайнер, и не сильно владеющий англ языком. Так что уведомить начинающего дизайнера английской статьей, все равно что подарить русскому книжку на тайском язык: «Ну и что что не понятно, учи тайский, поймешь»…
                              0
                              Ну, английский надо еще в школе учить. Сейчас множество профессий и вакансий подразумевают что человек уже знает английский а не будет его учить на работе.
                          0
                          А как же без этой ссылки в статье?
                            0
                            Спасибо, хотел и про нее написать но не мог найти.
                              0
                              Обновил пост, добавив эту ссылку, спасибо
                            +1
                            И все-таки надо отсылать дизайнеру на доработку, если такая возможность есть.

                            Если такой возможности нет — нужно ставить в известность заказчика и отдавать этот кусок работы дизайнеру/верстальщику, с которым есть уговор и включать этот момент в стоимость работ отдельным пунктом.

                            Если всегда будете продолжать подчищать косяки за другими — вам этих косяков будут сыпать больше и больше и начнете работать себе в убыток.
                              +2
                              Вот почему удобно иметь одного партнёра.
                                +1
                                Стараюсь использовать в проектах по минимуму растровой графики. Если проследить эволюцию собственной работы в веб, то можно заметить, что вес папок /images/ стремится к нулю. Чего и всем желаю ;-)
                                  0
                                  На самом деле все, что написанно конечно имеет значение, но по большому счету к дизайнерам не имеет никакого отношения,
                                  и опытный дизайнер может написать про то как вы делаете, что то не так — все эти проблемы которые вас возмущают
                                  лежат на самом деле совсем в других областях причем в очень разных и сложных и в большинстве случаев ни у программистов
                                  ни у дизайнеров на них нет возможности повлиять.
                                  Эти проблемы решаются с опытом и чтобы их избегать старайтесь просто работать с хорошими и опытными колленами и заказчиками,
                                  и такие мелочи будут реже вас беспокоить т.к. все нормальные люди стараются помогать своим коллегам, решать те проблеммы, что мещают
                                  делать общее дело.
                                  Мне это все хорошо знакомо тк я был в обоих ролях.

                                  > Но проблема в том, что часто конспираторы-заказчики стараются не давать разработчику никаких выходов на дизайнера.
                                  не работайте с такими заказчиками т.е только в крайнем случае
                                    +1
                                    Ваш совет в стиле «Лучше быть здоровым и богатым, чем бедным и больным».
                                    Заказчики бывают разные. Исполнители тоже. Все хотят кушать, а спецов нужного класса никогда не будет, если они будучи младшими исполнителями не сделают все ошибки своими руками.
                                    Автор вероятно захотел написать своему классу заказчиков пост, чтобы кидать ссылку. И правильно сделал.
                                      0
                                      вы правы, по этому постараюсь немного перефразировать (может быть будет больше практической пользы) — если вы стакиваетесь с повторяющимися проблемами на протяжении нескольких лет, то не думайте,
                                      что весь мир против вас, просто постарайтесь оглядываться вокруг, смотреть на мир с другой стороны и рано или поздно вы обнаружите, что и другие варианты решения ваших проблем тоже возможны )
                                    +1
                                    Я в свое время тоже нервничал и исходил желчью. У меня под кроватью была кукла вуду на каждого дизайнера. Потом я обнаружил одну очень интересную вещь: дизайнеры такие же люди! Они понимают связную речь, и с ними всегда можно договориться. Объяснить что к чему, дать ссылки на спецификации и, нет, я не вру, они нарисуют как нужно. Берегите свои нервы и нервы тех, с кем работаете.
                                      +3
                                      Про названия слоев: я, как дизайнер, тоже не понимаю «дизайнеров», которые не именуют слои (и даже не группируют). Несколько раз уже приходилось продолжать работу с такими макетами. Я когда-то вначале работы тоже не заморачивался с названиями слоев, но когда пришлось вернуться к своему же файлу полугодичной давности пришлось пересмореть свой подход к организации структуры файла.

                                      Могу дать один совет дизайнерам, как быстрее научиться именовать слои, — выключить превьюшки слоев. Сразу разбираться в ворохе «layer 100500» становится сложнее. И к тому же слоев больше на экран влазит.
                                        +1
                                        Почему-то мне вся статья показалась очень умело замаскированным парафразом вот этого вот куска из всем известного текста:

                                        бесцветный и жестокий мир, и совсем не важно, узкий ваш Arial или жирный, когда в стране ад, чума и все гнут спину на царя. Междумордники ЧКВшники находят баги после получения письма от психотерапевта.
                                          0
                                          Вы просто сорвали эту статью у меня с уст ) ха-ха. Очень давно хотел написать именно свои пожелания разработчика дизайнерам. У меня, например, свой пунктик на дизайнеров, которые рисуют какой-то элемент в разрешении ретины, который имеет нечетную высоту или ширину. То есть, когда я его уменьшу в два раза для стандартного разрешения — он должен иметь размер 35.5 что-ли? )))

                                          А насчет автоматизированной нарезки, то ее активно использовал мой один из заказчиков, который сам разработчик. Мне во всем этом деле было не понятно, как эта автоматика все режет, и как мне потом эти файлы подстроить под программу. Когда я режу сам, я знаю, как я пишу и какие файлы мне нужны, и моя работа имеет более осмысленный для меня вид.
                                            +2
                                            получил свои кровные, сидит на подоконнике, смотрит на дождь, пьет кофе и думает о концепции нового шедеврального дизайна

                                            Завидую умению вставить стереотип в статью, так, чтобы это было крайне уместно!
                                              +6
                                              Каждый разработчик, рано или поздно, пишет публичное обращение к дизайнерам ©

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

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

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

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

                                              Вообще, если вам, разработчикам часто приходится работать с разными дизайнерами, составляйте свои собственные требования для дизайна и включайте это в ТЗ. Потому что подход у всех разный и требования тоже разные. Я в свою очередь часто сталкивался с тем, что разработчик плевался слюной и кричал что то что нарисовано — невозможно скопировать отдельным элементом, и когда ему показываешь волшебные ctrl+shift+C (скопировать со всех слоев) он успокаивался.

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

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

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

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

                                                Я тоже под айос пишу, и графические редакторы мне нужны бывают только чтобы цвета и отступы посмотреть, если мне их вдруг не прислали. Бесконечно люблю наших дизайнеров за это :)
                                                  0
                                                  Фотошоп, этот кусок непотребности, вызывает лишь улыбку сожаления. Особенно по поводу слоев.

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

                                                  Самое читаемое