ТЗ на разработку любого сервиса (особенно массового) должно включать макеты/прототип. На примере кейса с Банком Москвы, которые в 2003 внедрили "коробку", а к юзабилити пришли только в 2015 году, рассказываю о возможностях для проектной команды уже на первом этапе внедрения получить сервис с высокими пользовательскими качествами. В презентации есть примеры пользовательских проблем, а также объясняется практическая ценность каждого этапа создания макета. Если Банк включает в ТЗ макеты, появляется выбор, например, использовать "коробку", но до внедрения тестировать их интерфейс (или передать вендору готовое юзабилити-исследование USABILITYLAB). Качественное решение банк получает уже на этапе внедрения даже "коробки". Эволюция проекта: 1. Низкий приоритет для проекта ДБО и разработка ТЗ (функциональность, безопасность). 2. Выбор "коробки. 3. Боремся за работоспособность внедрения. 4. Боремся с техническими проблемами. 5. Набираем статистику. 6. Приходим к выводу, что "коробка" не соответствует уровню банка (речь про пользовательские качества и дизайн). 7. ТЗ на собственное решение, которое включает макеты, проверенные на пользователях. 8. Внедрение, борьба за работоспособность ("чтоб без технических проблем"). 9. Красота и оценка/улучшение пользовательских качеств внедрения. 10 Продвижение.

1. Эволюция проекта
БАНК МОСКВЫ:
эффективный интернет-банк
Дмитрий Силаев,
коммерческий директор USABILITYLAB
d.silaev@usabilitylab.net
Моб.: +7 (926) 492 05 50
Офис: +7 (495) 933 01 37 #401

2. Немного о коробках
 Главный критерий
выбора «коробочных
версий» – цена и
функционал;
 «коробка» не
заточена на заботу о
пользователе;
 выход из коробки –
важный этап
эволюции банка
2

3. ИБ Банка Москвы:
старая версия
 существовала с 2003 года;
 стандартная «коробочная» версия от iBank;
 оценка 3+ в рейтингах: «Есть необходимые
функции, можно пользоваться, но без
удовольствия»
– информация взята из выступления Елены Фоминой на конференции
iFin

4. Ключевые проблемы*
«недружественный» к пользователю интерфейс:
– отсутствие важной для пользователя информации (сроки следующего
платежа по кредиту, разделение карт на кредитные и дебетовые и т.п.);
– сложная и запутанная навигация;
– отсутствие подсказок;
– неоптимальная компоновка экрана для некоторых платежей.
*на основе экспертной оценки USABILITYLAB, предшествовавшей проекту по созданию нового
интерфейса
4

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

6. Пример проблемы:
сложная навигация
6
Через пункт «Оплата
квартплаты» в разделе
«Коммунальные платежи»
невозможно оплатить ЕПД.
Оплата ЕПД вынесена в
отдельный пункт. Это может
вызвать трудности у неопытных
пользователей: не все знают, что
их квитанция называется «ЕПД».

7. Пример проблемы:
нехватка подсказок
7
Нет пояснений, как правильно
заполнять это поле (оно является
проблемным во многих ИБ)
Откуда брать и как считать НДС?
(и обязательно ли это делать
физическому лицу)

8. Пример проблемы:
компоновка экранов
8
Ссылка «выслать пароль по SMS»
не выглядит кликабельной и
плохо заметна. Это вызовет
затруднения у неопытных
пользователей ИБ.
Кнопка приоритетного действия
«Отправить в банк» не отделена
от других кнопок в пространстве
и не отличается от них по
оформлению. Ее сложно найти.
Пользователь легко может по
ошибке нажать на кнопку
«отмена» или «редактировать».

9. Цель проекта
 Разработать удобный для пользователей
интерфейс нового интернет-банка:
– обеспечить простоту навигации;
– обеспечить простоту выполнения всех задач пользователя;
– обеспечить быстрый доступ к наиболее часто востребованным
функциям интернет-банка;
– сделать его доступным на максимальном количестве устройств
(адаптивный дизайн).
9

10. Ход проекта
10

11. Методология HCD
Определение
контекста
использования
Определение
требований и
ограничений
Разработка проектных
решений,
соответствующих
требованиям
Оценка продукта на
соответствие
заявленным
требованиям
Внедрение
11

12. Методология HCD
Определение
контекста
использования
Определение
требований и
ограничений
Разработка проектных
решений,
соответствующих
требованиям
Оценка продукта на
соответствие
заявленным
требованиям
Внедрение
12
Концептуальное
и детальное
проектирование,
разработка ИА
Юзабилити-
тестирование
Дизайн, передача
разработчикам
Выработка требований
к ИБ: интервью с
заказчиком и
мозговой штурм

13. Персонажи и сценарии
13
Основа для персонажей – совместный мозговой
штурм с представителями банка

14. Особенность 1: персонажи на
основе экспертизы
 Не было полноценного этапа исследования
пользователей
 Минусы:
– персонажи основаны на экспертном опыте сотрудников USABILITYLAB
и представителей банка, поэтому информация об их потребностях и
задачах необъективна;
 Плюсы:
– экономия сроков и бюджета проекта.

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

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

17. Проектирование
17
Главная страница:
концепция
Главная страница:
детальный прототип

18. Особенность 2: десктопная
и мобильная версии
 Для ключевых экранов была спроектирована
полноэкранная и мобильные версии;
 минусы:
– увеличение срока и стоимости проекта
 плюсы:
– обеспечено удобство пользователей, выходящих в мобильный банк со
смартфонов;
18

19. Пример
19
Настольная версия Мобильнаяверсия

20. Особенность 3: тестирование
прототипов
 На основе детальных макетов был создан
кликабельный прототип, который протестировали
17 пользователей
 минусы:
– увеличение сроков и стоимости проекта;
 плюсы:
– возможность внести правки в новый интерфейс до начала разработки.
20

21. Пример правок
21
Вариант до тестирования Итоговый вариант
Представление основной и дополнительной карты стало древовидным
Пункт «Телефон» переименован в «Городской телефон»

22. Итог: дизайн
22
Главная страница: прототип Главная страница: дизайн

23. Примеры решенных
проблем
23

24. Рублевыйперевод:
проблемы
24
Комиссия не указана
Непонятно, как
заполнять НДС
Цифры не разбиваются на
группы, велика
вероятность ошибки
Кнопки «Отмена» и
«Далее» расположены
слишком близко

25. Рублевыйперевод:
решения
25
Подстановка
значений полей из
истории платежей
Маска на поле
уменьшает количество
ошибок при воде
Явно указана
комиссия
Кнопки приоритетного и
второстепенного действия
разнесены в пространстве и
зрительно отличаются
Убран шум, затрудняющий
восприятие страницы:
лишние полоски, серые
блоки и т.п.
Проектировщики разместили
названия полей над полями, а
не слева, как было. Страница
стала не такая загруженная и
читается легче

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

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

28. Выводы
28

29. Коробка или не коробка?
 На самом деле, не важно. Важно: спроектировать
интерфейс системы до начала разработки;
 План А: ТЗ, которое уйдет вендорам или
разработчикам, должно содержать макеты экранов
и требования к пользовательским качествам.
 План Б: включайте этап юзабилити-тестирования.
 План Ц: используйте готовые исследования.
29

30. Результаты внедрения
будут оценивать пользователи
30

31. Критерии успешного внедрения
ИБ
 увеличение числа активных пользователей;
 рост среднего количества операций на
пользователя;
 снижение отказов;
 снижение нагрузки на саппорт;
 высокие пользовательские оценки, полученные
в ходе юзабилити-тестирований, опросов и т.п.
31

32. Специальные гости
Ольга Лебедюк
Начальник отдела продаж через каналы ДБО
Екатерина Ключкина
Менеджер проекта

33. СПАСИБО ЗА ВНИМАНИЕ!
Выслать презентацию? Обсудить подробнее?
Дмитрий Силаев,
коммерческий директор USABILITYLAB
d.silaev@usabilitylab.net
Моб.: +7 (926) 492 05 50
Офис: +7 (495) 933 01 37 #401