Контекст и задача
В системе изначально заложили три отдельных раздела: новости, объявления и уведомления. У каждого своя форма создания, свой список и своя логика отображения. Задача пришла от бизнеса без технического задания: нужно было самому понять, как это реализовать, реально ли это вообще и какие будут ограничения.
Работал один. Проектировал сам, потом отдавал системному аналитику, она возвращала с пометками, что проходит, а что нет. По событиям отдельно уточнял детали у фронта.
Задача
Свести три похожих раздела в один механизм так, чтобы автору не приходилось выбирать между тремя формами, а разработке не приходилось поддерживать три модуля.
Результат
Раздел в проде, публикациями пользуются постоянно: через них освещают отключения ресурсов и изменения в работе УК. Вместо трёх разделов одна сущность «Публикация» с матрицей видимости по ролям.
Три раздела оказались одним
Когда начал разбираться, увидел: новости, объявления и уведомления делают одно и то же, публикуют текст с картинкой для определённой аудитории. Отличались только тем, кто это видит: жители одного дома, все жители УК, только сотрудники или комбинация ролей.
Предложил свести их в одну сущность с матрицей видимости по ролям. Автор при создании отмечает, кому публикация видна, вместо выбора между тремя похожими формами.
Что это дало
Упростилось с двух сторон разом. Пользователю не нужно гадать, куда постить, если грань между новостью и объявлением размыта. Разработке не пришлось поддерживать три модуля с дублирующейся логикой.
Бизнес хотел два раздела, я настоял на одной ленте
Бизнес хотел вынести события в отдельный раздел, отдельно от новостей.
Чем аргументировал
Ожидание пользователя должно совпадать с реальностью. Если он заходит в «Новости», он ожидает там новости. Событие по факту тоже публикация, просто с другим поведением.
Работать в одной вкладке логичнее, чем в нескольких. Зачем дублировать функционал, который уже есть. Плюс это лишние трудозатраты для фронта: лучше продолжить существующий раздел, чем строить рядом второй такой же.
Система и так огромная. Новая вкладка её запутает. Есть новости, есть события, а чем одно отличается от другого? Что будет, если я туда попаду?
Чем закончилось
Договорились на одну ленту. Активное отключение теперь видно сразу при входе, а не после перехода в отдельный раздел.
Конкурентный анализ
Смотрел создание публикации в VK: там хорошо собран флоу с вложениями и настройкой даты выхода. И Яндекс Дзен, тоже ради процесса создания.
Задача перепридумать карточку новости не стояла. Главное было расширить функциональность так, чтобы бэк и фронт не страдали при каждом изменении.
Гипотезы
Если события и новости живут в одной ленте, а не в разных разделах, пользователь сразу видит активные отключения.
Если карточка события визуально отличается от новости и телефонограммы, пользователь сразу понимает, на что обратить внимание.
Если активные события закреплять вверху ленты, пользователь всегда видит, что актуально прямо сейчас.
Что подтвердилось после релиза
События открывают и разбирают: смотрят, какие дома отключены и на какой срок. Активное отключение видно сразу при входе в ленту.
Жалоб в поддержку по ленте не поступало. Пользователи читают карточки событий и понимают их без объяснений.
Создание события
Событие — это ремонт или поломка. Автор последовательно указывает, что произошло, какой ресурс затронут (отопление, электроэнергия, водоснабжение или лифт), на какой период отключение и по какому адресу вплоть до конкретных квартир.
Адресность
Дальше публикацию можно показать только жильцам этих квартир, а не всему дому.
Типы публикаций и роли
В ленте три типа: события, обычные новости и телефонограммы. Телефонограмма — публикация только для сотрудников организации.
Пользователи делятся на обычных и суперпользователей. Обычный создаёт публикацию. Суперпользователь дополнительно публикует системные новости с тегами вроде «релиз системы» или «новое обновление» и показывает их всем сотрудникам и жителям.
Две витрины одной публикации
Публикация выходит сразу в двух местах: в разделе «Новости» внутри системы и в личном кабинете жителя.
Какой итог?
Главный урок — научился отстаивать архитектурное решение перед бизнесом до релиза, а не после. Бизнес хотел вынести события в отдельный раздел; я предложил обратное — одну ленту с матрицей видимости — и обосновал это ожиданиями пользователя и трудозатратами фронта.
Решение прижилось: жалоб в поддержку не было, а разработке не пришлось поддерживать три параллельных модуля вместо одного.