Дизайнерам с любовью (письмо от фронтенд-разработчика)

Уважаемые дизайнеры,

Это письмо готовилось годами. Части его были переданы в устной и письменной форме различным дизайнерам в течение длительного периода времени.

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

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

Я не берусь учить вас графике или эстетике. Я не буду углубляться в типографику, разборчивость или использование пробелов.

Вместо этого я хотел бы объяснить, как плоды вашего труда влияют на мои.

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

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

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

Проектирование для документации

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

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

Расскажите мне, какие шрифты вы использовали для чего. Дайте мне знать, какие цвета, интервалы и контексты использовать. Мне нужно знать.

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

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

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

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

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

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

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

Проектирование для технологий

У этого есть две стороны: что можно сделать и что подходит для среды.

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

Тот факт, что вы нашли пример, в котором кто-то успешно объединил WebGL 3D с размытием CSS и масками фильтров для демонстрационной страницы, не означает, что вы можете использовать это как полноэкранную панель параллакса в одностраничном приложении.

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

Однако, если вы действительно хотите проверить края и если вы хотите попробовать это для развлечения, свяжитесь со мной в частном порядке. Я люблю создавать такие вещи так же сильно, как и вы. Просто не вкладывайте это в бюджетный производственный проект.

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

Вы не художник-график; Вы больше, чем это, вы дизайнер.

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

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

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

Постарайтесь достичь как можно большего, используя только HTML и CSS. Избегайте использования красивых функций, доступных в Photoshop. Не используйте смешивание! Не используйте искусственный полужирный шрифт и искусственный курсив.

Если вы не хотите, чтобы элемент был изображением, вообще не используйте фильтры, кроме самых простых теней.

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

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

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

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

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

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

Начнем с самого простого: ссылок.

Ссылки не могут иметь только два состояния.

В навигации, которую я получаю, вы всегда предоставляете дизайн для ссылок и активную ссылку (текущая страница).

В других случаях вы обычно предоставляете базовые состояния и состояния зависания .

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

О, и не смей менять расположение ссылок между состояниями (различная ширина границы, отступы и т.п.).

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

Поскольку мы собираемся использовать это на мобильных устройствах, убедитесь, что между отдельными интерактивными элементами достаточно пробелов и что каждый хитбокс достаточно велик. Я думаю, что минимум 42px по каждой оси — это норма.

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

Элементы формы еще хуже.

Наиболее распространенный случай, который я вижу, — это переключатели и флажки. Стандартные ужасны! Итак, вы создаете свой собственный, и даете мне проверенное и непроверенное состояние, и считаете, что сделали.

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

Имеем следующие состояния:

• Проверено или не проверено
• Ховер или нет
• Фокус или нет
• Включено или отключено
• Ошибка или нет

Каждый из них может сочетаться с другими.

Disabled предотвращает некоторые комбинации (hover и focus обычно не имеют значения, когда отключены), но не все (checked-disabled-error — это вполне допустимое и информативное состояние для флажка). Таким образом, мы получаем 16 включенных и четыре отключенных состояния, что дает в общей сложности не менее 20 различных состояний. Например, в этой настройке состояния, которые вы мне обычно даете, это «проверено-не-не-включено-не» и «непроверено-не-не-включено-не».

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

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

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

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

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

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

Дизайн для контента

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

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

• А если его слишком много?
• Что, если его слишком мало (или он полностью отсутствует)?

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

Если для раздела страницы нет контента, удалим ли мы весь раздел — заголовок, контейнер и все остальное — или сохраним раздел и отобразим что-то вроде: «Пока нет статей, зайдите позже?» Еще лучше: «Хотите получать уведомления, когда появится этот контент? Подпишитесь на нашу рассылку!"

Принимайте решения! Тогда спроектируйте эти вещи!

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

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

Убедитесь, что один и тот же контент имеет одинаковую структуру.

Если один и тот же заголовок виден в нескольких местах, не выделяйте одно слово жирным шрифтом в одном регистре, а другое — в другом!

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

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

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

Дизайн для отзывчивости

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

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

Во-первых, мобильные и десктопные варианты не являются отдельными страницами. Я знаю, что ты знаешь это. Это просто переформатирование одной и той же страницы.

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

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

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

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

Разработка исключений

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

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

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

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

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

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

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

С любовью,

Ваш фронтенд-разработчик