Использование «Задания на проектирование» при разработке интерфейсов

Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование».

Предпосылки

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

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

Можно вспомнить еще другие частные частные варианты входа в процесс проектирования интерфейсов.

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

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

Проще говоря, нужно аккуратно использовать ресурс бизнес-заказчика (product owner, клиента) — не перегружая его, но и не позволяя чересчур расслабляться. Ведь ничто так не загружает людей, как работа над большим ТЗ. Даже его вычитывание делает людей, которые специально к этому не готовились, глубоко несчастными. А те, кто готовились, выглядят уставшими.

И вот, мы определили два фактора. С одной стороны, все заинтересованы быстрее начать проект и увидеть хоть какой-то первый результат. С другой стороны, никто не хочет участвовать в написании полноценного ТЗ.

Оба фактора часто верны и для бизнес-заказчика, и для команды разработчиков.

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

Таким образом у нас сформировался процесс, в котором первым документом после сбора требований и формирования бэглога, становится Задание на проектирование.

Какие задачи решает Задание на проектирование

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

В идеальном варианте, мы должны иметь возможность отдать документ внешнему исполнителю, который не погружен в проект, который после прочтения скажет что-то вроде: «Да, в принципе понятно, можно начинать. Только есть пара вопросов.»

Кто основные пользователи Задания на проектирование

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

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

Содержание Задания на проектирование

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

Типовой состав включает:

1. Титульный лист с выходными данными
2. Историю изменений документа, если мы ввели в практику ее вести
3. Список терминов и сокращений, используемых в документе
4. Цели и задачи проекта в общем виде
5. Описание ролей/пользователей
6. Список основных сценариев с возможными исключениями
7. Описание предметной области, которые касаются интерфейсов системы

1. Титульный лист

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

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

Что может содержать:

• Название проекта
• Дата документа
• Версия документа
• Автор

2. История изменений

Хранить в документе Историю изменений — это хорошая практика, которая поможет обеспечить управляемость документом и возможность «найти концы», если до этого дойдет.

С одной стороны, дату и версию документа можно хранить на уровне титульного листа, но, если у нас начинается версионность, то хочется видеть различия в версиях. Можно не детально, но хотя бы так, чтобы понимать основные изменения. Ведь при долгом обсуждении документа, такие изменения обязательно будут. Ну а если все обсуждения проходят легко, то и История изменений будет короткой.

Что может содержать:

• Дата
• Номер версии документа, в которую внесены изменения
• Описание изменений, краткое
• Автор, который внес изменение в документ

3. Список терминов и сокращений

Вместе с Титульным листом, Историей изменений — это еще один пункт для хорошего оформления документа.

Нам нередко приходится использовать профессиональные сокращения, например, “ТЗ”, а в бизнесе сокращения встречаются еще чаще.

Как только пользователи не называют свои системы, подсистемы, подразделения и т.д!

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

Поэтому, добавление в документ списка сокращений — хорошая практика, которая поможет сократить время на объяснения и уменьшит вероятность неправильного понимания важных вещей.

4. Цели и задачи проекта

Общее описание того, что мы делаем, зачем и какой результат ожидаем получить.

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

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

5. Пользовательские сценарии

Основные пользовательские сценарии (и исключения/альтернативные сценарии к ним) описанные в простом формате.

• Название сценария (можно в формате User Story)
• Предусловия (опционально)
• Триггер (опционально)
• Основные шаги выполнения сценария

Можно делать сценарии в формате User Story, без детализации. Но следует помнить правила для описания таких сценариев. Как минимум, сценарии должны быть короткими, и обязательно нужно описывать, как позитивные, так и негативные варианты поведения системы.

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

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

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

6. Описание предметной области

Совокупность данных, которые нужны для проектирования интерфейса.

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

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

Примеры 4, 5 и 6 даны, с одной стороны — как возможные форматы таблицы данных, с другой стороны — как пример того, что формат описания может быть различным.

7. Справочники и прочие материалы

Можно включить в документ дополнительные материалы, которые помогут спроектировать интерфейсы. Чаще всего это материалы, связанные с фиксированными данными и контентом.

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

Справочники выносятся в отдельный раздел, чтобы не увеличивать раздел с описанием предметной области.

Можно не включать в документ сам справочник, а давать ссылку на него.

В заключение

Задание на проектирование подготавливается, чтобы повысить качество работы над проектом на стадии проектирования.

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

UX прототипирование