Инструкция дизайнера

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

Куратор Илья Саблин




Десять принципов качественного дизайна:


  1. Хороший дизайн — инновационный
  2. Хороший дизайн делает продукт полезным
  3. Хороший дизайн — эстетичен
  4. Хороший дизайн помогает продукту быть понятным
  5. Хороший дизайн — ненавязчив
  6. Хороший дизайн — честен
  7. Хороший дизайн — долговечен
  8. Хороший дизайн продуман до мельчайших деталей
  9. Хороший дизайн гармонирует с окружающей средой
  10. Хороший дизайн — это как можно меньше дизайна

— Дитер Рамс, немецкий промышленный дизайнер, ведущий дизайнер фирмы Braun с 1962 по 1995




Подход к проектированию


  • Чтобы спроектировать хороший интерфейс, необходимо четко представлять, какую задачу с помощью него будет решать пользователь. Нельзя создать интерфейс, не поняв задачи пользователя. Интерфейс должен позволять решить задачу максимально простым и понятным способом. Сам пользователь (заказчик) может не знать такого способа и просить «более быструю лошадь», когда ему нужен автомобиль.
  • Интерфейс должен позволять выполнить все функции, требуемые спецификацией проекта (заказчиком), либо предлагать лучшее решение пользовательской задачи, чем заложено в спецификации, но обязательно согласованное с заказчиком.
  • Интерфейс должен объяснять сам себя. Если при рассмотрении макета возникают вопросы типа «Что делает этот элемент?», «А как мне сделать это действие?», «Где я нахожусь?», «Что означает эта иконка?» и т.п. — макет плохой.
  • Интерфейс не должен требовать обучения или объяснения, а должен основываться на привычных паттернах взаимодействия, уже знакомых пользователю. Поэтому при проектировании необходимо в первую очередь изучить и применять существующие решения, а не создавать новые.
  • Чтобы объективно оценивать работу в процессе ее выполнения, автор должен смотреть на нее критично, а также привлекать к оценке других людей (куратора проекта, арт-директора, коллег-дизайнеров), чтобы выявить проблемы интерфейса еще на этапе проектирования.
  • Интерфейс должен сохранять свою функциональность и узнаваемость на разных устройствах: надо заранее продумать, как поведут себя все элементы при изменении размеров экрана. При необходимости нужно создать макеты, демонстрирующие поведение интерфейса при отображении на разных устройствах.
  • Дизайн — лицо продукта. Он должен быть привлекательным и максимально качественным. Именно по привлекательности дизайнерского решения и удобству интерфейса продукт будет оцениваться пользователями и заказчиками, как настоящими, так и будущими.
  • Дизайн должен быть последовательным. Весь продукт (сайт, приложение) должен следовать одной линии дизайна, элементы страниц должны быть максимально переиспользованы. Все интерфейсы должны иметь одинаковую структуру, которую можно выразить набором правил (напр. все кнопки, отправляющие данные форм — зеленого цвета, кнопки отмены — серого цвета)
  • Хороший интерфейс должен взаимодествовать с пользователем: сообщить ему какую-то информацию и дать возможность на нее отреагировать: оформить заказ, позвонить, выполнить действие. Для этого на макетах интерфейса должны быть размещены все необходимые управляющие элементы.




Элементы сайтов и приложений и их функции


  • Ссылка — используется для перехода на другую страницу или сайт. При переходе на сторонний ресурс (другой сайт), должна открываться в новой вкладке браузера. Ссылкой всегда должна быть часть текста, семантически указывающая на открываемую страницу. Например «Ознакомьтесь с правилами пользования сайтом» (но не «прочитайте правила здесь»). Визуально ссылки лучше оформлять синим цветом и подчеркивать, так они быстрее и более однозначно воспринимаются пользователем.
  • Навигация — набор ссылок, помогающих ориентироваться и перемещаться в приложении. Навигация может быть основной (меню, доступно на всех страницах) или вспомогательной (хлебные крошки, оглавление раздела и т.п.) Навигация должна быть максимально простой, отражать логику приложения, а также помогать понять, на какой странице и в каком разделе сайта пользователь находится в настоящий момент.
  • Кнопка — выполняет какое-либо действие (сохраняет данные, отправляет форму и т.п.), или открывает страницу (то есть технически является ссылкой), но связанную с действием. Например кнопка «Зарегистрироваться» открывает страницу регистрации. Надпись на кнопке — это всегда глагол (не «Регистрация» и не «Зарегистрируйтесь»).
  • Элементы форм: поля ввода, поле выбора (селект), радиокнопки и чекбоксы позволяют пользователям вводить и отправлять информацию приложению. Текстовые поля должны выглядеть так, чтобы было понятно «сюда можно ввести текст». Размеры полей должны соответствовать длине вводимых данных, то есть поле ввода даты должно быть коротким (а также содержать иконку-календарь в качестве подсказки).
  • Радиокнопки и ческбоксы нужно использовать строго по назначению. Если из множества может быть выбрано только одно значение — используются радиокнопки либо селект, если несколько — чекбоксы.
  • При проектировании форм нельзя забывать о том, как отобразятся ошибки валидации, как будет выглядеть кнопка отправки в то время, пока идет обработка запроса (содержать индикатор загрузки, блокироваться). Несколько вариантов макета, отображающих разные состояния интерфейса сильно упростят объяснение и передачу этой информации разработчикам.
  • Иконки (пиктограммы) — маленькие изображения, подсказывающие значение элементов. Требования к иконкам: все иконки в наборе должны быть примерно одного размера (визуально казаться одинаковыми по площади), выполнеными в одной стилистике, одинаково заполненными, одинаково детализированными, достаточно отличаться друг от друга, и главное — понятно передавать смысл того, что они означают.
  • Интерфейс в мобильных приложениях должен быть типовым (одного из нескольких возможных типов) и опираться на руководства по оформлению приложений для соответствующей платформы. Все экраны приложения должны быть максимально унифицированы по расположению и размерам управляющих элементов.




Визуальное форматирование, верстка


  • При проектировании внешнего вида страниц, надо опираться на опыт полиграфической, в первую очередь журнальной верстки. Однако при этом не забывать о том, что размеры носителя, в отличие от полиграфии, в вебе и приложениях не имеют конкретных значений и верстка адаптируется под различные размеры экранов, поэтому проектировать следует таким образом, чтобы при изменении размеров это не сказалось на расположении элементов.
  • Необходимо выбрать несколько опорных значений размера шрифта (1-3 размера) и использовать только их. Размеры шрифта во всех типовых элементах: заголовках, кнопках, пояснительном тексте и т.п. должны быть одинаковыми сквозь все экраны интерфейса.
  • То же касается цветов и шрифтовых гарнитур. Необходимо использовать только несколько базовых цветов (из фирменной палитры, если она есть). 
  • Наборы цветов для цветового кодирования на схемах, в специальных списках и т.п. создаются отдельно.
  • При форматировании достаточно объемных текстовых блоков (более двух-трех строк текста) недопустимо использовать выравнивание по центру, а также по обоим краям текста. Текстовые блоки следует выравнивать преимущественно по левому краю, а также следить, чтобы строки не были длинными (форматировать текст в колонки). 
  • Необходимо придерживаться «принципа близости»: связанные по смыслу элементы должны стоять ближе друг к другу, чем к другим элементам. Заголовок — ближе к следующему после него параграфу, чем к предыдущему. Подпись к иллюстрации — ближе к иллюстрации, чем к следующему далее тексту и т.п.
  • Макет должен иметь ритм: конфигурация колонок в соседних секциях должна быть разной, это позволяет избавиться от лишних визуальных связей между несвязанными элементами, а еще делает макет не таким скучным. Большое количество иллюстраций делает макет понятнее и интереснее.




Работа с текстом


  • Текст на странице или в интерфейсе должен быть максимально простым. заказчик редко предоставляет хороший текст, поэтому его необходимо редактировать, предварительно согласовав это.
  • Если текст кажется сложным, скучным, непонятным — его надо переписать.
  • Текст должен быть разбит на параграфы.
  • Предложения должны быть максимально короткими и понятными.
  • Если в тексте говорится о чем-то неочевидном или сложном — необходимо снабдить текст иллюстрацией, графиком, таблицей — чем-либо, упрощающем восприятие информации.
  • Следует избегать переноса одного слова. Решить эту проблему можно используя неразрывные пробелы или принудительные переносы в других местах.
  • Не стоит использовать перенос внутри слов.
  • Если есть возможность (например, когда длина строк фиксирована), переносы нужно расставлять так, чтобы на одной строке стояли связанные по смыслу словосочетания.
  • Короткие слова и предлоги не должны стоять в конце строки, передними необходимо использовать неразрывный пробел.
  • Ширина макета как правило около 1400 пикселей. Этот размер условный: макет демонстрирует, как страница выглядит на экране среднего размера. Сверстанная же страница должна корректно отображаться на экранах любых размеров (следует тестировать от 320 до 1920 пикселей).
August 2, 2018
by Ilya Sablin
0
46

Руководство по разработке продуктового дизайна


Софт

Photoshop предоставляет огромное количество плагинов, которые могут облегчить ваш рабочий процесс, но мы рекомендуем использовать Figma или Adobe XD. Эти программы совмещают преимущества использования векторной графики с простотой работы над растровыми изображениями, что особенно полезно при создании дизайна для устройств с большой плотностью пикселей. Используя Figma или XD, вы не будете переживать о выбранных цветовых профилях, а размер рабочих файлов будет в разы меньше. В итоге вы получите много полезных функций, которые смогут ускорить рабочий процесс.


Наименование файлов

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

  • Используйте латинский алфавит.
  • Не используйте пробелы.
  • Используйте нижний регистр (lowercase).
  • Используйте @2x- или @3x-постфиксы для подготовки изображений для устройств с разной плотностью пикселей.
  • Используйте эти же правила для именования папок.
  • Вкладывайте смысл в названия.


Оптимизация изображений

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

Посмотрите на гайд по оптимизации изображений от Google и следуйте следующим правилам:

  • Используйте JPG для изображений без прозрачности и в тех случаях, когда вы можете пожертвовать качеством картинки в пользу размера.
  • Для максимального качества и поддержки прозрачности используйте PNG.
  • Для анимаций используйте видеоформаты или гифки. Но GIF-анимация будет более хорошего качества при меньшем весе.


Инструменты для оптимизации изображений

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


Старайтесь использовать SVG

При использовании SVG вы не будете волноваться о подготовке изображений для устройств с разной плотностью пикселей, создавая версии @2x и @3x. Также не придётся создавать версии одного файла с разрешениями для разных частей сайта (к примеру, логотип в футере и в шапке может быть разного размера, но с SVG вы будете использовать один файл). Другое преимущество SVG в том, что векторная графика занимает намного меньше места и является текстом, что позволяет эффективно производить сжатие на стороне сервера с помощью gzip для последующей передачи клиенту.

Несколько правил о работе с SVG

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

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

Пример, когда вы вставили base64-изображение в SVG

Уберите из SVG всю ненужную информацию с помощью SVGOMG. Обычно SVG содержит разные мета-данные (заголовок, описание). Также экспортированный SVG имеет prettify-код вместо inline минимизированного. Также могут присутствовать неиспользуемые группы и пустые контейнеры. Всё это можно убрать без потери качества с помощью SVGOMG.

Проверяйте SVG в браузере перед тем, как передать файлы разработчикам. Это позволит убедиться в том, что вы экспортировали SVG правильно и браузер отрендерил всё корректно.

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


Определите приемлемую степень сжатия для нестатических изображений

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


Favicon

Подготовьте два PNG-файла с разными разрешениями:

  • Первый: favicon.png с размером 32×32. Все современные браузеры поддерживают PNG-формат для favicon, и вам не нужно конвертировать его в ICO.
  • Второй: favicon-180×180.png с размером 180×180 для мобильных устройств.

Многие авторы заявляют, что нужно подготавливать большое количество версий favicon: 16×16, 24×24, 48×48 и так далее. Не стоит тратить на это время, так как в подавляющем большинстве случаев будет достаточно 32×32 и 180×180 версий. При необходимости браузер сможет сделать ресайз изображения до необходимого ему формата. Также не забывайте использовать инструменты по оптимизации изображений и для Favicon.


Grid

Держите в голове поведение CSS Grid Systems при разработке дизайна. Посмотрите на Bootstrap Grid — очень популярный CSS-фреймворк. Эта сетка будет покрывать большинство стандартных случаев, также она проста в настройке для разработчика. Главное понимать, что ширина колонок в CSS-фреймворках относительная, но имеет статический размер внутреннего паддинга. Bootstrap Grid по умолчанию имеет 12 колонок и внутренний паддинг 15 px, но при этом легко кастомизируется.

Когда вы создаете UI, то всегда работаете со статической картинкой, следовательно размер контейнера также будет статическим. Например, если размер артборда 1920 px, рабочая область 960 px, то размер одной колонки равен 80 px, где с каждой стороны будет отступ 15 px, а ширина внутренней части колонки 50 px.

Когда вы построили UI с использованием такой сетки, разработчику не придётся постоянно измерять размер некоторых объектов. Он просто будет знать, что элемент занимает, к примеру, две колонки. Просто покажите разработчику overlay с колонками, и он будет задавать их размер с помощью классов, таких как .col-sm-2, .col-sm-6.

Responsive дизайн

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

Если вы подготовили несколько версий страницы для 320×568, 1024×768 и 1920×1080, это не означает, что ваша работа закончена. Вам по-прежнему нужно объяснить разработчику, что будет происходить в переходах между разрешениями:

  • Что будет происходить с колонками и контентом внутри на каждом брейкпоинте.
  • Что будет происходить с размером контейнера на разных разрешениях (будет он занимать всю ширину экрана или примет новое статическое значение).
  • Как изменения разрешения повлияют на размеры изображений. Рассмотрим пример: есть картинка 200×200 px в десктопной версии, и вы решили, что изображение на мобильной версии будет занимать 100% контейнера, например, на устройстве с разрешением 375×667 px. В таком случае вам придётся иметь изображение 750 px по ширине для того, чтобы не получить размытую картинку на устройствах с большей плотностью пикселей.

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

Используйте стандартный набор брейкпоинтов: 320×568, 375×667, 768×1024, 1024×768, 1280×768, 1366×768 и 1920×1080. И не забывайте про landscape-режим на мобильных устройствах.

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


Не изобретайте велосипед

Если у вас нет достаточного количества времени и вы не уверены, что сможете продумать компонент от начала до конца (к примеру, dropdown или datepicker), попросите разработчика показать, какую библиотеку он привык использовать для этих целей, и просто стилизуйте её под общий UI Kit.

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

  • Как будут выделены даты предыдущего месяца.
  • Какой будет hover-эффект на каждую дату.
  • Как будете выделять текущую дату.
  • Как будете выделять выбранную дату.
  • Как будет выглядеть переключение месяцев, лет.


Анимации и прототипы

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

Используйте Principle, Framer или Adobe After Effects для анимаций. Это поможет избежать недопониманий между вами, разработчиками и клиентами, а также позволит протестировать ваши предположения. Анимации и прототипы помогают делать более крутые презентации ваших идей для клиентов.


UI Kits

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

В UI Kit вы должны добавить цвета, шрифты, компоненты (кнопки, формы, слайдеры), показать состояния объектов (active, hover, default). Используйте D.R.Y. («Don't Repeat Yourself»): принцип по которому вы думаете, что необходимо поместить в UI Kit, а что нет. Если вы используете два одинаковых элемента в рамках страницы, то смело помещайте его в UI Kit.

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

Мы рекомендуем использовать Craft для создания вашей UI-библиотеки. Также для больших проектов хорошей практикой является создание HTML, CSS-версии UI Kit и использование именно её для контроля качества элементов.


Экспорт

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

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

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

Старый подход описания макетов, популярный в Photoshop


Состояния элементов

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

  • Default.
  • Hover — состояние элемента при наведении мышкой.
  • Active — состояние при клике или нажатию на элемент.
  • Focus — состояние текущего выбранного поля (inputs, text areas).
  • Visited — состояние ссылки, на которую уже переходил пользователь.

Примеры состояний элементов


Line-height

Понимание line-height — неотъемлемая часть работы над дизайном и процесса передачи макетов разработчику. Для этого необходимо знать, как браузер производит рендер элементов на странице и как line-height влияет на это. Посмотрите на изображение ниже. Это типичный пример текстового блока и того, как браузер воспринимает его высоту. Высота блока совпадает с величиной line-height.

Одно из преимуществ использования Sketch в том, то что он рендерит текстовые объекты по такому же принципу как и браузер. А в Photoshop line-height никак не влияет на размер блока.

Хорошей практикой является использование line-height близким по значению к line-height шрифта. Не используйте много разных значений line-height в рамках одного проекта. К примеру, Roboto имеет 1,4x line-height от размера шрифта. Это означает, что при шрифте 16 px line-height будет 22 px.

Даже если вы решите использовать нестандартное значение, старайтесь использовать одну и ту же пропорцию на протяжении всего сайта. Наиболее частыми значениями являются 1,3 — 1,6 от размера шрифта. Разработчики это оценят. Они смогут задать line-height глобально и им не придётся отдельно устанавливать и проверять line-height каждого элемента. Они продолжат работать только с размером шрифта.

Теперь немного поговорим о поведении с нецелочисленными значениями в разных браузерах. Для примера возьмём:

  • Размер шрифта — 36 px.
  • Line-height — 1,4.

Chrome, Safari, Opera считают line-height с использованием только целочисленных значений, отсекая цифры после запятой. К примеру, в расчёте 36 px * 1,4 = 50,4 эти браузеры оставят 50.

Но Firefox учитывает значения после запятой. В результате 36 px * 1,4 = 50,4 будет всё равно 50,4 px. Визуально разница будет заметна в случае рассмотрения примера с двумя строчками текста. На изображении ниже line-height = 1,41. В Chrome, Safari и Opera размер элемента будет равен 100 px, тогда как Firefox будет считать высоту как 101.533 px.

Если вы хотите добиться абсолютного Pixel Perfect и поддерживаете Firefox, то задавайте максимально точную величину line-height как 1,34 653. Если для вашего проекта это не имеет значения, можете смело оставить просто 1,3.

Шрифты

Пытайтесь найти приемлемый для вас шрифт на Google Fonts. Браузеры поддерживают разные форматы шрифтов. Это означает, что разработчику придётся специально подготавливать ваш кастомный шрифт с использованием специальных сервисов по конвертации TTF/OTF в WOFF, WOFF2 или EOT. В ходе этого процесса шрифт может потерять в качестве. Поэтому моя рекомендация — используйте кастомные шрифты только в том случае, когда вы уверены, что ваши разработчики умеют с ними работать.

Ещё несколько вещей, которые необходимо знать об использовании шрифтов:

  • Не используйте больше двух шрифтов на проекте. Их количество влияет на скорость загрузки сайта.
  • Не используйте слишком много разных размеров и начертаний (italic, bold, light, thin, regular).


Разработчик и дизайнер

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

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

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

May 23, 2018
by Ilya Sablin
0
342
Show more