UX снижения тарифа: сроки, лимиты и существующие проекты

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

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

Определите правила перехода до проектирования экрана

В инструкции GitHub по переходу на более низкий тариф (на английском) пользователям личных аккаунтов и организаций предлагают проверить, какие возможности они потеряют в следующую дату оплаты. Там названы и конкретные последствия: например, при переходе с Pro на Free становятся недоступны расширенные инструменты ревью кода в закрытых репозиториях. Полезный урок для дизайнера — быть конкретным: объяснять, какую работу затронет изменение, а не только называть новый тариф. Правила GitHub в отношении ресурсов не служат готовой политикой для другого продукта.

Для подробного примера представим вымышленное приложение для управления проектами и рабочее пространство Harbor. Дана, администратор, отвечающий за подписку и оплату, 20 октября 2026 года планирует переход со Studio на Core. Изменение вступит в силу на границе следующего расчётного периода: 1 ноября 2026 года, 00:00 UTC. Эти тарифы, даты, ограничения и правила относятся только к учебному примеру.

В Harbor пять активных проектов: «Сайт», «Мобильное приложение», «Клиентский портал», «Центр поддержки» и «Библиотека бренда». В Core лимит в три активных проекта применяется к созданию, копированию и восстановлению проектов. Уже существующие проекты сверх лимита остаются доступными для чтения и редактирования в рамках прежних прав. Сам переход не удаляет и не архивирует их. Архивные проекты не считаются активными; восстановление проекта увеличивает число активных.

Отделяйте управление подпиской от прав на проекты

В этом примере администраторы подписки могут запланировать переход и отменить его до вступления в силу. Сама по себе эта роль не даёт доступа к содержимому проектов или права их архивировать. Так же чётко определите остальные роли:

Покажите Дане общий объём использования, не раскрывая названия закрытых для этого пользователя проектов. В списке могут быть только те названия, которые Дане разрешено видеть. Редактору, столкнувшемуся с лимитом, нужны объяснение и контакт человека с нужными полномочиями, а не доступная кнопка управления оплатой. Более низкий тариф и недостаточные права — разные причины недоступности действия.

Разделяйте подтверждение и момент вступления в силу

В настройках клиентского портала Stripe (документация на английском) переход на более низкий тариф в конце периода включается отдельно; по умолчанию эта настройка предусматривает немедленное изменение. Вариант с концом периода применяется к переходам между ценами одного и того же продукта. Это показывает зависимость срока от конфигурации, а не устанавливает правило, что любое снижение тарифа ждёт продления подписки.

Для Harbor подтверждение должно говорить «Запланировать Core с 1 ноября» и указывать точное время и часовой пояс. Объясните, что до этого момента действует Studio. Не используйте «Снизить тариф сейчас» для будущего изменения и не показывайте Core как текущий тариф сразу после создания расписания.

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

Объясняйте судьбу существующих и новых проектов отдельно

Фраза «Лимит превышен на два проекта» сообщает число, но не последствия. Сводка Harbor должна различать чтение, редактирование, архивацию, создание и восстановление. В этом примере правила намеренно позволяют продолжать работу с существующими проектами; у другого продукта они могут быть иными.

Покажите расчёт явно. После архивации двух из пяти проектов Harbor останутся три активных: лимит заполнен, и новый проект создать всё ещё нельзя. Если архивировать третий, останутся два — тогда пользователь с правом создания сможет добавить один. Не пишите «Архивируйте два проекта, чтобы создать новый», хотя текущее превышение действительно равно двум.

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

Подтверждайте конкретное решение, а не общее предупреждение

На последнем экране соберите название Harbor, переход Studio → Core, момент вступления в силу, текущее использование и конкретные действия, которые будут ограничены. Рядом с кнопкой подтверждения укажите последствие: «Все пять существующих проектов сохраняют прежние права доступа. Для создания и восстановления проектов активных должно быть меньше трёх». Дайте обычную возможность вернуться назад, не теряя контекст проверки.

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

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

Показывайте запланированный переход и возможность его отмены

После планирования страница оплаты должна показывать одновременно «Текущий тариф: Studio» и «Запланировано: Core с 1 ноября 2026 года, 00:00 UTC». Повторите соответствующее последствие для проектов и обеспечьте доступ к той же сводке при следующих посещениях. Временное всплывающее уведомление не заменяет постоянную запись о будущем ограничении.

Harbor позволяет администратору подписки отменить запланированное снижение тарифа до его вступления в силу. Назовите действие «Отменить запланированный переход», а не «Отменить подписку». После успеха покажите, что Studio продолжит действовать и переход больше не запланирован. Если запрос выполняется на границе вступления в силу, проверьте ответ сервера: не обещайте отмену, когда Core уже действует.

До ноября использование может измениться. Если в Harbor станет шесть активных проектов, обновите сводку до шести, не выдавая прежние пять за текущее число. Правило для существующих проектов остаётся тем же, но для освобождения места под новый проект потребуется другой объём действий. Сообщите об изменении затронутым руководителям проектов, не раскрывая суммы оплаты или закрытые сведения о проектах получателям без соответствующих прав.

Объясняйте ограничения там, где с ними сталкиваются

После подтверждённой активации Core показывайте его как текущий тариф. Возле действия создания проекта полезно написать: «5 активных проектов. В Core можно создавать проекты, когда активных меньше 3. Текущие редакторы могут продолжать работу». Оставьте существующие проекты видимыми: замена рабочего пространства экраном с требованием перейти на тариф выше противоречила бы заявленной политике Harbor.

Предлагайте только доступные этому человеку действия. Руководитель может просмотреть свои проекты, которые разрешено архивировать; редактор — обратиться к соответствующему руководителю. Если у человека есть право создавать проекты, но кто-то другой первым занял последнее место, сохраните введённое название проекта и после отказа сервера объясните обновлённое количество. Не создавайте впечатления, что ещё не подтверждённый проект уже существует.

Если изменение оплаты и доступ к функциям ещё согласуются между системами, точно опишите это состояние. Не показывайте «Core активен» только потому, что наступило запланированное время, и не оставляйте метку Studio на неопределённый срок после подтверждения изменения сервером. Согласуйте с разработчиками, какой источник состояния тарифа считается достоверным и как действовать при сбое.

Отделяйте восстановление возможностей от изменения счёта

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

До момента вступления в силу отмена расписания сохраняет Studio. После этого возвращение на Studio — новый переход со своей ценой, сроком и необходимым подтверждением оплаты. Покажите эти условия заранее; возвращайте возможности только после того, как сервис подтвердит право на функции нового тарифа. Не называйте действие «Отменить изменение», если при этом не отменяются последствия для уже выставленных счетов.

Возврат денег, зачёт средств, сохранность данных и восстановление доступа — отдельные вопросы политики продукта. Если продукт предоставляет средства к зачёту, нужно объяснить, что они покрывают и когда применяются. Если восстановление нельзя обещать, не скрывайте это за фразой «Перейдите на тариф выше, чтобы всё вернуть». Одна настройка платёжного провайдера не определяет правила хранения данных рабочего пространства.

Спроектируйте переход Harbor в Pixso

Создайте в файле Pixso три связанных экрана вымышленного приложения: предварительную сводку последствий для Harbor, сведения о запланированном переходе и рабочее пространство с активным Core, где создание новых проектов недоступно. Согласуйте число проектов, дату, роль и формулировки правил. Это экраны подписки, которые проектируются на холсте, а не собственные элементы управления оплатой Pixso.

Попросите коллегу в роли Даны запланировать переход, а затем вернуться к оплате. Может ли он определить текущий тариф, объяснить, что произойдёт 1 ноября, и отменить только ожидающий переход? Во втором проходе используйте роль руководителя проекта после активации Core. Спросите, позволит ли архивация двух проектов создать ещё один. Объяснение участника покажет, передаёт ли интерфейс смысл реального лимита.

Спроектируйте понятный переход на более низкий тариф в Pixso →

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