Можно по-разному подходить к процессу разработки сервисов и приложений. Идеальной методологии не существует, многое зависит от особенностей команды и самого проекта. Тем не менее, некоторые практики показывают себя хорошо, и в ходе различных проектов могут распространяться на все работы, обеспечивая более предсказуемый результат. Это не означает, что для конкретного проекта и команды не будет существовать более эффективного пути организации работы, но согласитесь — лучше иметь постоянно работающий хороший инструмент, чем под каждый проект пытаться найти самый лучший. Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование». В проектной работе, к которой мы в свое время привыкли, этап проектирования начинался с передачи Технического задания (ТЗ). В практике встречались ТЗ разной степени проработанности. Нередко заказчик сам готовил ТЗ и часто это были документы низкого качества, которые требовали доработок. Также, мы могли начинать проектирование интерфейсов системы, основываясь на поверхностном описании процессов и бизнес-требованиях, и в таких случаях ТЗ писалось после проектирования. Есть практики, когда клиент разделяет Техническое задание и Техническое решение, или когда BRD становится входной точкой для проектирования. Можно вспомнить еще другие частные частные варианты входа в процесс проектирования интерфейсов. Как вы видите, вариантов было много. Некоторые из них были более привычными, и можно было бы считать их хорошей практикой, которой нужно все время следовать, но… В основе нашего «но», которое побуждает менять практику лежит понимание того, что Time to market стал важным фокусом проектной работы. И вместе с этим, проект — это всегда люди, которые вовлечены со всех сторон. Так возникло убеждение, что нам надо учитывать необходимость поддержания клиентов во включенном в проект состоянии и для этого следует обеспечить контролируемую нагрузку и регулярность активностей. Проще говоря, нужно аккуратно использовать ресурс бизнес-заказчика (product owner, клиента) — не перегружая его, но и не позволяя чересчур расслабляться. Ведь ничто так не загружает людей, как работа над большим ТЗ. Даже его вычитывание делает людей, которые специально к этому не готовились, глубоко несчастными. А те, кто готовились, выглядят уставшими. И вот, мы определили два фактора. С одной стороны, все заинтересованы быстрее начать проект и увидеть хоть какой-то первый результат. С другой стороны, никто не хочет участвовать в написании полноценного ТЗ. Оба фактора часто верны и для бизнес-заказчика, и для команды разработчиков. Мы считаем, что начинать проектирование без формализованных материалов возможно — но это, в итоге, станет долгой дорогой. На таком пути прототипы могут быть инструментом выявления потребностей и согласования решений, но все затянется. Соответственно, если нас интересует сокращение времени проекта, то надо выбрать подход с документацией, но ее объем можно сократить и подготовку документов разнести во времени. Таким образом у нас сформировался процесс, в котором первым документом после сбора требований и формирования бэглога, становится Задание на проектирование. Документ подготавливается для того, чтобы организовать работу по проектированию с пониманием области проекта, учетом основных сценариев и исключений. В идеальном варианте, мы должны иметь возможность отдать документ внешнему исполнителю, который не погружен в проект, который после прочтения скажет что-то вроде: «Да, в принципе понятно, можно начинать. Только есть пара вопросов.» Задание подготавливается для команды проектирования и бизнес-заказчика. Выгода команды проектирования понятна и в основном заключается в том, что при наличии задания нет необходимости дополнительно исследовать предметную область и погружаться в понимание особенностей работы системы. При этом виден объем работ, которые можно заранее оценить и спланировать. А бизнес-заказчик получает возможность формализовать свои требования через небольшой документ, провалидировать их, ранжировать в зависимости от своих бизнес-задач. Конечно, документом могут пользоваться и другие участники проекта, кто заинтересован в получении ранней информации о функциональных возможностях интерфейса. В нашей практике Задание на проектирование стало частным случаем большого Технического задания и наследуют в себя часть его разделов только с меньшей детализацией. Типовой состав включает: Титульный лист с выходными данными. Историю изменений документа, если мы ввели в практику ее вести. Список терминов и сокращений, используемых в документе. Цели и задачи проекта в общем виде. Описание ролей/пользователей. Список основных сценариев с возможными исключениями. Описание предметной области, которые касаются интерфейсов системы. Хорошее оформление документа еще никому не мешало, и здесь это правило тоже работает, а Титульный лист — это начало хорошего оформления. При большом желании, им можно пренебречь, но чаще всего отсутствие нормального Титула объясняется исключительно ленью. Вот чтобы уменьшить количество такой лени, я добавил этот пункт. Что может содержать: Название проекта. Дата документа. Версия документа. Автор. Хранить в документе Историю изменений — это хорошая практика, которая поможет обеспечить управляемость документом и возможность «найти концы», если до этого дойдет. С одной стороны, дату и версию документа можно хранить на уровне титульного листа, но, если у нас начинается версионность, то хочется видеть различия в версиях. Можно не детально, но хотя бы так, чтобы понимать основные изменения. Ведь при долгом обсуждении документа, такие изменения обязательно будут. Ну а если все обсуждения проходят легко, то и История изменений будет короткой. Что может содержать: Дата. Номер версии документа, в которую внесены изменения. Описание изменений, краткое. Автор, который внес изменение в документ. Вместе с Титульным листом, Историей изменений — это еще один пункт для хорошего оформления документа. Нам нередко приходится использовать профессиональные сокращения, например, “ТЗ”, а в бизнесе сокращения встречаются еще чаще. Как только пользователи не называют свои системы, подсистемы, подразделения и т.д! В итоге, всякое сокращение, понятное вовлеченным участникам проекта, будет новым словом для нового человека. Или, что еще хуже, он поймет сокращение или термин неправильно, опираясь на свой прошлый опыт, который будет неприменим к текущей ситуации (законы Мерфи еще никто не отменял ). Поэтому, добавление в документ списка сокращений — хорошая практика, которая поможет сократить время на объяснения и уменьшит вероятность неправильного понимания важных вещей. Общее описание того, что мы делаем, зачем и какой результат ожидаем получить. Основная цель данного раздела — погрузить исполнителя в контекст проекта достаточно глубоко, чтобы он ясно понял — о чем все это. Для этого раздела нужно найти баланс, чтобы не было лишней информации. Можно ориентироваться по объему: если Цели и задачи занимают больше одной страницы, скорее всего стоит поубавить воды. Основные пользовательские сценарии (и исключения/альтернативные сценарии к ним) описанные в простом формате. Название сценария (можно в формате User Story). Предусловия (опционально). Триггер (опционально). Основные шаги выполнения сценария. Можно делать сценарии в формате User Story, без детализации. Но следует помнить правила для описания таких сценариев. Как минимум, сценарии должны быть короткими, и обязательно нужно описывать, как позитивные, так и негативные варианты поведения системы. Предпочтительно делать короткие сценарии, без ветвлений. Если мы имеем дело со сложным составным интерфейсом, то лучше создать отдельные сценарии для фич, чем формировать мега-сценарий. В ситуации, когда мы совсем не понимаем, что может происходить в рамках интерфейса, и времени на аналитику нет, мы можем задавать очень обобщенный сценарий (например, покупка товара в Интернет-магазине), но при этом помнить, что этот сценарий в дальнейшем, уже в процессе проектирования, должен быть декомпозирован на более простые составляющие. В рамках сценария нужно избегать описания интерфейса и конкретных интерфейсных решений, потому что это снижает свободу возможных решений и, скорее всего, усложнит поиск хорошего решения. Если у аналитика есть идея, как может быть реализован тот или иной сценарий в интерфейсе, лучше эту идею изложить в виде комментария к сценарию, чтобы идея воспринималась, как предложение возможного решения, а не как требование к исполнению. Ниже я привел несколько примеров того, какими могут быть сценарии. В конечном счете, формат можно выбрать и другой. Главное, чтобы сценарии функционально покрывали весь проект (или хотя бы нужно стремиться к этому). Совокупность данных, которые нужны для проектирования интерфейса. Можно использовать ссылки на источники таких данных. Например, когда мы переносим контент с существующего проекта, то можно указать ссылки на текущие страницы, с которых будет переноситься контент. Но такая практика хороша, когда данные очевидны, например, когда мы копируем блоки текста с одной версии системы в другую. Попытка же сослаться на форму с динамическими данными и скрытой логикой, скорее всего, приведет к тому, что мы не сможем ее корректно проектировать. Данные чаще всего описываются в табличном формате. Вместе с общим описанием данных полезно прилагать примеры данных, а в некоторых случаях — примеры крайних значений, которые может принимать то или иное поле. Например, если у нас есть поле «Название компании», то важно понимать какой длины оно может быть, «ООО Ромашка» или «Московский ордена Трудового красного знамени инженерно-технический институт тяжелого машиностроения МИТИТМ» потребуют разных интерфейсных решений. Примеры 4, 5 и 6 даны, с одной стороны — как возможные форматы таблицы данных, с другой стороны — как пример того, что формат описания может быть различным. Можно включить в документ дополнительные материалы, которые помогут спроектировать интерфейсы. Чаще всего это материалы, связанные с фиксированными данными и контентом. Например, можно включать справочники, которые нам нужны для формирования форм, чтобы в интерфейсе показывать реальные данные, когда пользователь выбирает значение в выпадающем списке. В зависимости от длины такого списка удобными будут различные интерфейсные решения. Справочники выносятся в отдельный раздел, чтобы не увеличивать раздел с описанием предметной области. Можно не включать в документ сам справочник, а давать ссылку на него. Задание на проектирование подготавливается, чтобы повысить качество работы над проектом на стадии проектирования. За счет более глубокого погружения в технические аспекты реализации, появляется возможность сразу, на стадии проектирования, учесть редкие пользовательские кейсы, которые стали бы очевидны и без задания на проектирования на более поздних стадиях. При этом, за счет ограниченного объема и фокусировки, только на аспектах касающихся интерфейсов, удается сократить время, требуемое для подготовки Задания на проектирование, если сравнивать со временем, требуемым на подготовку полноценного Технического задания.  Head of UX