Юзабилити без юзкейзов - как пиво без водки
Юзабилити - одно из ключевых слов современности, неотъемлемая и неизбежная часть работы над любым проектом, который имеет пользовательский интерфейс.
Однако, с моей точки зрения, юзабилити из цели превратилась в самодостаточную сущность, в единственный метод постановки задачи и управления процессом разработки UI. Что, с моей точки зрения, неверно. Приправа, даже такая обязательная как соль, не должна превращаться в блюдо. А юзабилити - всё же, приправа. А если быть ещё более точным - это качественная оценка удачности UI.
Я бы хотел обосновать эту точку зрения с позиции одной любопытной дихотомии, которую я подглядел в выступлении юзабилистов на последней конференции MBLT17.
Дихотомия звучала со сцены так: есть элементы UI (обсуждалось банковское мобильное приложение), которые “танцуют” от счёта клиента (первым элементом навигации идёт счёт или карта, вторым - операции с ним), а есть элементы, которые начинаются действием (перевести деньги) - в этом случае предмет действия выбирается на втором шаге.
Эти два кейза легко обобщить: есть отглагольная навигация, а есть навигация объектная, от существительного. В таком виде дихотомия пригодна для обсуждения не только банковских продуктов, а и вообще любых UI.
Какой из способов верен? Конечно, напрашивается очевидный (и, наверное, в целом довольно правильный) ответ - давайте сделаем обе, и пользователь выберет ту, которая ему удобна.
Но, конечно, опытный UI/UX проектировщик сразу скажет, что это - не решение, а уход от него. Пространство пользовательского интерфейса ограничено и вопрос, таким образом, превращается из “как сделать” в “какой вариант показать на главном экране” - невозможно все варианты навигации сделать равнодоступными, что-то будет ближе, что-то дальше.
Как выбрать? Есть только один верный ответ на вопрос - его величество сценарий. Use case. Модель поведения пользователя. Задача, которая перед ним стоит.
Сколько я вёл на эту тему разговоров с разработчиками интерфейсов (нет, не наших, в DZ/E-Legion, конечно, работают профессионалы высокого уровня), и всё как-то не видно в них стремления залезть в шкуру пользователя. Понять и зафиксировать в проектных документах его мотивацию, целеполагание, подход к решению задачи. “Мы не пишем юз-кейзы, наши юзеры все совсем разные”. C’mon. Really?
На практике, всё довольно банально. Достаточно просто перечислить мотивы, с которыми пользователь достаёт мобильное приложение из кармана. Что он в этот момент хочет? Усилия будут вознаграждены сторицей - подход к проектированию UI станет довольно очевиден.
Давайте попробуем сделать это на примере банковского приложения.
Для начала есть всего три группы сценариев, на которые делятся все кейзы: принести деньги в банк, забрать деньги из банка, получить информацию. Смотрите-ка, уже видна структура.
Попробуем пройти чуть дальше по этой дорожке. Принести деньги в банк. Это - пополнение счёта. Очевидно, мотивация действия - глагольная, но выбор счёта является неизбежным и первым шагом. В то же время, пользователь нуждается в том, чтобы ему подсказали, какие именно счета в каких пополнениях нуждаются. Каков может быть минимальный элемент UI, который поддерживает эту задачу пользователя? Например, такой: “пополнить счета: задолженность 52354 р”. Кстати, заодно решили часть задачи для третьей группы сценариев - получение информации. Вопрос “сколько я должен банку” при нынешнем проникновении кредитных инструментов - один из ключевых.
Вторая группа сценариев - потратить деньги. Спектр услуг банков в этой тематике очень широк и ни при каком раскладе не поместится в домашний экран любого интерфейса. Мало того, навигация по типу платежа широка и многогранна. Однако, и тут есть класификация субсценариев. Платежи бывают рекуррентные (оплата мобильного), частые но нецикличные (оплата парковки), событийные (оплата штрафа) и казуальные (оплатить замену прав или паспорта).
Очевидно, что поведение банковского приложения должно быть разным для разных видов. Рекуррентные и событийные платежи должны “проситься” - вылезать в виде каких-либо проактивных элементов основного экрана приложения. Остальные (да и эти тоже) должны быть организованы в дерево навигации по типам. Но, очевидно, что разные люди часто выполняют не один и тот же набор платежей. Кто-то оплачивает интернет из мобильного приложения, кто-то - нет, кто-то нуждается в парковке ежедневно, а у другого и машины-то никогда не было. Очевидно, что навигация по типам платежа должна быть организована как дерево плюс вынос нескольких наиболее популярных назначений на верхний уровень навигации.
Третий вид сценариев - информационный. Строго говоря, это неправда - у человека не бывает чистой незамутнённой потребности в информации. Ну не бывает нужно человеку просто вот так, ни для чего узнать, где находится отделение банка или каков процент по срочному вкладу. Ему что-то другое нужно, и информация - только шаг на пути к этой цели. Хорошо бы понимать и удовлетворять именно цель. Например, проценты по депозитам людей интересуют, когда им нужно передержать или вложить надолго свои деньги, и хорошая навигация поддержала бы именно этот сценарий, предложив пользователю пункт меню “другие операции -> положить деньги на депозит - -> более чем на год -> с низкой доходностью и без риска”, но, наверное, я уже хочу слишком многого. Хотя, с другой стороны, зачем мне пункт “найти ближайший банкомат”, когда на самом деле мне нужно “прямо сейчас внести наличные на счёт”? Кстати, знаете, в чём разница? В том, что во втором случае приложение, зная реальную задачу пользователя, в состоянии отфильтровать мне выдачу оптимальным путём - исключить банкоматы без возможности внесения наличных, добавить офисы банка, а так же банкоматы и офисы партнёров, которые поддерживают нужную операцию. Опять же, вторичные сценарии и информация должны быть организованы в дерево с выносом частых операций (частых для данного, конечно, пользователя) в топ.
Что получилось. Даже прикинув сценарии на уровне палки и верёвки мы видим, что идеальный UI банковского мобильного приложения выглядит так:
Пополнить баланс (вы должны 52378 р)
Оплатить/перевести деньги (доступно 120567 р)
За интернет Rinet.ru 500р
За телефон МТС 1000р
Штраф ГИБДД 250р
Другие операции
Внести наличные
Информация
Виды пластиковых карт
Депозиты
Инвестиционные инструменты
Отмечу, что выносы подпунктов в основной экран можно делать как в силу частого их употребления пользователем, так и для продвижения услуги банка.
Итого: если вы описали сценарии использования и опираетесь на них, вы делаете то, что нужно клиенту и строите навигацию так, как удобно клиенту. Все остальные методы сродни самоудовлетворению проектировщика: приносят радость ему, а не пользователю.
Неожиданный для меня самого вывод: навигация должна быть отглагольной всегда. Для “мальчика, воспитанного волками объектно-ориентированными программистами” это звучит ересью, но против фактов не попрёшь. Впрочем, скорее, это следствие выбранного примера. Для магазина, напротив, навигация будет объектной. Но это только потому, что операцию с магазином пользователи совершают, в основном, одну. Купить. Эта операция превалирует с подавляющим перевесом, поэтому в интерфейсе она является очевидным умолчанием. Но есть и другие сценарии и соответствующие им операции - например, вернуть товар, найти точку гарантийного обслуживания, адрес ближайшего магазина и время его работы.