Для чего нужны прототипы интерфейсов в Техническом Задании

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

Статья пригодится тем, кто часто пишет ТЗ в сервисных (работающих с внешними клиентами) и продуктовых (работающих с внутренними клиентами, в виде начальников) компаниях.

Orana Velarde

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

Вариант 1. Заказчик заказал индивидуальный дизайн для своего B2C проекта.

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

И у клиентов, и у разработчиков не возникает вопросов, где же будет стоять эта красивая красная кнопка. Все согласуется поэтапно.

Вариант 2. Заказчик использует шаблон для своего интранет проекта.

Особенности такого проекта:

  • Допустим это автоматизация части бизнеса, внутри компании

  • Доступ к кабинетам имеют только сотрудники компании

  • Нет необходимости отдельно рисовать пользовательский интерфейс и делать его графически уникальным, в корпоративном стиле.

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

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

Кроме того, если дать команде разработки задачу – «поставить заданные функции в интерфейс», справятся с этим далеко не все, а на визуальные правки может уйти куча времени при сдаче этапа проекта.

Tyler Wayner

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

Решение проблемы

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

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

Почему это необходимо делать даже на маленьких проектах и взять за правило

  • Упростит презентацию проекта клиенту перед разработкой

  • Поможет поймать упущенные моменты в самом ТЗ

  • Поможет объяснить разработчикам расположение элементов

  • Ускорит процесс производства

  • И в итоге – увеличит доходность, пусть не на 20%, но и 2-3% тоже деньги.

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

0
Комментарии
-3 комментариев
Раскрывать всегда