SLAMSOFT 
Тендеры и лиды
Информация
Меня зовут Игорь Повшок, я сооснователь и коммерческий директор в SLAM.
SLAM — компания с фокусом на разработку и развитие eСommerce-проектов.
Мы разрабатываем, поддерживаем и продвигаем сайты, внедряем CRM Битрикс24, создаем мобильные приложения.
В статье вы найдете полный чек-лист, по которому работают дизайнеры SLAM. Документ является практически исчерпывающим документом, который будет полезен любому дизайнеру. В работе мы используем подходы бережливого производства, поэтому для нас важно, чтобы при переходе проекта из одного этапа во второй, количество доработок и вопросов от фронтенд-специалиста к дизайнеру отсутствовало или было минимальным. Хорошо подготовленный макет — это до 30% экономии времени вашего верстальщика и количества багов на этапе тестирования верстки.
1. В проекте должна быть разработана цветовая схема.
2. Аналогичная схема должна быть разработана для всех используемых шрифтов. (Так же использовать нейминг в проекте — называем шрифты осмысленно).
3. Если проект рисуется с нуля, то все макеты должны лежать на одной странице Figma. Для проектов на поддержке стоит их разбивать на разные страницы под каждую новую задачу. Каждая страница в таком случае должна иметь правильное понятное всем название. Не Page 1, а, например, Великий камень: раздел для партнеров.
4. Для общих сквозных элементов сайта все состояния и ховеры должны быть отрисованы на эталонной странице. Для уникальных или очень редких элементов состояния и ховеры рисуются рядом с этим элементом прямо рядом с макетом.
5. Логотип проекта всегда должен быть нарисован в SVG. Если его нет от клиента, отрисуйте его самостоятельно по предоставленному PNG.
6. Отступы всех элементов должны задаваться отступами, которые можно сразу померить. Не Line Height текста, не межстрочными интервалами и т. д.
7. Сложные коллажи из фото должны быть объединены в единую группу (если планируется, что это будет один слой на верстке).
8. Составные изображения обязательно группируем в макетах, чтобы даже те, у кого нет доступа к редактированию макета (менеджеры и т.д.), могли легко экспортировать нужные элементы.
9. Все макеты в Figma должны иметь соответствующее правильное название.
10. Обязательно показываем сетку и направляющие.\
11. Состав элементов эталонной страницы:
1. Правила ширины фреймов: ширина фрейма должны быть 1920px (если в проекте не заложены варианты под Retina или варианты под SMART TV). Речь не про ширину дизайн-макета, а именно про ширину фрейма. Если сделать меньше, то при демонстрации заказчику по краям макета буду черные полосы + у верстальщика будут вопросы по блокам со 100% заливкой по ширине.
2. Разрешения дизайн-макетов.
В наших проектах максимальное разрешение 1500 или 1400. Макеты могут по согласованию с менеджером иметь кастомные брейкпоинты для адаптива. Но если у вас нет других вводных, руководствуйтесь стандартными брейкпоинтами Bootstrap.
Дополнительно:
3. Когда вы рисуете разные пропорции картинок для десктопа/планшета и мобайла — согласуйте эту логику с менеджером, чтобы понимать, будет ли готов клиент поддерживать разработку нескольких версий картинок для одного блока. Или проще пропорционально перестраивать картинку, чтобы один вариант поддерживался всеми разрешениями.
4. Для листингов с динамическим контентом всегда показываем вариант отображения элементов превью в 1,2,3 и т.д. строки (или вариант с ограничением по строкам, например, с многоточием или фейдом текста), чтобы показать верстальщику логику перестроения элементов по сетке.
5. Рисуем вариант зафиксированного хедера в 1 строку.
1. Вне зависимости от наличия в проекте, должны быть прорисованы:
2. Показать дизайн поп-апа.
3. Показать дизайн нотификаторов добавления в корзину: успешно, возникли проблемы, ошибка.
4. Рисуем картинки размерами w:1200 h:630 и w:300 h:300 для превью при шаринге в различных соц. сетях и мессенджерах.
5. Обязательно рисуем заглушку для всех элементов, где может быть фото (товар, статья в превью и т.д.), на случай, если картинка отсутствует или не выгрузилась.
6. Обязательно делаем дизайн 404 (страница не найдена), 500 (ошибка сервера) по желанию, если проект с упором в дизайн.
1. Название слоев либо кириллица, либо латиница, только одно.
2. Название отражает содержимое.
3. Все слои одного логического элемента в одной папке.
4. Избегать полупрозрачные градиенты и режимы наложения типа «multiply, screen, overlay, и т.д.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13202 тендера
проведено за восемь лет работы нашего сайта.
5. Не использовать сложные режимы наложения (blend mode) на любых свойствах слоя (типа inner shadow, drop shadow и т.д.).
6. Обязательно показываем сетку и направляющие.
1. Использовать не больше 2 шрифтов (заголовки, основной текст).
2. Использовать не более 3-4 начертаний шрифта.
3. Не использовать прозрачность для шрифтов.
4. В текстах нет грубых грамматических ошибок.
5. Не используем в дизайне light и extralight гарнитуры на мобайле для основных блоков текста, если только это не специальный дизайн-прием для создания нужной эстетики.
6. При разработке стараемся использовать минимальное количество шрифтов и гарнитур, выбирайте те шрифты, где и буквы, и цифры выглядят хорошо. Помните, что жирности тоже влияют на общий вес шрифтов в проекте. Поэтому не надо использовать просто так и Bold, и ExtraBold и Black без необходимости.
7. Серый цвет не должен использоваться как основной цвет текста на проекте, особенно в статьях, описаниях, характеристиках. Только как нейтральный цвет для опциональных и служебных элементов страниц (тултипы, плейсхолдеры, элементы футера, подписи к фото и таблицам и т. д.).
8. Не используем просто так платные или кастомные шрифты, только Google Fonts. При использовании платных или кастомных шрифтов архив с ИСПОЛЬЗУЕМЫМ начертаниями прикрепить к проекту при передаче макетов на верстку.
9. Обязательно делаем таблицу адаптивности шрифтов: десктоп-мобайл. И строго соблюдаем эти размеры в макетах.
10. На мобайле не должно быть шрифта ниже 14px (валидаторы гугла будут ругаться и снимать баллы в Google pagespeed insight), основной шрифт текста желательно должен быть не ниже 16px. Для меню тапбара и всяких служебных нотификаторов типа блока с cookies можно сделать шрифт 12.
11. Составление схемы используемых шрифтов с адаптивом. И обязательно использование одного размера как в моб версии, так и на десктопе (т.е, если мы для заголовка используем шрифт h2, значит в моб. версии должен использоваться тот же шрифт h2, а не менять его например на h3). Использовать не больше 6 размеров для заголовков (h1 ... h6). Шрифты вынести в uikit.
12. Не используем рыбные тексты Lorem ipsum в макетах.
13. Каждый текстовый элемент страницы должен быть привязан к конкретному шрифту из шрифтовой схемы, чтобы верстальщик сразу мог подкидывать нужный класс шрифта при верстке.
1. КАЖДЫЙ кликабельный элемент сайта должен иметь ховер.
2. Ховеры должны быть сильно заметны и отличны от статичного текста. Предпочтительно использование двойного ховера для элементов меню, кнопок, тегов и т.д. (например, цвет и подчеркивание/бордер/заливка и т. д.).
3. Статический текст, ховеры и цвет ссылок должны иметь понятную логику и отличаться друг от друга визуально.
4. Отрисовать default, hover, focus и disabled состояния для кнопок, ссылок, инпутов. Для инпутов также отрисовать состояния error с валидацией.
5. Показать все состояния полей форм: input, textarea, select, check-box, radio-button.
6. Для всех полей и выпадающих списков отрисовать варианты, когда текст не вмещается в строку поля.
1. Иконки делаем всегда в контейнере одного размера. Что касается самих иконок, то они в идеале должны быть:
2. Рисуем фавикон в svg формате размером от 16×16 до 192×192. Фавикон должна быть читаемая и понятная в маленьком размере. Поэтому логотип как фавикон — плохое решение.
3. Отрисовать иконки основных форматов файлов для документов: pdf, docx, xls, txt, ppt, mp4, rar, zip, jpg, gif, png, avi, mp3 (остальное в зависимости от проекта).
4. Для ряда иконок всегда надо рисовать несколько состояний:
1. В превью товаров (если это не противоречит ТЗ проекта) нужно показать следующие элементы:
2. Всегда рисуется отдельная страница заказа для истории заказов (логика 1C-Битрикс проектов).
3. Есть ряд страниц, на которые можно попасть просто по url, дизайн этих страниц должен быть прорисован:
Вам понравилась статья? Подписывайтесь на наш телеграм-канал! Там мы делимся интересными кейсами и жизнью нашей компании!
