Корпоративная система планирования

Контекст

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

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

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

С чего начала

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

Основная сложность была в таблицах. Данных было много, между ними существовали связи, а пользователям с разными ролями требовалась разная степень детализации.

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

1. Решение 01Сделать работу с данными удобнее
2. Решение 02Справиться с потоком правок
3. Решение 03Встроить новые разделы

Решение 01

Как сделать работу с данными удобнее

Мы работали с пользователями, привыкшими к табличному представлению данных. Для них были нормой бесконечные столбцы от A до CZ, в которых легко потеряться без контекста (и пары крепких слов).

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

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

У каждого подхода оказались свои плюсы и минусы.

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

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

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

Решение 02

Слишком много правок

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

Поэтому мы начали продумывать систему согласований и статусов с учётом ролей пользователей.

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

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

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

В итоге остановились на отображении изменений непосредственно в контексте данных с возможностью их подтверждения. Дополнительно реализовали историю изменений для более подробного анализа.

Решение 03

Когда система начинает разрастаться

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

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

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

Я пересмотрела структуру новых разделов с учётом потребностей пользователей. Для работы со статусами удалось использовать уже существующие компоненты, изменив только наборы состояний. Это позволило сохранить привычное взаимодействие и не создавать дополнительную работу для фронтенд-⁠разработчиков.

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

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