В июле 2022 года я взялся за проектирование новой версии сайта по управлению торговыми ботами Ginarea. Так выглядел основной интерфейс до начала работы:

1 этап: сбор функциональных требований

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

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

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

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

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

2 этап: интерактивный прототип в Axure

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

А ниже можно изучить пару скриншотов:

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

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

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

Сначала создаётся навигационное решение, затем прорабатываются основные разделы, затем второстепенные разделы. После этого проектируются низкочастотные состояния разделов (например, пустые списки или сообщения об ошибках) и уже в самом конце можно делать главные страницы и дэшборды — как результат полного понимания работы проекта.

3 этап: создание функциональной спецификации

Функциональная спецификация (ФС) — это документ, который подробно описывает интерактивный прототип. Он преследует сразу несколько целей:

• Позволяет проектировщику перепроверить результат своей работы и детализировать его. Когда я пишу ФС, то вношу в прототип до 30% изменений. Иногда это какие-то улучшения, а иногда я просто обнаруживаю, что что-то упустил. Подробное текстовое описание здорово помогает выявлять места, проработанные не достаточно подробно для того, чтобы можно было отдавать это разработчикам.

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

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

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

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

4 этап: создание дизайна в Фигме

Интерактивный прототип и функциональная спецификация попали в руки к моему коллеге дизайнеру Александру Щипакову — и он приступил к первому этапу: созданию дизайн-концепта. Для этого взяли одну из страниц, с которой посетители будут сталкиваться чаще всего (нет, это не главная страница): список ботов.

Первый концепт, предложенный клиенту, не зашёл. Увидели дизайн и поняли, что темная тема — не вариант, надо делать в светлой.

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

Несколько макетов, чтобы понять формат оформления проекта. Тут есть небольшие расхождения с прототипом. Так бывает, когда клиент видит уже «картинку», а не прототип и описание к нему — хочется что-то решить иначе. Чаще всего это незначительные правки.

Все макеты проекта, чтобы представлять объем проделанной работы:

А вот что на сегодняшний день сделали разработчики клиента на основе получившейся проектной документации:https://ginarea.org.