Связаться с нами

19 требований к дизайну, которые облегчат жизнь верстальщику


Array ( [TAGS] => [~TAGS] => [SHOW_COUNTER] => 2918 [~SHOW_COUNTER] => 2918 [PREVIEW_TEXT] => Хотим поделиться нашими наработками в области бюрократии разработки регламентов. А точнее, общие требования к дизайн-макетам и материалам. [~PREVIEW_TEXT] => Хотим поделиться нашими наработками в области бюрократии разработки регламентов. А точнее, общие требования к дизайн-макетам и материалам. [PREVIEW_PICTURE] => Array ( [ID] => 425 [TIMESTAMP_X] => 10.12.2015 09:45:00 [MODULE_ID] => iblock [HEIGHT] => 250 [WIDTH] => 250 [FILE_SIZE] => 20988 [CONTENT_TYPE] => image/jpeg [SUBDIR] => iblock/5ef [FILE_NAME] => 5efd03701ee36f5c4369a9a101975f24.jpg [ORIGINAL_NAME] => startup-photos-preview.jpg [DESCRIPTION] => [HANDLER_ID] => [EXTERNAL_ID] => ea448afc2deb5bd911c8c4bfd188fb93 [~src] => [SRC] => /upload/iblock/5ef/5efd03701ee36f5c4369a9a101975f24.jpg [UNSAFE_SRC] => /upload/iblock/5ef/5efd03701ee36f5c4369a9a101975f24.jpg [ALT] => 19 требований к дизайну, которые облегчат жизнь верстальщику [TITLE] => 19 требований к дизайну, которые облегчат жизнь верстальщику ) [~PREVIEW_PICTURE] => 425 [DETAIL_PICTURE] => [~DETAIL_PICTURE] => [ID] => 380 [~ID] => 380 [NAME] => 19 требований к дизайну, которые облегчат жизнь верстальщику [~NAME] => 19 требований к дизайну, которые облегчат жизнь верстальщику [IBLOCK_ID] => 5 [~IBLOCK_ID] => 5 [IBLOCK_SECTION_ID] => 7 [~IBLOCK_SECTION_ID] => 7 [DETAIL_TEXT] =>

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

При создании этого документа мы хотели достичь следующих целей:

  • уменьшить время на коммуникации между дизайнером и верстальщиком;
  • увеличить качество работы дизайнера;
  • дать возможность дизайнеру исправить свои «косяки» до передачи макета верстальщику;
  • и при этом, не создавать лишней работы дизайнеру.

1. Наличие всех макетов, описанных в ТЗ в формате psd. Если предполагается, что сайт будет адаптивным, то необходимы макеты для каждого состояния ширины.

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

2. Корректное именование макетов (название должно отражать содержимое, например, main, catalog, catalog-list и т.д.)

Чтобы не путаться в названиях, именуем макеты обдуманно.

3. Наличие полноразмерного jpg в качестве превью макета (для макетов, содержащих на отключаемых слоях значимые элементы нужно несколько превью). Название превью совпадает с названием psd (+ комментарий, если превью несколько).

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

4. Наличие файлов favicon. Иконки должны быть заранее подготовлены в формате png в размерах:

  • 16х16 (favicon.png)
  • 32х32 (favicon2x.png)
  • 72x72 (apple-touch-icon-72x72-precomposed.png)
  • 76x76 (apple-touch-icon-76x76-precomposed.png)
  • 114x114 (apple-touch-icon-114x114-precomposed.png)
  • 120x120 (apple-touch-icon-120x120-precomposed.png)
  • 144x144 (apple-touch-icon-144x144-precomposed.png)
  • 152x152 (apple-touch-icon-152x152-precomposed.png)

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

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

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

6. Если в макете предполагается анимация (например, при прокрутке страницы), желательно сопроводить макет описанием этой анимации или сделать видео/gif-анимацию.

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

7. Эффект Блюр: только для всего блока целиком, при этом блок не должен быть динамичным (например, google карта).

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

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

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

9. В макете для всех элементов, меняющих свое состояние, должны быть отрисованы состояния:

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

В макете слои с состояниями должны быть подписаны, чтобы не перепутать, например, hover и focus.

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

10. Для макетов, содержащих формы, предусмотреть отображение ошибок. Например: при отправке незаполненного обязательного поля меняется цвет границы поля ввода.

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

вместо:

11. Все слои/папки в psd должны быть именованы.

Извечная претензия верстальщиков к дизайнерам – организация слоев в psd макетах. Не дадим повода для драки :).

12. Должна быть минимальная сетка которая может покрыть весь макет.

Не дадим возможности дизайнеру хаотично разбрасывать элементы по странице… ну только если он сможет обосновать такой подход. Это, кстати, экономит время верстальщика и позволяет получить pixel perfect верстку без оговорок вроде «ну да, промахнулся на 1 пиксель, когда рисовал».

13. Предусмотреть лого со ссылкой на сайт разработчика.

Если предусмотрена такая возможность, то нужно ею воспользоваться.

14. Предусмотреть стили типовых элементов:

  • абзац;
  • список;
  • таблица;
  • ссылка;
  • заголовки h1-h6;
  • элементы форм.

15. Максимальное использование реальной информации. Например, если клиент предоставил email ochen-ochen-ochen-dlinnyi@domen.ru, то и в макете нужно использовать его, а не info@example.ru.

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

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

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

17. Не забыть нарисовать страницу 404, даже если ее нет в смете.

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

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

Мы честные! =)

19. Корректная типографика.

Иначе все равно верстальщик попросит исправить:

Купите у нас соль ,сахар ,крекеры. ООО "Компания" - лидер на рынке крекеров

на:

Купите у нас соль, сахар, крекеры. ООО «Компания» – лидер на рынке крекеров.

[~DETAIL_TEXT] =>

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

При создании этого документа мы хотели достичь следующих целей:

  • уменьшить время на коммуникации между дизайнером и верстальщиком;
  • увеличить качество работы дизайнера;
  • дать возможность дизайнеру исправить свои «косяки» до передачи макета верстальщику;
  • и при этом, не создавать лишней работы дизайнеру.

1. Наличие всех макетов, описанных в ТЗ в формате psd. Если предполагается, что сайт будет адаптивным, то необходимы макеты для каждого состояния ширины.

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

2. Корректное именование макетов (название должно отражать содержимое, например, main, catalog, catalog-list и т.д.)

Чтобы не путаться в названиях, именуем макеты обдуманно.

3. Наличие полноразмерного jpg в качестве превью макета (для макетов, содержащих на отключаемых слоях значимые элементы нужно несколько превью). Название превью совпадает с названием psd (+ комментарий, если превью несколько).

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

4. Наличие файлов favicon. Иконки должны быть заранее подготовлены в формате png в размерах:

  • 16х16 (favicon.png)
  • 32х32 (favicon2x.png)
  • 72x72 (apple-touch-icon-72x72-precomposed.png)
  • 76x76 (apple-touch-icon-76x76-precomposed.png)
  • 114x114 (apple-touch-icon-114x114-precomposed.png)
  • 120x120 (apple-touch-icon-120x120-precomposed.png)
  • 144x144 (apple-touch-icon-144x144-precomposed.png)
  • 152x152 (apple-touch-icon-152x152-precomposed.png)

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

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

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

6. Если в макете предполагается анимация (например, при прокрутке страницы), желательно сопроводить макет описанием этой анимации или сделать видео/gif-анимацию.

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

7. Эффект Блюр: только для всего блока целиком, при этом блок не должен быть динамичным (например, google карта).

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

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

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

9. В макете для всех элементов, меняющих свое состояние, должны быть отрисованы состояния:

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

В макете слои с состояниями должны быть подписаны, чтобы не перепутать, например, hover и focus.

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

10. Для макетов, содержащих формы, предусмотреть отображение ошибок. Например: при отправке незаполненного обязательного поля меняется цвет границы поля ввода.

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

вместо:

11. Все слои/папки в psd должны быть именованы.

Извечная претензия верстальщиков к дизайнерам – организация слоев в psd макетах. Не дадим повода для драки :).

12. Должна быть минимальная сетка которая может покрыть весь макет.

Не дадим возможности дизайнеру хаотично разбрасывать элементы по странице… ну только если он сможет обосновать такой подход. Это, кстати, экономит время верстальщика и позволяет получить pixel perfect верстку без оговорок вроде «ну да, промахнулся на 1 пиксель, когда рисовал».

13. Предусмотреть лого со ссылкой на сайт разработчика.

Если предусмотрена такая возможность, то нужно ею воспользоваться.

14. Предусмотреть стили типовых элементов:

  • абзац;
  • список;
  • таблица;
  • ссылка;
  • заголовки h1-h6;
  • элементы форм.

15. Максимальное использование реальной информации. Например, если клиент предоставил email ochen-ochen-ochen-dlinnyi@domen.ru, то и в макете нужно использовать его, а не info@example.ru.

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

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

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

17. Не забыть нарисовать страницу 404, даже если ее нет в смете.

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

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

Мы честные! =)

19. Корректная типографика.

Иначе все равно верстальщик попросит исправить:

Купите у нас соль ,сахар ,крекеры. ООО "Компания" - лидер на рынке крекеров

на:

Купите у нас соль, сахар, крекеры. ООО «Компания» – лидер на рынке крекеров.

[DETAIL_TEXT_TYPE] => html [~DETAIL_TEXT_TYPE] => html [PREVIEW_TEXT_TYPE] => html [~PREVIEW_TEXT_TYPE] => html [TIMESTAMP_X] => 27.02.2017 11:09:29 [~TIMESTAMP_X] => 27.02.2017 11:09:29 [ACTIVE_FROM] => 11.12.2015 [~ACTIVE_FROM] => 11.12.2015 [LIST_PAGE_URL] => /publications/novosti/ [~LIST_PAGE_URL] => /publications/novosti/ [DETAIL_PAGE_URL] => /publications/novosti/19-trebovaniy-k-dizaynu/ [~DETAIL_PAGE_URL] => /publications/novosti/19-trebovaniy-k-dizaynu/ [LANG_DIR] => / [~LANG_DIR] => / [CODE] => 19-trebovaniy-k-dizaynu [~CODE] => 19-trebovaniy-k-dizaynu [EXTERNAL_ID] => 380 [~EXTERNAL_ID] => 380 [IBLOCK_TYPE_ID] => publications [~IBLOCK_TYPE_ID] => publications [IBLOCK_CODE] => publication [~IBLOCK_CODE] => publication [IBLOCK_EXTERNAL_ID] => [~IBLOCK_EXTERNAL_ID] => [LID] => s1 [~LID] => s1 [NAV_RESULT] => [DISPLAY_ACTIVE_FROM] => 11.12.2015 [IPROPERTY_VALUES] => Array ( [ELEMENT_META_TITLE] => 19 требований к дизайну, которые облегчат жизнь верстальщику [ELEMENT_META_DESCRIPTION] => Хотим поделиться нашими наработками в области бюрократии разработки регламентов. А точнее, общие требования к дизайн-макетам и материалам. ) [FIELDS] => Array ( [TAGS] => [SHOW_COUNTER] => 2918 [PREVIEW_TEXT] => Хотим поделиться нашими наработками в области бюрократии разработки регламентов. А точнее, общие требования к дизайн-макетам и материалам. [PREVIEW_PICTURE] => Array ( [ID] => 425 [TIMESTAMP_X] => 10.12.2015 09:45:00 [MODULE_ID] => iblock [HEIGHT] => 250 [WIDTH] => 250 [FILE_SIZE] => 20988 [CONTENT_TYPE] => image/jpeg [SUBDIR] => iblock/5ef [FILE_NAME] => 5efd03701ee36f5c4369a9a101975f24.jpg [ORIGINAL_NAME] => startup-photos-preview.jpg [DESCRIPTION] => [HANDLER_ID] => [EXTERNAL_ID] => ea448afc2deb5bd911c8c4bfd188fb93 [~src] => [SRC] => /upload/iblock/5ef/5efd03701ee36f5c4369a9a101975f24.jpg [UNSAFE_SRC] => /upload/iblock/5ef/5efd03701ee36f5c4369a9a101975f24.jpg [ALT] => 19 требований к дизайну, которые облегчат жизнь верстальщику [TITLE] => 19 требований к дизайну, которые облегчат жизнь верстальщику ) [DETAIL_PICTURE] => ) [DISPLAY_PROPERTIES] => Array ( ) [IBLOCK] => Array ( [ID] => 5 [~ID] => 5 [TIMESTAMP_X] => 23.07.2015 10:16:36 [~TIMESTAMP_X] => 23.07.2015 10:16:36 [IBLOCK_TYPE_ID] => publications [~IBLOCK_TYPE_ID] => publications [LID] => s1 [~LID] => s1 [CODE] => publication [~CODE] => publication [NAME] => Публикация [~NAME] => Публикация [ACTIVE] => Y [~ACTIVE] => Y [SORT] => 500 [~SORT] => 500 [LIST_PAGE_URL] => /publications/novosti/ [~LIST_PAGE_URL] => /publications/novosti/ [DETAIL_PAGE_URL] => #SITE_DIR#/publications/#SECTION_CODE#/#ELEMENT_CODE#/ [~DETAIL_PAGE_URL] => #SITE_DIR#/publications/#SECTION_CODE#/#ELEMENT_CODE#/ [SECTION_PAGE_URL] => #SITE_DIR#/publications/#SECTION_CODE#/?SECTION_ID=#SECTION_ID# [~SECTION_PAGE_URL] => #SITE_DIR#/publications/#SECTION_CODE#/?SECTION_ID=#SECTION_ID# [PICTURE] => [~PICTURE] => [DESCRIPTION] => [~DESCRIPTION] => [DESCRIPTION_TYPE] => text [~DESCRIPTION_TYPE] => text [RSS_TTL] => 24 [~RSS_TTL] => 24 [RSS_ACTIVE] => Y [~RSS_ACTIVE] => Y [RSS_FILE_ACTIVE] => N [~RSS_FILE_ACTIVE] => N [RSS_FILE_LIMIT] => [~RSS_FILE_LIMIT] => [RSS_FILE_DAYS] => [~RSS_FILE_DAYS] => [RSS_YANDEX_ACTIVE] => N [~RSS_YANDEX_ACTIVE] => N [XML_ID] => [~XML_ID] => [TMP_ID] => 89a0bcdc01bcf8ed825c2c5413e6ef9c [~TMP_ID] => 89a0bcdc01bcf8ed825c2c5413e6ef9c [INDEX_ELEMENT] => Y [~INDEX_ELEMENT] => Y [INDEX_SECTION] => Y [~INDEX_SECTION] => Y [WORKFLOW] => N [~WORKFLOW] => N [BIZPROC] => N [~BIZPROC] => N [SECTION_CHOOSER] => L [~SECTION_CHOOSER] => L [LIST_MODE] => [~LIST_MODE] => [RIGHTS_MODE] => S [~RIGHTS_MODE] => S [SECTION_PROPERTY] => N [~SECTION_PROPERTY] => N [VERSION] => 1 [~VERSION] => 1 [LAST_CONV_ELEMENT] => 0 [~LAST_CONV_ELEMENT] => 0 [SOCNET_GROUP_ID] => [~SOCNET_GROUP_ID] => [EDIT_FILE_BEFORE] => [~EDIT_FILE_BEFORE] => [EDIT_FILE_AFTER] => [~EDIT_FILE_AFTER] => [SECTIONS_NAME] => Разделы [~SECTIONS_NAME] => Разделы [SECTION_NAME] => Раздел [~SECTION_NAME] => Раздел [ELEMENTS_NAME] => Новости [~ELEMENTS_NAME] => Новости [ELEMENT_NAME] => Новость [~ELEMENT_NAME] => Новость [PROPERTY_INDEX] => [~PROPERTY_INDEX] => [CANONICAL_PAGE_URL] => [~CANONICAL_PAGE_URL] => [EXTERNAL_ID] => [~EXTERNAL_ID] => [LANG_DIR] => / [~LANG_DIR] => / [SERVER_NAME] => complexsys.ru [~SERVER_NAME] => complexsys.ru ) [SECTION] => Array ( [PATH] => Array ( ) ) [SECTION_URL] => )

11.12.2015

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

При создании этого документа мы хотели достичь следующих целей:

  • уменьшить время на коммуникации между дизайнером и верстальщиком;
  • увеличить качество работы дизайнера;
  • дать возможность дизайнеру исправить свои «косяки» до передачи макета верстальщику;
  • и при этом, не создавать лишней работы дизайнеру.

1. Наличие всех макетов, описанных в ТЗ в формате psd. Если предполагается, что сайт будет адаптивным, то необходимы макеты для каждого состояния ширины.

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

2. Корректное именование макетов (название должно отражать содержимое, например, main, catalog, catalog-list и т.д.)

Чтобы не путаться в названиях, именуем макеты обдуманно.

3. Наличие полноразмерного jpg в качестве превью макета (для макетов, содержащих на отключаемых слоях значимые элементы нужно несколько превью). Название превью совпадает с названием psd (+ комментарий, если превью несколько).

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

4. Наличие файлов favicon. Иконки должны быть заранее подготовлены в формате png в размерах:

  • 16х16 (favicon.png)
  • 32х32 (favicon2x.png)
  • 72x72 (apple-touch-icon-72x72-precomposed.png)
  • 76x76 (apple-touch-icon-76x76-precomposed.png)
  • 114x114 (apple-touch-icon-114x114-precomposed.png)
  • 120x120 (apple-touch-icon-120x120-precomposed.png)
  • 144x144 (apple-touch-icon-144x144-precomposed.png)
  • 152x152 (apple-touch-icon-152x152-precomposed.png)

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

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

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

6. Если в макете предполагается анимация (например, при прокрутке страницы), желательно сопроводить макет описанием этой анимации или сделать видео/gif-анимацию.

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

7. Эффект Блюр: только для всего блока целиком, при этом блок не должен быть динамичным (например, google карта).

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

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

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

9. В макете для всех элементов, меняющих свое состояние, должны быть отрисованы состояния:

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

В макете слои с состояниями должны быть подписаны, чтобы не перепутать, например, hover и focus.

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

10. Для макетов, содержащих формы, предусмотреть отображение ошибок. Например: при отправке незаполненного обязательного поля меняется цвет границы поля ввода.

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

вместо:

11. Все слои/папки в psd должны быть именованы.

Извечная претензия верстальщиков к дизайнерам – организация слоев в psd макетах. Не дадим повода для драки :).

12. Должна быть минимальная сетка которая может покрыть весь макет.

Не дадим возможности дизайнеру хаотично разбрасывать элементы по странице… ну только если он сможет обосновать такой подход. Это, кстати, экономит время верстальщика и позволяет получить pixel perfect верстку без оговорок вроде «ну да, промахнулся на 1 пиксель, когда рисовал».

13. Предусмотреть лого со ссылкой на сайт разработчика.

Если предусмотрена такая возможность, то нужно ею воспользоваться.

14. Предусмотреть стили типовых элементов:

  • абзац;
  • список;
  • таблица;
  • ссылка;
  • заголовки h1-h6;
  • элементы форм.

15. Максимальное использование реальной информации. Например, если клиент предоставил email ochen-ochen-ochen-dlinnyi@domen.ru, то и в макете нужно использовать его, а не info@example.ru.

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

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

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

17. Не забыть нарисовать страницу 404, даже если ее нет в смете.

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

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

Мы честные! =)

19. Корректная типографика.

Иначе все равно верстальщик попросит исправить:

Купите у нас соль ,сахар ,крекеры. ООО "Компания" - лидер на рынке крекеров

на:

Купите у нас соль, сахар, крекеры. ООО «Компания» – лидер на рынке крекеров.

 

2918
Последние публикации
Запуск нового направления VR/AR в Complex Systems

10.10.2017271

Презентация системы управления симуляционным центром на международной конференции

07.10.2017459

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

09.08.2017607