Я проектировал разделы для закупок, аналитики, управления проектами и ресурсами, а также настройки прав доступа.

Сначала World of Development помогал обучать сотрудников внутри одной команды. Постепенно в продукте появлялись новые задачи: управление проектами, планирование загрузки, закупки, финансовые данные и права доступа. Эти разделы начали зависеть друг от друга, поэтому проектировать их по отдельности уже не получалось.

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

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

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

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

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

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

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

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

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

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

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

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

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