Как проектировать понятные таблицы тарифов

Хорошая таблица тарифов позволяет ответить на три вопроса, не открывая калькулятор или ещё одну вкладку браузера: какой тариф подходит для моей работы, сколько я в действительности заплачу и что произойдёт, если я его выберу?

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

В расчётах ниже используется Fieldnote — вымышленный сервис для совместной работы.

Определите выбор, прежде чем рисовать карточки

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

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

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

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

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

Таблица тарифов: сначала отбор, затем сравнение

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

В рекомендациях Figma по страницам цен краткая презентация тарифов отделяется от более полной сравнительной таблицы; единицу тарификации предлагается указывать явно рядом с ценой. Это полезная основа для рассматриваемой здесь структуры. Рекомендации Figma по страницам цен.

Карточка Solo в Fieldnote могла бы описывать самостоятельные проекты, а затем показывать цену, лимит активных проектов и гостевой доступ. Карточка Team — совместные исследования, затем цену, число включённых редакторов и общую ёмкость проектов. Карточка Organization — централизованное администрирование и покупку через отдел продаж. Не нужно придумывать публичную цену для последней карточки, если коммерческая модель предусматривает индивидуальное предложение.

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

Изучите страницу цен GitHub в два этапа

Страница цен GitHub — полезный реальный пример различия между кратким описанием тарифов и подробным сравнением. Блок тарифов обозначает доступные варианты и пути покупки, а расположенное ниже сравнение функций раскрывает другой уровень подробностей. Цены на снимках иллюстрируют устройство страницы; актуальные условия проверяйте на действующей странице.

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

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

Рассчитайте счёт, который в действительности выбирает читатель

Для отдельного примера с оплатой за место представим вымышленный сервис SeatMeter. Его тариф указан как 12 $ за редактора в месяц при ежегодной оплате и минимуме в пять редакторов. Команда из трёх человек не обязательно будет платить по 36 $ каждый месяц. При таких условиях минимальное годовое обязательство составляет 12 $ × 5 × 12 = 720 $.

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

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

Та же точность нужна при описании включённого объёма. «Пять редакторов включено» и «минимум пять оплачиваемых редакторов» могут давать один и тот же первоначальный состав команды, но описывать разные коммерческие правила. Запишите действительное правило в справочном листе, затем сохраните его смысл в карточке, матрице и при переходе к оплате.

Цена за рабочее пространство рассчитывается иначе

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

Допустим, Fieldnote Team стоит 30 $ за рабочее пространство в месяц при помесячной оплате. Отдельное годовое предложение с оплатой за пространство стоит 288 $ за пространство в год, то есть эквивалентно 24 $ в месяц. На понятной годовой карточке месячный эквивалент может быть основной цифрой, но сразу за ним должно следовать объяснение: 288 $ списываются ежегодно. Посетитель не должен догадываться, доступны ли ему двенадцать платежей по 24 $.

Разница между оплатой за пространство и за место требует такого же внимания. Надпись «24 $ в месяц» неполна, если команда из шести человек на самом деле заплатит в шесть раз больше. Покажите, включает ли цена фиксированное число редакторов, применяется ли к каждому редактору или предполагает минимальное количество. Допущение о количестве должно находиться рядом с ценой, а не в далёкой всплывающей подсказке.

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

Не смешивайте несколько единиц в одной строке сравнения. Значения «10» и «Без ограничений» неоднозначны, если строка не объясняет, что считается и за какой период. «Активные проекты» отличаются от «Проектов, созданных за месяц». Это различие может изменить решение о покупке даже при внешне одинаковых числах.

Считайте переключение оплаты изменением условий

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

В примере Fieldnote двенадцать месяцев помесячной оплаты стоят 360 $, а годовая оплата — 288 $. Разница составляет 72 $, или двадцать процентов от суммы помесячных платежей. Если дизайн показывает эту экономию, её основа должна оставаться понятной. Сравнение сниженной годовой цены с какой-либо другой акционной ставкой означало бы уже другое.

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

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

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

Создавайте строки, позволяющие честно сравнивать

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

Во всей строке используйте одинаковую единицу и одинаковую точность. Если в столбце Solo написано «Три активных проекта», не пишите в Team «Достаточно места для роста». Вторая формулировка уклоняется от сравнения, ради которого существует таблица. Рекламный текст размещайте в окружающем объяснении, а фактический лимит — в ячейке.

Отличайте отсутствие от неопределённости. Тире может означать «недоступно», «неприменимо», «не раскрывается» или ноль. Когда разница важна, выбирайте явные слова. Если используете компактный символ, задайте ему понятное значение и убедитесь, что оно доступно также вспомогательным технологиям. Покупатель не должен гадать, означает ли пустая ячейка ограничение или ошибку публикации.

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

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

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

Объясняйте основание рекомендации

Выделенный тариф должен объяснять, кому он подходит. «Для команд, совместно ведущих исследования в нескольких проектах» даёт причину рассмотреть Fieldnote Team. «Лучшее предложение» просит принять оценку, не раскрывая её основания. «Самый популярный» — фактическое утверждение, которому нужны доказательства; оно не должно становиться декоративной заменой рекомендации.

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

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

На узком экране сохраняйте возможность сравнения

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

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

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

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

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

Согласуйте действие со следующим шагом

Кнопка должна описывать ближайшее действие, которое посетитель действительно может выполнить. Начало пробного периода, создание бесплатного рабочего пространства, выбор платной подписки и обращение в отдел продаж — разные шаги. Одинаковое «Начать» на всех кнопках создаёт ровный ряд, но оставляет взаимодействие неопределённым.

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

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

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

Карточки GitHub на снимках делают это различие наглядным. Team предлагает «Continue with Team», а Enterprise — и пробный период, и обращение в отдел продаж. Вторая карточка показывает два пути к одному тарифу, а не две разные его функции. Во время проверки пройдите каждый путь и выясните, какие сведения посетитель должен предоставить дальше. Единый цвет кнопок может сохранять визуальный ритм страницы, а конкретные подписи — точно обозначать следующий шаг.

Проверяйте черновик задачами выбора

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

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

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

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

В OpenDesign HTML-предпросмотр помогает провести такую визуальную проверку. Комментариями можно отметить вводящий в заблуждение блок цены или строку сравнения, в которой нарушилось выравнивание, а точечными правками текста или стилей — улучшить подачу. Передайте утверждённые условия тарифов в контекст дизайна. Расчёты оплаты, право аккаунта на выбранные условия и поведение оформления покупки проверяйте в реализованном сценарии.

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