Развитие платформы
Платформа автоматизирует производственные процессы предприятий коммунальной инфраструктуры. В системе сотрудники управляют объектами и ресурсами, работают с большим объемом данных. Помимо десктопной платформы существует мобильное приложение для сотрудников, работающих непосредственно на объектах.
Моя роль:
Я работала над развитием интерфейсов мобильной и десктопной версии продукта.
В этом кейсе — две небольшие задачи, в которых при работе с существующими решениями необходимо было учитывать не только изменения в интерфейсе, но и логику продукта и особенности его дальнейшего развития.
В этом кейсе — две небольшие задачи, в которых при работе с существующими решениями необходимо было учитывать не только изменения в интерфейсе, но и логику продукта и особенности его дальнейшего развития.
Проект под NDA. Название компании, реальные данные и вид интерфейсов изменены.
Задача первая: Модуль карты
По задаче нужно было актуализировать раздел карты и привести мобильную и десктопную версии к единому виду. Часть сценариев уже отличалась между версиями, поэтому требовалось обновить существующие макеты и синхронизировать поведение интерфейса.
- ЗадачаНужно было актуализировать внешний вид карты в мобильной и десктопной версиях и привести их к единому визуалу. Основные изменения были небольшими: унифицировать цвета статусов, скорректировать шрифты, размеры, отступы и положения элементов.
Что обнаружилось в процессе
При работе с макетами я заметила, что одна из сущностей в мобильной и десктопной версиях работает по-разному. Под сущностью в этом кейсе будем понимать инцидент — группу проблем, которая на карте может отображаться с разными адресами и атрибутами.
На карте такой инцидент должен отображаться одной меткой, внутри которой объединены все связанные адреса.
На карте такой инцидент должен отображаться одной меткой, внутри которой объединены все связанные адреса.
В десктопной версии при взаимодействии с меткой пользователь мог увидеть все связанные проблемы
и подробнее изучить каждую.
В мобильной версии каждый адрес отображался по отдельности.
Получалось, что одна и та же сущность по-разному представлялась в двух версиях продукта: в десктопе связь между адресами сохранялась, а в мобильном приложении — терялась.
Почему это было важно
Мобильная версия переставала передавать саму логику инцидента.
Связанные адреса могли восприниматься как отдельные проблемы, хотя в системе они относились к одному инциденту. Была сложность также с тем, что проблемы невозможно было найти на карте, если они находились далеко друг от друга.
Связанные адреса могли восприниматься как отдельные проблемы, хотя в системе они относились к одному инциденту. Была сложность также с тем, что проблемы невозможно было найти на карте, если они находились далеко друг от друга.
Решение проблемы:
Зафиксировала проблему
Объяснила в рабочем чате, чем мобильная реализация отличается от десктопной и почему это может привести к негативному опыту.
Объяснила в рабочем чате, чем мобильная реализация отличается от десктопной и почему это может привести к негативному опыту.
Подготовила вариант решения
Моей задачей было сохранить на мобильном устройстве ту же логику сущности, которая уже использовалась в десктопной версии, но адаптировать её под ограниченный размер экрана.
Моей задачей было сохранить на мобильном устройстве ту же логику сущности, которая уже использовалась в десктопной версии, но адаптировать её под ограниченный размер экрана.
Обсудила решение с командой
На встрече более подробно обозначила проблему и показала вариант доработки функционала
На встрече более подробно обозначила проблему и показала вариант доработки функционала
В предложенном варианте доработки упростилось взаимодействие с картой за счет того, что минимизировалось количество меток на карте, а также функционал составной сущности работал корректно и отображал связанные проблемы ввиде списка.
Итог
Команда согласилась, что функционал нужно привести к единой логике, и предложенный вариант взяли за основу для доработки.
Задача вторая: Фильтры
В платформе много разделов со списками данных. В каждом разделе пользователи могут применять фильтры, сохранять их и использовать повторно.
Фильтр может содержать множество атрибутов разных типов: даты, выбор значений, чекбоксы и тд. Сохранённые фильтры можно редактировать, удалять и применять повторно.
Фильтр может содержать множество атрибутов разных типов: даты, выбор значений, чекбоксы и тд. Сохранённые фильтры можно редактировать, удалять и применять повторно.
- ЗадачаВ одном из разделов такой сценарий уже был реализован. Нужно было распространить его на другие разделы, где тип и количество атрибутов различались.
Что изменилось по ходу задачи
Требования, дизайн и разработка шли параллельно, поэтому часть решений уточнялась уже в процессе работы. В какой-то момент стало понятно, что разрабатывается не отдельный фильтр для каждого раздела, а универсальный компонент, который в дальнейшем можно будет подключать к новым разделам, меняя только состав атрибутов. Это заставило пересмотреть некоторые особенности исходного решения.
Что мешало масштабированию
В исходном фильтре все атрибуты в строчке растягивались на ширину контейнера.
Для нескольких типов полей были сделаны исключения: они имели фиксированную ширину и визуально выглядели компактнее.
Для нескольких типов полей были сделаны исключения: они имели фиксированную ширину и визуально выглядели компактнее.
В конкретном разделе такое решение работало хорошо. Но в универсальном компоненте каждое исключение означало дополнительную логику для разработки.
- —Получалось, что визуальное улучшение одного сценария усложняло настройку компонента для всех разделов.
- —Само улучшение использовалось только в одном разделе, и не было уверенности, что оно понадобится в ближайшем будущем.
Решение
Я предложила убрать специфическое поведение и оставить одинаковую ширину для всех атрибутов. Компонент становился проще и не требовал отдельных правил для редких случаев.
Для проверки технической стороны я описала функционал фильтров и зафикисровала в документации ответы на вопросы:
-
- Как работают сохранённые фильтры?
-
- Какие атрибуты могут использоваться?
-
- Как можно создавать/редактировать/удалять фильтры?
-
- Какие сценарии нужно учитывать?
Часть документации с группировкой атрибутов
Готовую документацию показала разработчику. В обсуждениях мы пришли к тому, что дополнительная логика действительно не оправдывает себя. В итоге от исключений отказались и оставили единое поведение атрибутов.
Итог
Упростили универсальное решение и убрали необходимость поддерживать специфическое поведение ради редкого сценария, что позволило уложиться в согласованный срок.
- Давайте знакомиться!Я ищу работу в продукте и хочу присоединиться к команде, в которой налажены рабочие процессы и внедрены исследования. Если вам нужен дизайнер, который задает вопросы и находит решения, напишите мне.
stacesork@gmail.com
