Дизайн веб-сервиса сбора инвестиций для физических бизнесов (Web3)

Дизайн платформы для криптоинвестиций в физические бизнесы. Совместно с арт-диреткором и прототипировщиками спроектировал сервис для десктопа и мобильных устройств.

На других платформах

Контекст

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

Основные задачи

Собрать UI-Kit и описать принципы огромного проекта с нуля
Перепроверить логику и обоснованность решений, которые составили UX-редакторы и прототипировщики. Предложить свои улучшения
Отрисовать все макеты на десктоп и мобилку с авто-лейаутами

Инициативы и улучшения

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

Создание пула (заявка на сбор денег)

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

То есть, предполагалось, что пользователь должен самостоятельно продумать через сколько дней, какую долю от суммы задолженности он будет платить. При этом, он ещё должен контролировать прогресс бар суммы задолженности. Накладывается на всё это то, что у платформы есть ограничение: у пула может быть максимум 20 запланированных выплат. Соответсвенно, если человек ошибется, и заполнив 20 платежей прогресс бар не достигнет 100% – он будет должен начать свои расчеты и заполнение с начала.

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

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

1) Через сколько дней после сборов хочется начать выплачивать долги
2) Временной промежуток между каждым платежом
3) Доля от общего долга у каждого платежа

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

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

Пользователям, как минимум, не придется постоянно кликать на Add tranche: система сама определяет, что сумму долга овнер своими платежами ещё не исчерпал, и поэтому каждый раз добавляет новую обязательную строку на заполнение.

Более того, в прототипной версии на овнера накладывались ограничения по выбору даты платежа: выбирая «через 100 дней после закрытия сборов», он уже не мог выбрать «через 90 дней» для следующего платежа (что логично, ведь следующий по порядку платёж не может быть раньше в временных рамках). Данное ограничение тоже удалось снять: теперь все варианты всегда доступны, а если пользователь указал меньшую дату для платежа, по сравнению с предыдущим, он просто автоматически поменяет свое расположение в таблице, заняв реальное порядковое место.

Принцип отображения фильтрации

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

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