Безликость и запоминаемость: как создать банковский сайт, соблюдая правила юзабилити и отвечая требованиям ЦБ

Светлана Пушкарь

Руководитель технического отдела группы компаний «Медиасфера»

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

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

На тот момент у нас уже был опыт работы в банковской сфере – мы делали сайт «НС Банк».  

Этот проект нас многому научил. В частности – юристы в банках суровы, суровее них только безопасники, так что многие решения обречены быть неоптимальными, зато безопасными. Сайт в процессе сдачи должен быть верифицирован Яндексом в качестве официального сайта банка. А еще новый сайт должен пройти одобрение Центрального Банка, у которого есть ряд требований к банковским ресурсам, например, обязательная версия для слабовидящих. 

На основе этого опыта мы рассчитывали, что сайт «ПростоБанка» разработать нам будет просто и с минимумом проблем. Так ли это вышло? Отчасти. 

Визуализация 

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

А что тут придумывать – большой слайдер всегда в тему 

Интереснее стало на этапе дизайна – первый поданный вариант был классическим. В качестве референсов нам стандартно был назван ВТБ, Тинькофф, Альфа. Одним словом – золотые сайты рунета в категории «банки». 

Что в них хорошего?  

• Светлые фоны без картинок или узоров. 
• Большие, ровные шрифты без засечек. 
• Ургант.  

По бюджету прошли два первых пункта. Почему они важны?  

Во-первых, это веяния современного западного стиля – меньше элементов на экране, меньше шансов, что посетитель сайта в нем запутается. Чем квадратнее тексты, тем их проще читать, меньше устают глаза и мозг. 

А еще квадратно-гнездовой дизайн позволяет заказчику сайта меньше париться с контентом, можно наштамповать много картинок 400х400 и расставить в нужные места, а не креативить png с прозрачными фонами.  

Руководствуясь этими идеями, мы создали первый вариант дизайна:   

Очень чисто, очень доходчиво, цветом выделены кнопки. Но нет в нем изюма, он не запоминается. 

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

Для обсуждения дизайна на 56-м этаже Москва Сити собрались в переговорной аж 8 человек: два со стороны Медиасферы (руководитель проекта и руководитель отдела разработки сайтов) и шесть со стороны банка – координатор проекта, генеральный директор, заместитель директора, руководитель маркетинга… Одним словом, все заинтересованные в нормальном сайте лица. 

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

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

В процессе мозгового штурма пришло понимание, что ориентироваться, скорее, надо на https://tochka.com/ и https://genplace.ru/, т.к. у них есть стиль. И хочется, чтобы к стилю прилагался смысл. 

Совместные рассуждения позволили выявить следующие концептуальные идеи: 

• Сайт должен показывать клиенту его самого. Если ЦА – это мелкие парикмахерские, сервисы, ремонт обуви и пр., то на картинках должны быть люди, занимающиеся такой работой. 
• Малый бизнес – это стартапы, а стартапы – это особенная, неуловимая атмосфера суеты, эмоционального подъема и постоянного ощущения пушного песца в твоем ближайшем будущем. Один из важных архетипов такой атмосферы – пробковая канбан-доска с записками самому себе в стиле «найти офис» и «погуглить, что же такое эти допуски СРО, которыми мы занимаемся».  
• Возможно, стоит сделать акцент на цвете – ярко-зеленом или синем. В конце концов, яркое запоминается тоже.  

Дизайн был реализован по всем трем идеям.  

Акцент на цвете. Много синего и баннеры с фотографиями 

Акцент на людях. Парень справа понял, как открыть счет 

Акцент на тематике канбан-доски. Заметки, наклейки и кнопки (металлические) 

Стиль ватмана и записок. Вам не видно, но они все со смыслом и нигде не лорем ипсум 

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

Рабочая часть баннера расположилась на «ватмане», там будут акции и новости. А на самой доске будут вывешиваться фото победителей акций, а пока там фотосточные автослесари и сантехники. Потом будут любимые клиенты банка.   

Стиль доски ненавязчиво присутствует на всех страницах – где-то картинки на ватмане, где-то кнопка прямо в поверхность сайта воткнулась.  

Одним словом, задача выполнена. Теперь посетитель сайта сможет уверенно сказать «там везде были пробковые доски». Но отметим, что теперь работать с контентом на сайте стало не так легко, как было в первой подаче. Однако дизайн так понравился, что этому не придали значения. 

Фиксация договоренностей 

Следующим этапом всегда идет составление технического задания, которое описывает работу каждого элемента и привязку его к админке, что в совокупности составляет 60+ страниц, мелким и убористым шрифтом.  

Удобно писать ТЗ, когда дизайн уже готов, оно намного понятнее со скриншотами 

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

Совершенно точно дизайнер в презентации сказал: «Тут у нас будет слайдер», – а не «Рабочая область слева, две строчки – это контент, который нужно будет менять через админку, остальное – картинка, которую вам предстоит готовить и менять самостоятельно, слайд сменяется раз в 3 секунды или по клику на стрелки, менять время между слайдами и способ переключения можно в настройках модуля….» и так далее. Масса нюансов в одном-единственном (и очень банальном) слайдере. 

Забить на описание нюансов и сделать слайдер полностью на свое усмотрение? Хорошо, в 90% элементов сайта вы попадете и претензий не будет. Но в одном или двух начнутся вопросы в стиле «Как это мы не можем менять скорость смены слайдов, мы же хотим. Корм для собак должен держаться на экране вдвое дольше корма для кошек, это же очевидно!». И в этот момент вам предстоит покупать другой модуль, настраивать его заново, согласовывать его отдельно. Уже ради избавления от таких моментов ТЗ лучше написать.  

А можно описать и еще подробнее 

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

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

В нашем случае клиент четко дал понять, что функционал Личного Кабинета – не наша забота, он уже существует, разработан отдельно, нам нужно лишь поставить кнопку со ссылкой. А в процессе согласования ТЗ оказалось, что для доступа в личный кабинет сайт должен собирать почты-заявки, должна собираться конфиденциальная информация клиента, и поступать она должна в Автоматизированную Банковскую Систему. 

Это не стандартный функционал Битрикс, и хотя у клиента уже был готовый код (с предыдущего сайта), в исходном виде он не подходит все равно, поэтому его придется дописывать и встраивать к нам в проект.  

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

Разработка  

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

И вот здесь встают в полный рост всемогущие безопасники из первой части данного текста. Они работают в материнском банке, удобство и сроки разработки их не волнуют, их волнует безопасность.  

Безопасники считают, что на камерах тут сэкономили 

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

Но, пусть и с некоторой задержкой, мы это выдержали. Система работала.  

Финальная проверка и сдача проекта 

Финальная приемка – это именно тот этап, когда в плохих проектах приходит Главный Начальник и заставляет все переделать, потому что мужчина на слайдере недостаточно счастлив. 

А в хороших проектах, где разработчики пишут ТЗ (это последний раз, когда я агитирую писать ТЗ, честно-пречестно) – это этап ловли мелких багов и досадных огрехов.  

QR-код на пиксель вплотную к рамке. А не должен быть! 

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

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

Вот лишь некоторые причины таких огрехов 

Человеческий фактор:  

• Мне показалось выравнивание текста по этому краю логично. 
• В папке с контентом не указано, какая картинка куда, я решил сюда.
• А мне показалось и так норм (это всегда программист, ему всегда норм). 
• Глаз замылился, пропустил запятую, со всеми бывает. 

Нечеловеческий фактор:  

• На вашей версии браузера скрипт не работает, вот все и косо. Кто вообще пользуется эксплорером до сих пор?
• На вашем хостинге какие-то настройки не такие, как у нас на тесте. Будем искать… 
• Мы не смогли проверить сайт на всех версиях телефонов и планшетов. И почему-то именно на шестом айфоне все кувырком. 

А вот еще банальная причина огрехов – версия для слабовидящих, она не отрисовывается с нуля, а просто подключается готовым модулем Битрикс. И надо сказать, не всегда он работает идеально сразу, приходится вносить микроизменения в каждом конкретном проекте, и не всегда достаточно одного человека, чтобы найти все огрехи. 

Как правило такие баги мелкой халатности и непонимания излечиваются очень быстро.  

Мы выработали схему, как проходить приемку эффективно. Мы передаем клиенту гуглодокумент в котором одна строчка соответствует одному багу. Общаемся и оставляем комментарии также в документе.  

Почему не пулять друг в друга вордовскими файлами и аудиозаписями?  

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

Во-вторых, иногда люди непоследовательны, особенно когда их много. Что понравилось директору, то заму может не понравиться и наоборот. А менять по восьмому кругу слово в заголовке на другое – участь тех, кто не хранит логи предыдущих изменений. 

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

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

В этот раз многоступенчатая проверка документа сразу рядом лиц на стороне Банка несколько растянула время сдачи, но в целом проект благополучно запустился и сейчас уже лежит на основном домене Банка. А мы получили задачу скопировать проект и «немного его изменить для другого проекта того же самого банка».  

Но это уже иная история.