Внутренняя соцсеть для развития корпоративной культуры и обмена опытом
Спроектировал внутреннюю соцсеть и сторисы для обмена опытом, видимости знаний и развития корпоративной культуры внутри компании.
О проекте
Почему это было важно
- Автоматизация была одной из самых сложных зон продукта
- Ошибки в настройке влияли не только на удобство, но и на предсказуемость работы системы
- Чтобы разобраться в логике, пользователям приходилось идти в документацию, к более опытным коллегам или в техподдержку
- Чем сложнее становилась система, тем выше была цена непонятных зависимостей и непрозрачных настроек
Проблема
- Слишком много настроек без понятной структуры
- Неочевидные зависимости между параметрами
- Непонятно, почему отдельные настройки не работают
- Smart-логику было сложно понять и отладить: пользователи не понимали, какие параметры и функции доступны, какие типы данных можно использовать и какой результат ожидается в конкретном контексте
- Карта маршрута не показывала реальное поведение процесса
- Пользователи шли в документацию, к старшим коллегам и в техподдержку
- Новым администраторам было сложно входить в систему
Цель
- Снизить количество ошибок при настройке
- Сделать систему более прозрачной для администраторов
- Упростить освоение сложной логики для новых пользователей
Моя роль
- Проводил интервью и созвоны с администраторами
- Анализировал проблемные сценарии и часто используемые настройки
- Участвовал в выработке решений вместе с дизайн-директором
- Проектировал UX/UI ключевых частей новой админки
Ключевая проблема была не в количестве экранов, а в том, что логика системы была разбросана по разным разделам и плохо читалась пользователями.
Исследование
- Выяснил, какие настройки используются чаще всего
- Искал места, где пользователи теряют контекст
- Собирал сценарии, в которых пользователи ошибаются
- Выявлял, какой информации не хватает для настройки и анализа
- Проводил интервью с администраторами, бизнес-аналитиками и смежными участниками процесса
- Использовал бенчмаркинг и юзабилити-тестирование для проверки гипотез решений
Как искал решение
Сначала собрал основные боли по трём направлениям:
- структура настроек
- работа со smart-выражениями
- анализ маршрута
Дальше проверял, какие проблемы можно решить за счёт лучшей структуры, а какие — только за счёт большей прозрачности логики.
Сравнивал варианты группировки настроек и уточнял их вместе с пользователями.
Проверял гипотезы интерфейсных решений через обсуждение, тестирование и итерации с администраторами.
Что я сделал
1. Перестроил структуру настроек
- Разбил параметры на логические блоки
- Вынес связанные группы на отдельные экраны
- Добавил главную страницу категории
- Добавил подсказки почти к каждому полю
- Сделал зависимости между настройками явными
- Добавил скрытие и блокировку конфликтующих опций
2. Сделал smart-логику более прозрачной
- Добавил контекст использования smart-выражений
- Показал, где именно используется выражение
- Показал, какие данные smart принимает и какой результат должен возвращать
- Добавил встроенные подсказки по параметрам и функциям:
- Типы параметров
- Синтаксис функций
- пояснения и примеры использования
- Улучшил вход в сложную логику через поиск по функциям и параметрам с выбором с клавиатуры
- Добавил проверку типов, чтобы пользователь видел, соответствует ли отдаваемый результат ожидаемому формату
- Добавил версионирование, сравнение и восстановление версий для безопасной работы с изменениями
3. Усилил карту маршрута
- Показал, где выполняется smart-логика
- Вывел настройки, влияющие на маршрут
- Добавил больше данных для анализа этапов
- Показал обязательные поля, уведомления, доступы и переходы
- Добавил просмотр от роли
- Сделал маршрут полезным не только как схему, но и как инструмент анализа
Отдельно важно, что решения были направлены не только на удобство интерфейса, но и на повышение прозрачности системы: пользователь должен был понимать, что происходит, а не просто видеть набор настроек.
Масштабируемость
- Поддержал более масштабируемый подход
- Часть экранов и таблиц формировалась автоматически из базы полей
- Это упростило добавление новых опций без участия разработчиков
Что дошло до реализации
- По итогам работы были подготовлены и согласованы новые экраны и сценарии для ключевых зон админки
- Решения прошли через обсуждение с пользователями и были переданы в разработку
- Часть изменений была направлена не на один отдельный экран, а на более системное улучшение логики настройки и анализа
Результат
- Настройка системы стала более понятной и предсказуемой
- Пользователям стало проще находить нужные параметры и понимать их контекст
- Стало проще разбираться в smart-логике, допустимых типах данных и ожидаемом результате
- Анализ маршрутов стал нагляднее
- Снизилась зависимость от документации, коллег и техподдержки
- Новым администраторам стало легче входить в систему
- Работа с изменениями стала безопаснее за счёт версий и сравнения выражений
