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