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

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

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

Такие проблемы возникают, когда не повезло с подрядчиками. В лучшем случае макет слишком долго висит в разработке, в худшем — на этапе вёрстки оказалось, что не хватает элементов, а те, что есть — сделаны «спустя рукава» и надо все переделывать.

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

Мы же, 65pixels — часть IT-компании, специализирующейся на разработке мобильных приложений и сайтов. Мы с разработчиками — одна команда, вместе ходим на встречи к клиентам, участвуем в формировании ТЗ и по пятницам на кухне пиво пьем. Поэтому знаем, как выглядит дизайн-макет, который легко взять в работу, и готовы поделиться советами ;)

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

1. Какие основные цели и задачи у приложения/сайта? Проверяем наличие заложенной функциональности. Просто идём по пунктам технического задания (или функциональных требований). Пока ничего сложного — проверяем подрядчика на внимательность и ответственность.

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

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

4. Отображены ли все возможные состояния полей и реакции интерфейса на неверно заполненные/незаполненные поля? Когда вы уже проанализировали сценарий в целом, время приступать к доскональному изучению каждого отдельного экрана. Здесь рекомендации те же — убедитесь, что подрядчик ничего не забыл. Проще всего это сделать, сравнивая макет с подробной документацией по пунктам.

5. Как ведёт себя динамический текст, все ли слова помещаются внутрь элементов, какие ограничения по символам, встречаются ли одиночные знаки препинания/предлоги на отдельных строках, соблюдаются ли отступы/интервалы при изменении текста? Работа с типографикой очень важна, потому что текст — основа коммуникации. Он должен быть читабельным при любых условиях. Про красоту забывать тоже не стоит, опрятность блоков формирует доверие, потому что с некачественными сайтами пользователи чаще всего сталкиваются у пиратов и мошенников.

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

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

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

8. Насколько понятны текстовые формулировки в элементах навигации: кнопках, ссылках, таббарах и по контенту в целом (в заголовках, подсказках, описании)? Как и многие другие, этот пункт про удобство пользования. Там, где не помогает интуиция, пользователя должен сопровождать короткий и понятный текст.

9. Проверены ли цвета на контрастность и восприятие пользователями? Этот вопрос — забота об удобстве пользования: недостаточно контрастно — трудно читать и ориентироваться, слишком контрастно — устают глаза. На этом этапе важно также понимать, что экраны разных устройств и моделей по-разному воспроизводят цвета, поэтому важно убедиться что макет будет удобен на большинстве из них.

10. Используются ли компоненты, чтобы повысить легкую масштабируемость макета? Макет должен быть хорошо организован, чтобы вам было удобно вносить изменения, а разработчикам — экономить время на повторяющихся элементах. Часто компоненты выносятся в отдельный UI-kit — набор основных элементов интерфейса.

11. Проставлены ли связи в макетах, чтобы разработчики и все, кто будет взаимодействовать с макетами, могли по ним ориентироваться? Связи отражают переход между состояниями интерфейса: нажал сюда — стало так. Это неотъемлемая часть прототипа, без неё разработчикам придётся попотеть, чтобы понять, что имел в виду дизайнер.

12. Учтены ли все разрешения девайсов, на которых будет использоваться дизайн? Больше половины активных пользователей интернета — это пользователи смартфонов. Если сайт не будет адаптирован для них, вы потеряете половину покупателей. В идеальной ситуации их должно быть не меньше трёх — под экраны шириной в 1440, 768 и 320 пикселей.

13. Используется ли сетка, и насколько все элементы и отступы ей соответствуют? Без сетки сайт будет выглядеть неаккуратно, а разработчик будет мучиться, вычисляя отступы. Работая по сетке, дизайнер экономит время себе и программисту, а значит, бережно относится к вашим деньгам.

14. Подготовлены ли интерактивные прототипы и анимации для понимания поведения интерфейса в динамике? Разработчикам, которые будут заниматься анимацией и переходами должно быть ясно, как ведёт себя сайт, самый лучший способ это объяснить — показать.

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

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