Привет, Хабр! Тема довольно избитая, но для UX/UI специалистов, которые только начинают самостоятельно работать с заказчиками, будет полезно. Проектировщики пользовательских интерфейсов «Рексофт» собрали подборку вопросов, которые помогут выполнить работу быстрее и не вносить кучу правок. Хотя положа руку на сердце, скажем честно, тз все равно изменится по ходу проекта.

Действительно ли техническое задание представлено в финальной редакции?

Продукт начинает свой жизненный цикл с формирования сборника требований к нему. Этим сводом чаще всего является техническое задание (ТЗ). В нем подробно изложена информация о технологии работы будущего продукта, целевой аудитории, а также функциональности, которая должна обеспечивать работу этого продукта. Часто такое задание дается виде «сырца», наброска, которой в процессе работы будет обрастать подробностями. Для того, чтобы не попасть в ситуацию, когда под существенные изменения не попала часть задания, относящаяся к части дизайна и функциональным требованиям, необходимо тщательно изучить эти аспекты, максимально проговорить их с заказчиком.

Для отрисовки UI используем фирменный стиль компании (а также предыдущие UI наработки компании, если они есть) или создаем новый для конкретного продукта?

Часто новый продукт создается не на пустом месте, а в рамках другого продукта или блока сервисов компании. Исходя из этого, мы уже имеем набор стилистических и цветовых правил и требований к оформлению UI-компонентов. В этом случае следует просто подтвердить, что новый продукт будет создаваться, опираясь на эти правила. Если сервис создается «с нуля» необходимо сделать набросок так называемого mood board’a, чтобы согласовать стилистику и цветовую гамму с заказчиком.

Есть ли на рынке похожие продукты?

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

Какой диапазон устройств для использования продукта?

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

Какой будет уровень проработки прототипов?

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

• Прототип из примитивов (прямоугольники, кружки, квадраты и пр.). Здесь не требуется детальная проработка, и все UI компоненты (текст, кнопки и пр.) показаны в виде примитивов.
• Детальный прототип. Это усложнённая версия прототипа, здесь мы уже используем монохромное оформление проекта, кнопки выглядят как полноценные кнопки, а текст и заголовки приближены к реальным.
• Раскрашенный прототип. Это уже полноценный продуктовый прототип, созданный на базе уже имеющихся UI-компонентов.

Стоит предварительно узнать, как лучше преподносить заказчику прототип продукта на первоначальном этапе, так как далеко не все заказчики способны на основе примитивов увидеть целостную картину продукта.

Понятно, что это неполный список, и мы что-то забыли. Чтобы вы добавили в этот чек-лист?