Как создать макет для сайта и не остаться крайним

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

Они помогут вам:

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

Общее


  1. Именования макетов (Страниц, фреймов — обязательно) должны четко передавать суть и назначение и быть привязаны к логическим страницам сайта или другим большим сущностям.
    (Пример: “главная — планшет”, “main — mobile”, “кнопки”)
    [screen-example]
  2. Необходимо соблюдать структуру документа при работе со слоями, группами, компонентами и экранами, давать им исчерпывающие названия
    (Пример: main-background, settings, button, registration-page-mobile)
    (Плохой пример: frame 1, group 45, iphone XR)
    [screen-example]
  3. Если нужна мобильная версия, то на каждый экран должен быть разработан макет шириной 320px (iPhone SE), в дополнение к которому можно создать макеты с большим разрешением.
    [screen-example]
  4. Иконки (svg, …) должны быть выгружаемые и корректно открываться в браузере. Размер svg артборда должен соответствовать контенту и потоку. Можно собирать сеты иконок на отдельных арт-бордах.
    [screen-example]
  5. Картинки (графический контент) должны быть выгружаемые. Иметь разрешение не менее 2x. Выгружаться без предварительной обработки. (Таких, как: скругленные края, прозрачность, тень). За исключением случаев, когда такая обработка была явно запрошена.
    [screen-example]

    1. Необходимо учитывать размеры контентной области и то, что этот размер меняется от разрешения к разрешению. Тем самым “точка крепления” должна быть продумана.
    2. Контентные картинки должны выгружаться единым изображением.
      (Например: У нас есть прямоугольный блок с [фоном] который будет меняться. Соответственно, выгружаться картинка должна полностью с фоном, как на примере выше.)

  6. Цвета шрифтов не должны содержать alpha-канал (прозрачность), за исключением случаев, когда шрифт используется на разных фонах (градиентах или изображениях) и потому должен иметь такую логику.
  7. Полный список (zip.архив) используемых в проекте шрифтов должен предоставляться в первую очередь (до начала работ по фронту).
  8. Также не помешает подобрать безопасный шрифт (которые есть во всех ОС Windows, Mac, Linux и т.д.), похожий на используемый кастомный, чтобы его можно было подставить на случай ошибки загрузки кастомного шрифта
    (Пример: ‘Roboto’, sans-serif)
  9. Если имеем дело с кастомным иконочным шрифтом, то с иконками надо обращаться соответствующе, а именно: нужно выравнивать по базовым линиям, чтобы несколько иконок в ряду не были разного размера и с разными отступами. Также количество начертаний, базовая толщина начертаний, уровень детализации должны сохраняться от иконки к иконке, иначе они будут выглядеть разнородно, словно из разных наборов шрифтов.
  10. При отсутствии специальных требований к логике поведения, блоки в потоке должны сохранять последовательность своего расположения при адаптиве на тех разрешениях, которые отражены в требованиях.
  11. Логика должна быть отражена в дизайне. Например, несколько одинаковых карточек, в каждой из которых отобразить разное количество контента, разные изображения, разные состояния и т.д., чтобы появилась возможность проследить зависимость.
  12. В дополнение к макету приветствуется текстовое описание работы элементов
  13. Указать поведение элементов при переполнении текстом 
    (Например, обрезать длинный текст многоточием в блоке и т.д.)
  14. Оставлять комментарии и описание (любым способом) к анимированным элементам и элементам, поведение которых невозможно однозначно определить только по макету.
  15. Должна присутствовать страница 404, 500, и другие стандартные экраны

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

Гайд, GUI, UI-kit, Style Guide


  1. Описание и макеты блоков, связанных общей функциональностью, приводятся в одном разделе документа.
    (Например, все всплывающие окна имеют белый фон и скругления углов 10px, кнопки … )
  2. Типографика должна быть описана и отрисована дополнительно на отдельном артборде.
    (Пример: Все заголовки первого уровня имеют размер 24px и отступ снизу 40px. Все заголовки второго уровня …, параграфы …, и тд.)
  3. Все ссылки, кнопки, чекбоксы и др. интерактивные элементы должны быть отрисованы в пассивном, наведенном, активном состоянии. Аналогично этому должны быть состояния для мобилки (тач-устройств) — пассивное, момент-нажатия. Состояния: (link, hover, active, focus, visited, disabled, process).
    [Checkbox-example]
    [Buttons-example]
  4. Навигационные цепочки (Breadcrumbs) должны быть отрисованы во всех состояниях (активный, предыдущий, заблокированный, …) и с учетом переноса строк.
  5. Пагинация должна быть отрисована во всех состояниях (на первом, последнем, промежуточном шаге) И с разном количеством шагов (1, много) с учетом большого (3+ символа) количества цифр.
  6. Инпуты (поля ввода), формы должны быть отрисованы во всех состояниях: по умолчанию, при фокусе, при нажатии, заблокированная, сообщение об ошибке, сообщение о корректности и тд.
    [Input-example]
  7. Ограничить количество используемых цветов и оттенков
    [Color-level-example].

    1. Все используемые цвета должны быть вынесены гайд.
      (Любой новый цвет в макете будет считаться ошибкой и будет приравнен к ближайшему из гайда)
    2. Уникальные с точки зрения функциональности цвета должны быть описаны или привязаны к сущности. 
      (Например, виджет акции на halloween с единственным оранжевым фоном: оранжевый — цвет для акций на halloween)

Сетка


  1. Размеры отступов и элементов должны быть кратны одному значению
    (2px, 4px, 8px, 5px… )
    [screen-example]
    [post-example]
  2. Сетка (если есть) должна быть описана и не противоречить
    макетам. Размеры колонок, их кол-во и т.д.
  3. Размеры контейнера должна быть описаны на каждом из представленных
    разрешений.
  4. Значения breakpoints должны быть описаны.
  5. Вертикальные отступы блоков в потоке должны быть стандартизированы. (аналогично типографики)

Письма, почта, рассылки, mail


  1. Необходимо делать дизайн письма как можно проще. Важно понимать как работает вёрстка и тег < table >. Письма верстаются на таблицах. (display: block, flex, position absolute — в письме применить не получится). Адаптив максимально простой без блоков, меняющих своё положение в потоке. Желательна обычная “резина” и 1 набор стилей
  2. Не использовать кастомные шрифты в письме


Конечно если вы рисуете для «дрибла» и т.п. то можете делать, что хотите, но для серьёзного проекта эти пункты необходимы на 100%.


ссылка на оригинал статьи https://habr.com/ru/post/466557/

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *