UX рефакторинг. Сложность простоты
Применяйте простые решения, используя навыки пользователей. Постоянно упрощайте систему сверху донизу. Применяйте UX рефакторинг при каждой итерации.
Давайте рассмотрим вопрос, часто возникающий во многих проектах, интерфейсах и системах: как сделать то, что имеем намного проще и понятнее для большинства пользователей, при этом не теряя наработанного полезного функционала?
English version available here
Если расположить на графике количество людей и их способности (пользовательский опыт, полученные знания или навыки — подставьте что больше нравится), то получится похожее на гауссиану. Нет очень тупых (спасибо всеобщему образованию) и мало гениев (еще раз спасибо всеобщему образованию).
В представлении большинства сложился стереотип, что знания человека, как и функционал систем, растет по экспоненте (то есть, пропорционален предыдущему опыту или наработкам). В теории это так. Но на практике начинают действовать ограничения. После школы и университета появляется работа, семья, поездки на дачу. Время на чтение книг и самообразование уменьшается.
Усложнения интерфейсов и движков, диктуемые бизнесом реализовывать все сложнее из-за уже сделанного функционала. Часто те переменные, которые считались статичными, требуется сделать динамическими. Либо заложенный диапазон значений становится слишком мал (когда продажи превышают оптимистические значения и счетчик заказов переполняется через пару лет после старта проекта). Даже закон Мура перестает работать.
Фактический график, по которому развивается как функционал технических систем, так и способности отдельного индивидуума ближе к сигмоиде.
Простота понимания систем
Построим третий график. Распределение технических систем по простоте понимания пользователями.
Мало простых систем, пользованию которыми не надо учиться. Вспомните, дети сначала учатся пользоваться руками, затем открывают дверные ручки и разбегаются по квартире, потом учатся держать ложку. Став чуть постарше — осваивают велосипед. Так, постепенно, человек познает мир и открывает для себя более сложные системы.
Подростки учатся водить автомобили. Но редко кто умеет пользоваться факсом! Для примера показана доска Монтессори, с которой играют дети 2–3 лет. Это яркий пример простых систем, не требующих специальных способностей пользователя.
А вот сложные системы, интерфейсы управления космическим кораблем или андронный коллайдер — доступны единицам, которые посвятили их освоению годы жизни.
Если соотнести графики простоты систем (рис. 3) и спобностей пользователя (рис. 1), то каждой точке на одном будет соответствовать точка на другом. Причем, пользоваться данной системой нормально смогут только те люди, которые расположены с правой стороны (более способные, чем с левой стороны).
Но, как и во всяком правиле, тут есть исключения. Продукты, которые невероятно сложны по функционалу, но предельно просты в использовании. Ярким примером является продукция Apple или же поисковая строка Google. Как можно этого достичь без миллионных бюджетов?
Простая сложность или сложная простота?
Попытки улучшить систему, применить UX, опросить пользователей, прочувствовать эмпатией, поиграть со шрифтами или сделать кнопочки “поярче” — это попытки сдвинуться на графике понятности систем влево, в сторону понятных продуктов и интерфейсов. Чтобы большее количество пользователей могли работать с сайтом, продуктом или интерфейсом.
В процессе перемещения вы рано или поздно упретесь в одну проблему: невозможность уже ничего улучшить на данном уровне. Вылизали интерфейсы — необходимо менять API. Подправили API — необходимо изменить архитектуру системы. Переделали архитектуру — поняли, что надо осознать корневую причину пользователя и смысл всего созданного. И чем дальше, тем глубже будет эта пропасть и больше усилия, чтобы продвинуться на шаг.
Что тут можно посоветовать?
- Будь проще и люди к тебе потянутся
Сразу старайтесь использовать те навыки, которые есть у всех возможных пользователей. Сводите использование вашей системы к действиям, уже сейчас привычным для всех.
Как писал Джон Маэда “Знания упрощают жизнь” (“Законы простоты”, 4-й закон, стр. 45). Это абсолютно верно. Но что если мы не будем требовать от пользователя наращивать знания для использования нашего интерфейса? Если мы сделаем систему на основе тех навыков, что у него уже имеются?
Рассмотрим для примера замок на магнитной карточке. Она имитирует ключ. Открывание замка ключом сотни лет привычно всем, кто хоть раз запирал дверь. Карточку можно прикладывать, а можно вставлять. Если у вас отель и вы решаете какую партию магнитных замков закупить — каким будет ваш выбор?
Следуя сказанному выше, лучше выбрать те модели, где карточка вставляется, а не прикладывается. Особенно, если ваш отель в регионе и пользователи не привыкли к технологическим новшествам. Модели с прикладываемыми карточками лучше применять там, где аудитория уже имеет навык прикладывать предметы для совершения какого-либо действия: транспортные карточки, бесконтактная оплата PayPass и подобные им технологии.
Еще более наглядно — нанести на карточку изображение ключа. Это поможет, если ориентация карточки в замке имеет значение. Люди будут вставлять “ключ” в замок.
Чем шире аудитория — тем проще ее общие навыки
2. С вершины горы видно самый легкий путь
В процессе улучшений вы неизменно будете спускаться все ниже, в подсистемы продукта или интерфейса. И, что ожидаемо, упретесь либо в технологические ограничения (кстати, возможно с появлением квантовых компьютеров закон Мура снова заработает), либо в стоимостные. Поэтому лучше сразу подняться на уровень логики, учитывая весь тот путь и функционал, который уже наработан. Пересмотрите бизнес-логику, задайтесь вопросом “как можно достичь той же цели, но проще”? Вы же уже знаете предысторию создания текущего интерфейса, вы знаете как им пользуются люди, что осталось лишнего из прошлых версий. Посмотрите свежим взглядом на систему и перепроектируйте её.
“…добравшись до вершины горы и взглянув вниз, вы, возможно, найдете самый легкий путь к ее вершине” (с) Эдвард де Боно, “Использование латерального мышления”
В противном случае будет ситуация, когда предыдущие пивоты, версии системы, смены бизнес-стратегий и добавление уже ненужного функционала дали одноногого Франкенштейна, которого вы хотите заставить танцевать, меняя прически.
Например, вы хотите сделать форму подписки на новости. Классический вариант — реализовать по типовому шаблону и сразу, с первой страницы, требовать у пользователя email. Но ведь если рассматривать комплексно, эффективно будет просить согласия на подписку на том шаге процесса, где клиент ее и так вводит (этап покупки). Там же донести ценность зачем подписываться — какой тематики уведомления будут, как часто, дать почитать пример такого письма и т.д. Покажите признаки этой подписки.
Аналогично с номером телефона пользователя. Можно проектировать формы ввода, а можно спроектировать ситуацию, когда клиент сам позвонит в контакт-центр/ курьеру и определить этот номер автоматически. Например, “чтобы курьер подъехал не в выбранный диапазон времени по указанному адресу, а в рамках одного часа и куда вам будет удобно в течении дня — наберите его и согласуйте фактическое время-место доставки”. Не все же могут по 4 часа сидеть дома в ожидании доставки. Кто-то может отъехать по делам, отойти из офиса на обед или встречу, пойти в спортзал. Цель у пользователя — получить товар так, как ему удобно. А планирование, даже на день вперед, практикуют очень немногие. Используйте это.
Берите те цели пользователей, которые используются при работе с вашей системой и меняйте её. Фундаментальные изменения в логике и более корректная реализация цели автоматически отзовутся на уровни подсистем: архитектуру, железо, программное обеспечение и интерфейсы.
Двигаться надо не от изменений к цели, а от цели к изменениям
Кстати, как следствие всего вышесказанного — роль человека и команды, проектирующих систему, должна быть очень разносторонней. От дизайна до технологии. От программирования, до понимания финпотоков. От закупок составляющих до утилизации. Нарастающая конвергенция специальностей подтверждает это. Инженеры-технологи, fullstack -дизайнеры, менеджеры по продукту и аналитики широкого профиля.
Да, это сильно расходится с итеративными методологиями. Любители Agile и перебора гипотез сейчас начнут возражать. Поэтому, есть третья рекомендация:
3. Каждый раз как в первый раз
Итеративные методологии можно применять, но они не должны быть средством перебора вариантов в процессе достижения улучшений. Иначе вы рискуете начать наращивать ненужный функционал от прошлых итераций. Начнется нелинейный рост усложнения и система сама себя начнет тормозить в развитии.
Поэтому каждое изменение проектируйте от цели. Пересмотрите логику бизнеса, проведите аналитику, отрежьте ненужные части функционала, упростите по максимуму. Старайтесь применять такие решения, которые способствуют достижению нескольких целей одновременно.
Как в описанном выше примере со звонком курьеру — и вы получаете телефон пользователя, и пользователь получает дополнительный сервис в виде гибкости доставки. Классическое же решение с выбором диапазона времени доставки — это ИЛИ. Или один вариант (с 12 до 16 часов), или другой (с 16 до 20 часов).
Гений союза И и злодейство союза ИЛИ
Каждый релиз — это потенциальная нашлепка сверху к системе для реализации конкретного функционала, а не органичное встраивание его в логику. Добавляя все в кучу вы рискуете сделать работу с системой непонятной и нелогичной. Недостатки 1 и 2 типа (цели смазываются меж собой или ни одно из действий не кажется пользователю ведущим к цели) — как следствие несогласованных между собой изменений.
Старайтесь с каждым изменением функционала выстраивать логику работы системы в цепочку. Проверьте, что не породили новых ошибок (нет дефектов). Проверьте, что пользователю однозначно понятно что необходимо для достижения его цели (нет недостатков). Делайте UX рефакторинг вашей системы с каждой итерацией.
Обращайте внимание на то, что есть система у вас в данный момент. UX рефакторинг применим не только к визуальному интерфейсу. Любой набор систем можно выделить как единое целое и изолированно от другой части улучшить.
Чем выше берете уровень надсистемы для рассмотрения (бизнес-логику, например), тем масштабнее можно провести UX рефакторинг, затрагивая этот и низлежащие уровни систем.
В этом случае интерфейсами также становятся, например API (на уровне программных систем) и разъемы (на уровне серверного железа). А пользователями становятся не только внешние клиенты, но и внутренние менеджеры, операторы, администраторы. Даже одни системы могут быть клиентами по отношению к другим и на них также распространяется принцип устранения дефектов и недостатков.
Заключение
Как понять, что вы уже там, в зоне продуктов, понятных всем?
При работе с интерфейсом пользователь не ищет документацию и не спрашивает подсказок.
Все настолько понятно, что разберется любой. Да, может вашим продуктом изначально будут пользоваться только гики и ботаны, а новички в технологиях подключатся в самом конце, но ориентироваться лучше сразу на новичков. Даже вернее будет сказать что, для того чтобы ботан ощутил простоту и логичность использования интерфейса:
Превратите ботана в новичка.
Facebook: facebook.com/lessplusmore
Telegram: t.me/lessplusmore
VKontakte: vk.com/lessplusmore
Twitter: twitter.com/lessplusmore
Отдельное спасибо Wova Roodnyy за идеи, методику и консультации.
