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

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

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

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

Приходится идти на компромисс — выдавать сообщение об ошибке с расплывчатыми инструкциями:

Клиент вынужден забыть о своих финансовых возможностях и работать на интерфейс: решать в уме арифметическую задачу или перебирать случайные числа в надежде попасть в требуемый диапазон. Хорошенький «калькулятор».

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

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

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

То же противоречие, но в сторону избавления от вреда: использовать в интерфейсе существующие элементы интерфейса, но пользователь не сможет одновременно менять несколько связанных значений. Идеальное решение: клиент пользуется стандартными элементами интерфейса, но значения параметров кредита меняются сами по себе.

Прорывное решение в эту сторону придумано в начале 2000‑х для сайта польских кредитных экспертов pdk.pl (сайт больше не доступен). Параметры кредита представлены ползунками, которые автоматически передвигаются при изменении любого из параметров. Если же клиент пожелает зафиксировать один из них, предусмотрены специальные «замочки»:

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

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

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

Предположим, пользователь зафиксировал «замочком» срок на 4 года, и пытается уменьшить значение суммы кредита до 40 000 ₽. Банк не выдаёт кредиты меньше ста тысяч рублей на четыре года, поэтому ползунок просто останавливается на этом значении:

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

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

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

Хорошее дизайнерское выражение на пути к пользе — «ничего страшного». Ползунок на замке? Ползунок выходит за границы разрешённого диапазона? Ничего страшного, клиент беспрепятственно сдвигает ползунок к нужной ему сумме кредита, при этом интерфейс показывает области текущих ограничений. Там, где клиент запретил ползунку сдвигаться, создаётся копия ползунка — «призрак». Клиент видит, что он получит свои 40 000 ₽, если уменьшит срок до двух лет. Когда клиент банка отпустит мышь, все ползунки вернутся к ближайшим «разрешённым» границам.

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

Продолжение следует.