INDEXIS 
Статья поможет небольшим командам выстроить работу с внештатными и новенькими штатными дизайнерами, учесть все детали, ничего не упустить и оставить клиента довольным.
Привет! Меня зовут Дмитрий Талызин, я руковожу веб-студией INDEXIS более 10 лет. В статье будем рассматривать техпроцесс и требования для разработки дизайна сайта.
Еще в статье будут наши чек-листы. Они наработаны в процессе и не претендуют на истину в последней инстанции, но нашим менеджерам хорошо помогают.
Мы открыты к предложениям, делитесь в комментариях своим опытом и мы сделаем апдейт материалов, представленных в статье.
Вечный вопрос для клиента и разработчика: как получить красивый, выразительный, запоминающийся дизайн интерфейсов в интернет-проекте и уложиться при этом в сроки?
Один из ключей к успеху — правильная коммуникация в треугольнике «клиент — менеджер — дизайнер». Но можно ли регламентировать эту коммуникацию? Однозначно — да.
Первый этап — это сбор требований и аналитика. Мы заполняем с заказчиком бизнес бриф, чтобы понять для чего разрабатывается проект, и бриф на разработку дизайна, чтобы уловить стилистику будущего проекта. На них подробно не будем останавливаться, такие есть практически у всех.
Еще проектный менеджер составляет для заказчика документы — Business case и Устав и согласовывает их. Они нужны, чтобы заказчик понял, что мы понимаем задачу и какие в проекте существуют ограничения.
Аналитика в нашем техпроцессе тоже занимает особое почетное место и требует самостоятельной статьи.
Предположим, что брифы заполнены, аналитика и исследования проведены и приняты клиентом, двигаемся дальше.
1. Перед началом работы нужно убедиться, что в наличии есть вся необходимая информация, и внимательно ознакомиться с документами:
2. Прототип сделан в серо-белой гамме, цветные элементы сведены к минимуму, желательно полное их отсутствие.
3. Каждая страница в прототипе имеет осмысленное название. Названия типа «Frame2», «Страница1» и т.д. недопустимы.
4. Если больше 5 страниц, то присутствует нумерация в названии страниц и интерфейсы сгруппированы под одной цифрой с дополнительным индексом. Например,
3.1. Личный кабинет — редактирование регистрационных данных.
3.2. Личный кабинет — история заказов.
5. Недопустимо сдавать прототип с пустым белым пространством на листе, а также с «мусорными» элементами, которые не используются в прототипе и не несут никакой смысловой нагрузки.
6. Указаны корректные заголовки блоков страниц
7. Тексты блоков не «рыбные», а передают назначение блока. Тексты не должны быть финальными, отредактированными и т.п., просто текст должен хотя бы примерно передавать смысл самого блока, чтобы не было вот так:
8. Если по блоку не очевидно, какое тут планируется изображение и для чего, то используем либо пример фотографии (не цветной), либо подпись.
Пример очевидного фото на прототипе — изображение товара в миниатюре продукта:
Пример неочевидного блока:
Что тут будет? Просто изображения баннеров? Или html-баннеры с кнопкой/ссылкой? Или это своеобразные миниатюры товара со скидкой?
Пример UX-прототипа
UI-дизайнер должен получить исчерпывающую информацию по проекту. Поэтому мы передаем ему следующие документы:
Многие люди часто упускают важные для проекта детали. Это не зависит от квалификации дизайнера и его опыта, может сработать человеческий фактор. Поэтому важно созвониться и все важные моменты проговорить.
На этом шаге мы выделили 5 обязательных пунктов для менеджера проекта:
1. Созвониться с дизайнером.
2. Проговорить основные моменты по документам.
3. Показать прототипы. Акцентировать внимание на важных элементах. Обозначить пожелания клиента и наши идеи.
4. В конце разговора получить обратную связь от дизайнера. Убедиться, что дизайнер понял задачу, сферу деятельности клиента, был в контексте, чтобы в итоге в дизайне соблюсти баланс между пользовательским опытом и целями клиентов.
5. Составить и передать список страниц и разрешения, в которых они должны быть выполнены.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12249 тендеров
проведено за восемь лет работы нашего сайта.
В нашей практике был случай, когда дизайнер не увидел среди материалов логотип клиента. Без уточнения у менеджера, он сам разработал логотип и сделал дизайн главной страницы. В итоге дизайн получился в другой цветовой гамме и пришлось переделывать работу.
Этот документ позволяет поддерживать порядок в макетах и легче погружать новых дизайнеров в общие правила оформления, принятые в компании.
Такие макеты позволяют:
1. Сдать аккуратно оформленную работу клиенту.
2. Самим ориентироваться в трудах дизайнера.
3. Показывать дизайн потенциальным клиентам в качестве портфолио.
В документе подробно описано, как в макете оформлять обложку, группировать прототипы по интерфейсам, называть, нумеровать, оформлять страницы и др. Также в нем прописаны требования для UI-кит: шрифты, цвета, блоки, выпадающие элементы, состояние кнопок при наведении, без наведения.
Когда дизайнер заканчивает работу по подготовке макетов, ему необходимо показать анимацию в интерфейсах. Если же бюджетом проекта часы на это не предусмотрены, тогда дизайнер составляет текстовое ТЗ для верстальщика на такую анимацию. Также он может записать видео с демонстрацией экрана и референсов. Так верстальщику будет значительно проще понять задачу.
Порой даже самый внимательный дизайнер пропускает пункты в чек-листе. Для таких случаев мы предусмотрели памятку для менеджера проектов при приеме работы у дизайнера.
На данном этапе важно проконсультироваться с верстальщиком. Это необходимо, чтобы не было:
Также важно, чтобы на этапе приемки дизайнер провел предварительную защиту своего проекта перед менеджером. В процессе защиты дизайнер и проектный менеджер могут обнаружить упущенные моменты из материалов заказчика или аналитики и совместными усилиями решить все вопросы. Так проектный менеджер лучше поймет решения в дизайне и сможет аргументировать их клиенту. Благодаря этому этапу пропускается, как минимум, одна итерация правок с клиентом, и клиент от этого становится еще немного счастливее.
После подготовки готовые дизайн-макеты передаются на проверку проектировщику, которые делал UX. Чтобы он перепроверил макет на соответствие той логике, которая закладывалась, и тем решениям, которые приняли на этапе исследования.
Дизайн — вещь индивидуальная. Но работающий дизайн — результат труда команды, основанный на большом пласте знаний:
Багаж знаний позволяет доходчиво объяснить клиенту природу элементов в дизайне.
Также мы никогда не отправляем клиенту макеты заранее — файл открываем перед ним на защите и презентуем дизайн. Иногда для большей убедительности показываем референсы на других проектах, не наших. Объясняем, как работают разные решения.
При таком подходе выше вероятность успешной защиты проекта. Клиент понимает, что проделана огромная профессиональная работа, и каждое решение в дизайне взвешено и имеет за собой аргументированную позицию.
Иногда клиенты не принимают дизайн (да, такое тоже бывает). Тогда мы снова собираем список требований и референсов от клиента. Потом организуем тройную встречу: менеджер, клиент и дизайнер обсуждают дизайн проекта. Далее готовим новый макет.
Правила на этапе защиты, которые сэкономят время дизайнера и проекта:
1. Защита дизайна должна быть поэтапной. Вначале согласовываем макет главной страницы, только после этого переходим к дизайну внутренних страниц.
2. Важно получить одобрение дизайна от всех стейкхолдеров.
3. Выставить в FIGMA в настройках прототипа сразу нужное разрешение, под которое делался макет, чтобы видеть, как элементы помещаются в экран и т.п.
К планшетной и мобильной версии проекта мы переходим только после полного согласования десктопной версии. При этом в некоторых проектах мобильная версия составляет 50–70% трафика. В таких случаях мобильной версии уделяем время, равное десктопной. Если же проекту нужен подход mobile first, то мы сразу рисуем мобильную версию и прорабатываем ее максимально глубоко, а уже после принятия мобильной версии делаем desktop.
Наличие регламентов и чек-листов, следование им и частые коммуникации членов команды между собой гарантирует качественный результат.
Друзья и коллеги по digital-рынку, делитесь опытом. Будем рады вашим комментариям и дополним чек-листы.
Наша команда INDEXIS более 10 лет занимается разработкой digital-продуктов с продуктовым подходом, выпустила свыше 100 веб-проектов. Готовы помочь бизнесу построить и развивать IT-инфраструктуру для b2с и b2b продаж в интернете.
