Добавили функцию добавления больших файлов в облачное хранилище

Моя роль: Senior Product Designer.

Команда: Product Owner (2), UX Architector (2), UX-Writer (2), Product Designer (2), Backend и Frontend разработчики.

Инструменты: Figma, FigmaJam, Confluence, Jira.

Продукты: Mailion (корпоративная почта), FM (файловый менеджер).

Год: 2022.

1. Краткое содержание

Реализовали функционал загрузки файлов в облако для почтовых клиентов и закрыли один из важных этапов выполнения гранта на развитие продукта.

2. О задаче

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

В этом кейсе мы рассмотрим следующие продукты компании «МойОфис»: «Mailion» — это корпоративная почта, основанная на платформе Cloud Native, и «Частное облако» — это безопасное решение для хранения и управления файлами в вашем собственном облаке с встроенными редакторами документов.

2.1. Проблема

В Mailion установлены ограничения на отправку файлов, превышающих установленную квоту. Это ограничение регулируется через административную панель и относится как к отдельному файлу, так и к общему объёму всех вложений, а также к общей почтовой квоте каждого пользователя. Максимальный размер квоты составляет 50 МБ. Эти ограничения могут затруднить отправку больших файлов, несмотря на то что иногда возникает необходимость в таких передачах. Например, когда нужно отправить установочные файлы программ коллегам. К сожалению, использование общедоступных облачных хранилищ в компании не разрешено, а своё использовать возможности нет.

Было решено реализовать виджет в виде iframe на домене «Частного облака». Это решение значительно упрощает внутреннюю интеграцию между продуктами МойОфис. Кроме того, благодаря API с нашей стороны, внешняя интеграция с различным ПО, используемым нашими бизнес-клиентами, также становится проще.

2.2. Организация процесса и моя роль

Эта задача требовала параллельной работы нескольких продуктовых команд, поэтому кросс-командное взаимодействие стало неотъемлемой частью процесса. Я работал в двух командах одновременно: «WFM (продукт „Частное облако“)», где участвовал в разработке UX для MVP виджета, и в моей основной команде «Mailion», где проектировал интерфейс для облачной загрузки файлов в корпоративную почту с использованием нового виджета.

2.3. Исследования в команде WFM

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

2.3.1. User Story Map

Мы провели интервью с целевой аудиторией, результаты которого оформили в виде фреймворка «User Story Map». В нём мы приоритизировали решения наиболее важных задач для первого релиза:

  1. Передача данных из облака другому пользователю через ссылку.
  2. Передача данных из облака другому пользователю в виде вложений.
  3. Загрузка данных с локального устройства в облако с последующей отправкой через ссылку.
  4. Загрузка в облако вложений, размер которых превышает доступную квоту при добавлении в письмо, с дальнейшей отправкой их в виде ссылок.

2.3.2. Jobs To Be Done

Также на основе интервью мы составили основные джобы:

  1. Когда мне нужно поместить файл или папку в облако, я хочу его загрузить, чтобы дальнейшие операции с ним проводить в облаке.
  2. Когда я загружаю файл или папку в облако, я хочу знать статус загрузки, чтобы быть уверенным, что загрузка выполняется.
  3. Когда я загружаю файл или папку в облако, я хочу знать статус загрузки, чтобы понимать, сколько ещё осталось.
  4. Когда я загружаю файл и возник конфликт, требующий моего участия, я хочу получить нотификацию об этом, чтобы не задерживать загрузку.
  5. Когда я загружаю файл или папку и вышел в офлайн, я хочу, чтобы прогресс загрузки не был потерян и загрузка продолжилась после возвращения в онлайн, чтобы сэкономить время и трафик.

2.4. Проектирование UX виджета

Для удобства коммуникации с командой разработчиков мы составили короткий глоссарий терминов:

  1. Объекты — это файлы и папки, с которыми работают пользователи.
  2. Хостовое приложение — это приложение, вызывающее другое приложение и получающее от него данные. В нашем случае почтовый клиент «Mailion» выступает в роли хостового приложения.
  3. Виджет — это приложение, запускаемое в iframe хостовым приложением для выбора данных для письма и их передачи в хостовое приложение. В данном контексте «Частное облако» является виджетом.

Также совместно с командой WFM и командой разработчиков мы спроектировали архитектуру виджета, которая позволяет пользователю работать с двумя связанными системами — «Частным облаком» и почтовыми клиентами, которые взаимодействуют между собой через встроенные интерфейсы и API-запросы. Front-end «Частного облака» выполняет свои задачи, в то время как почтовый front-end управляет операциями, связанными с почтой, через Mail Back-end.

2.4.1. Сценарии использования виджета

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

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

2.4.2. Сценарий загрузки файлов в облако

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

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

2.4.3. Сценарий загрузки файлов с локального устройства

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

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

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

2.4.4. Сценарий загрузки файлов из облака

Пользователь может прикрепить уже загруженные в облако файлы в виде вложений и ссылок, используя виджет «Частного облака».

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

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

2.4.5. Сценарий просмотра письма с вложениями

Пользователи, просматривая входящее письмо с вложениями, могут:

  1. Визуально ознакомиться с файлами с помощью превью или полноэкранного просмотра.
  2. Скачать файлы на локальное устройство.
  3. Загрузить файлы в облако. При этом файлы в облаке и в переписке будут независимы друг от друга — изменения в облаке не повлияют на файлы в письме. Такое поведение обусловлено отсутствием связи с исходными файлами на локальном компьютере пользователя, так как всё взаимодействие происходит через back-end корпоративной почты.

2.4.6. Итог работы в команде WFM

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

В результате мы спроектировали UX виджета, и далее каждый дизайнер продолжил интеграцию в продукт своей команды.

3. Виджет в Mailion

3.1. Наброски

В команде WFM мы согласовали концепцию в виде модального окна, но при начале работы в Mailion наша команда разработчиков была против такого решения и настаивала на использовании компонента «Медиа-панель»: это элемент интерфейса, который открывается поверх основного интерфейса или в виде отдельной колонки, в зависимости от брейкпоинтов.

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

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

  1. Неконсистентное поведение: если мы ограничим использование медиа-панели только в Mailion, мы нарушим единый пользовательский опыт в сравнении с другими продуктами, где используется модальное окно.
  2. Ограниченная область взаимодействия: блок шириной 320 пикселей недостаточен для удобной работы с файловым менеджером, имеющим древовидную структуру.
  3. Дублирование работы: хотя виджет имеет API, который можно подключить к iframe, нам потребуется создавать множество новых уникальных компонентов для его реализации в медиа-панели. Это неэффективно и приведёт к излишней сложности.
  4. Смешивание сценариев: использование медиа-панели добавляет ещё один контекст к композеру письма. Пользователи сталкиваются с информацией из разных зон интерфейса, чего необходимо избегать. Исследования пользовательского поведения в Mailion подтвердили эту проблему.

Команда согласилась с приведёнными аргументами, и мы решили отказаться от использования медиа-панели. В итоге я вернулся к первоначальной идее реализации в виде модального окна.

3.2. Финальный дизайн

Мои макеты будут использоваться различными специалистами: разработчиками, дизайнерами, владельцами продукта, тестировщиками и UX-писателями. Поэтому я стремился сделать проработку в Figma максимально детальной, с описанием всех сценариев и пояснениями. Такой подход позволит сотрудникам разных ролей эффективнее работать с макетами и улучшит коммуникацию в процессе разработки продукта.

В Mailion была добавлена развёртка на разные сценарии загрузки файла по тапу на иконку вложения, раньше открывался только системный проводник. После выбора пунктов «Загрузить в облако и отправить» или «Из облака» пользователь столкнётся с iframe виджета.

3.3. Дополнительные улучшения

Нам также удалось усовершенствовать функционал drag & drop, сделав его более удобным для пользователей. Ранее интерфейс не отображал визуальных изменений при перетаскивании файла в область почтового клиента. В новой версии мы значительно улучшили этот сценарий. Теперь при перетаскивании файлов пользователь увидит разделение на зоны добавления: в тело письма или во вложения.

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

4. Вывод

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

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

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

Спасибо за просмотр!
Если вам понравился кейс, оцените его.