UX и дизайн

Представьте себе ситуацию: вы заходите в интернет-магазин, чтобы купить подарок другу на день рождения. Сайт загружается быстро, каталог выглядит привлекательно, цены адекватные. Вы находите идеальный товар, добавляете его в корзину и приступаете к оформлению заказа. И тут начинается кошмар. Форма регистрации требует заполнить пятнадцать полей, включая ваше отчество, дату рождения и индекс, хотя вы собираетесь забрать заказ самостоятельно. При попытке ввести номер телефона система отвергает его без объяснения причин. Кнопка подтверждения заказа почему-то находится не там, где вы её ожидаете, и вы случайно нажимаете на что-то другое. Страница перезагружается, и все введённые данные исчезают.

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

Что такое пользовательский опыт

Когда мы говорим о пользовательском опыте, мы имеем в виду нечто гораздо большее, чем внешний вид приложения или сайта. Пользовательский опыт — это совокупность всех впечатлений человека от взаимодействия с продуктом, начиная с первого знакомства и заканчивая регулярным повседневным использованием. Это весь путь, который проходит человек: от момента, когда у него возникает потребность, до момента, когда эта потребность удовлетворена. И даже дальше — до того, как он рекомендует продукт друзьям или, напротив, предостерегает их от использования.

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

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

Эти два измерения могут существовать независимо друг от друга. Продукт может быть визуально великолепным — с модными цветами, стильной типографикой, эффектными анимациями — и при этом совершенно неудобным в использовании. Пользователь любуется дизайном первые тридцать секунд, а потом начинает мучиться, пытаясь найти нужную функцию. И наоборот: продукт может быть визуально простым, почти аскетичным, но работать настолько логично и предсказуемо, что пользователь справляется с любой задачей без малейшего затруднения. Google в свои первые годы был именно таким: минималистичная страница с полем поиска, которая работала идеально.

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

Информационная архитектура

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

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

Рассмотрим простой пример: интернет-магазин одежды. Как организовать каталог? Один пользователь думает категориями типов одежды: платья, брюки, рубашки, куртки. Он ищет конкретный предмет гардероба и хочет увидеть все варианты этого предмета. Другой пользователь думает категориями назначения: одежда для работы, для спорта, для дома, для особых случаев. Он знает, куда пойдёт в этой одежде, но ещё не решил, что именно наденет. Третий пользователь думает категориями стиля: классический, повседневный, вечерний, спортивный. Он ищет определённый образ, а не конкретную вещь. Все три способа организации имеют право на существование, и выбор зависит от того, как думает основная часть целевой аудитории. Иногда правильный ответ — предоставить несколько путей к одному и тому же товару, чтобы каждый пользователь мог выбрать привычный для себя маршрут.

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

Навигация в продукте — это производная от информационной архитектуры. Меню, ссылки, хлебные крошки, поиск — всё это инструменты, которые помогают пользователю понять, где он находится и как попасть туда, куда нужно. Хорошая навигация предсказуема: человек может догадаться, что скрывается за каждым пунктом меню, ещё до того, как нажмёт на него. Названия разделов должны быть понятными и однозначными. «Услуги» — это слишком общо; «Ремонт техники» или «Консультации» — гораздо конкретнее. Пользователь не должен гадать, что его ждёт за каждой ссылкой.

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

Принципы проектирования интерфейсов

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

Первый принцип касается видимости состояния системы. Пользователь должен в каждый момент времени понимать, что происходит. Если система обрабатывает запрос, она должна показать индикатор загрузки, чтобы человек знал: его действие принято, нужно подождать. Если операция завершена успешно, должно появиться подтверждение. Если произошла ошибка, об этом необходимо сообщить. Молчащая система порождает тревогу и неопределённость. Пользователь не понимает: сработало или нет? Нужно ли повторить действие? Произошла ли оплата? Каждый из нас сталкивался с ситуацией, когда после нажатия кнопки ничего не происходило, и непонятно было, ждать или нажать ещё раз. Хороший интерфейс не допускает такой неопределённости.

Второй принцип говорит о соответствии между системой и реальным миром. Продукт должен говорить на языке пользователя, а не на языке разработчиков или инженеров. Это касается и терминологии, и метафор, и визуальных образов. Вместо технического жаргона следует использовать знакомые слова и понятия. Вместо абстрактных идентификаторов — человеческие названия. Многие успешные интерфейсные решения основаны на метафорах из физического мира: корзина для покупок, папки для документов, лупа для поиска, шестерёнка для настроек. Эти метафоры работают, потому что они опираются на существующий опыт пользователя. Человеку не нужно учить новые концепции — он переносит понимание из знакомого контекста.

Третий принцип связан со свободой и контролем пользователя. Люди совершают ошибки, меняют решения, экспериментируют. Интерфейс должен поддерживать это поведение, а не наказывать за него. Должна существовать возможность отменить действие, вернуться на предыдущий шаг, выйти из нежелательного состояния. Кнопка отмены, функция возврата назад, запрос подтверждения перед необратимыми действиями — всё это проявления данного принципа. Когда пользователь чувствует, что контролирует ситуацию, он использует продукт смелее и получает от этого больше пользы. Когда каждое действие кажется необратимым и рискованным, человек замирает в нерешительности.

Четвёртый принцип требует единообразия и соблюдения стандартов. Одинаковые вещи должны выглядеть и работать одинаково на протяжении всего продукта. Если кнопка подтверждения на одном экране синяя и расположена справа, она должна быть такой же на всех остальных экранах. Если свайп влево означает удаление в одном месте, он должен означать удаление везде. Если дата отображается в формате день-месяц-год в одном разделе, она не должна внезапно превращаться в месяц-день-год в другом. Непоследовательность заставляет пользователя каждый раз заново разбираться в интерфейсе, подрывает уверенность и порождает ошибки. Единообразие распространяется и на внешние стандарты: если на большинстве сайтов логотип в левом верхнем углу ведёт на главную страницу, ваш сайт не должен быть исключением без веской причины.

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

Шестой принцип предписывает отдавать предпочтение распознаванию перед припоминанием. Человеческая память несовершенна, и хороший интерфейс не должен её перегружать. Не заставляйте пользователя помнить информацию с одного экрана для использования на другом. Показывайте подсказки, варианты, историю предыдущих действий. Автозаполнение, список недавних запросов, контекстная помощь, предварительный просмотр — всё это способы снизить нагрузку на память. Когда пользователь видит нужный вариант в списке, ему не приходится вспоминать точную формулировку.

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

Восьмой принцип говорит об эстетике и минимализме. Каждый элемент на экране конкурирует за внимание пользователя. Каждый лишний элемент — это шум, который отвлекает от главного. Показывайте только то, что нужно для выполнения текущей задачи. Убирайте или скрывайте второстепенное. Не пытайтесь впечатлить пользователя количеством функций, выведенных на один экран. Пустое пространство — это не потеря драгоценных пикселей, а способ выделить важное на фоне неважного. Минимализм в данном контексте не означает скудость функциональности. Он означает умение показать нужное в нужный момент, а остальное оставить за кадром.

Девятый принцип касается помощи в распознавании и исправлении ошибок. Когда ошибка всё-таки произошла, сообщение о ней должно быть понятным и полезным. Не технический код и не стек вызовов, а человеческий язык. Сообщение должно объяснять, что именно пошло не так, и подсказывать, как это исправить. «Введён неверный пароль. Проверьте раскладку клавиатуры или воспользуйтесь восстановлением пароля» — это полезное сообщение. «Ошибка аутентификации» — бесполезное. Хорошее сообщение об ошибке никогда не обвиняет пользователя, оно предлагает помощь.

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

Проектирование форм и ввода данных

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

Первое и главное правило проектирования форм звучит просто: запрашивать только то, что действительно необходимо. Каждое дополнительное поле — это барьер между пользователем и его целью. Каждый лишний вопрос увеличивает вероятность отказа. Прежде чем добавить поле в форму, задайте себе вопрос: зачем нам эта информация? Что мы будем с ней делать? Можем ли мы обойтись без неё? Нужен ли номер телефона, если у вас уже есть электронная почта для связи? Нужен ли индекс отдельным полем, если современные системы определяют его автоматически по адресу? Нужно ли отчество, если вы никогда не будете обращаться к клиенту по имени-отчеству? Каждое поле должно быть обосновано реальной бизнес-потребностью.

Метки полей — те надписи, которые объясняют, что нужно вводить — должны быть понятными и располагаться там, где пользователь ожидает их увидеть. Многолетние исследования показали, что наиболее эффективное расположение метки — над полем ввода. Такая компоновка обеспечивает быстрое сканирование формы и минимальное движение глаз между меткой и полем. Метка слева от поля тоже работает, но требует больше горизонтального пространства. Опасная практика — размещать подсказку внутри самого поля, в качестве плейсхолдера. Такая подсказка исчезает, как только пользователь начинает вводить текст, и он может забыть, что именно требовалось. Это особенно критично для длинных форм, где человек может прерваться и вернуться к заполнению позже.

Валидация — проверка правильности введённых данных — должна быть своевременной и конкретной. Худший вариант: пользователь заполняет всю форму, нажимает кнопку отправки, и только тогда узнаёт, что три поля заполнены неправильно. Ему приходится искать эти поля, вспоминать, что он там ввёл, разбираться в причинах ошибки. Гораздо лучше показывать проблему сразу, как только человек закончил работу с конкретным полем и перешёл к следующему. Но и здесь важен баланс: не стоит ругать пользователя, пока он ещё не закончил ввод. Показывать ошибку «неверный формат email», когда человек набрал только три буквы своего адреса — это раздражает, а не помогает. Сообщение об ошибке должно быть конкретным и конструктивным. Не просто «неверный формат», а «номер телефона должен содержать 10 цифр» или «пароль должен включать хотя бы одну заглавную букву».

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

Умные значения по умолчанию могут существенно сэкономить время пользователя. Если статистика показывает, что девяносто процентов клиентов выбирают доставку курьером, а не самовывоз, сделайте доставку выбранной по умолчанию. Если большинство пользователей вашего сервиса из России, предзаполните поле страны. Если пользователь уже вводил свой адрес при предыдущем заказе, предложите использовать его снова. Каждое поле, которое не нужно заполнять вручную — это маленькая победа над трением.

Отдельную сложность представляет ввод данных на мобильных устройствах. Виртуальная клавиатура меньше физической, пальцы менее точны, чем курсор мыши, автокоррекция иногда мешает больше, чем помогает. Продуманная форма учитывает эти особенности. Тип клавиатуры должен соответствовать типу данных: для номера телефона — цифровая клавиатура, для email — клавиатура с легкодоступным символом @, для URL — клавиатура с кнопками .com и /. Поля ввода должны быть достаточно большими, чтобы легко попасть пальцем. Автокоррекция должна быть отключена для полей, где она вредит: имена собственные, технические термины, пароли.

Каркасы и прототипы

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

Каркас, который в профессиональной среде часто называют вайрфреймом, представляет собой схематичное изображение экрана. Это не красивая картинка, а скорее чертёж или план. Прямоугольники обозначают места для изображений, линии разной длины символизируют текст, простые контуры показывают кнопки и поля ввода. Цвета минимальны или отсутствуют вовсе: чёрный, белый, оттенки серого. Каркас отвечает на вопрос «что где находится», оставляя вопрос «как это выглядит» на потом.

Ценность каркасов заключается в их простоте и скорости создания. Когда нет необходимости подбирать идеальный оттенок кнопки или искать подходящую фотографию, можно за час создать десяток вариантов одного и того же экрана. Это позволяет исследовать альтернативы, сравнивать подходы, экспериментировать с размещением элементов. Если вариант оказался неудачным — не жалко выбросить, потому что в него не вложено много труда. Изменить каркас несравнимо проще, чем переделывать готовый дизайн, над которым дизайнер работал три дня.

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

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

Главная ценность прототипов — возможность проверить дизайнерские решения с реальными пользователями до того, как начнётся дорогостоящая разработка. Можно дать человеку прототип и попросить выполнить типичную задачу: найти товар, оформить заказ, изменить настройки. Наблюдая за тем, как он взаимодействует с прототипом, можно увидеть проблемы, которые невозможно обнаружить, просто глядя на статичные картинки. Где пользователь запнулся? Что не понял? Какой путь выбрал? Эта информация бесценна для улучшения продукта, и получить её на этапе прототипирования в сотни раз дешевле, чем после запуска готовой системы.

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

Тестирование с пользователями

Даже самый опытный проектировщик с многолетним стажем и десятками успешных проектов за плечами может ошибаться. То, что кажется совершенно логичным создателю, который провёл с продуктом сотни часов, может оказаться совершенно непонятным пользователю, который видит интерфейс впервые. Мы слишком хорошо знаем свой продукт, чтобы объективно оценить его понятность. Это называется проклятием знания: невозможно забыть то, что уже знаешь, и посмотреть на вещи глазами незнающего. Единственный надёжный способ узнать, насколько продукт понятен и удобен — протестировать его с реальными людьми.

Юзабилити-тестирование — это метод, при котором представители целевой аудитории выполняют задания с продуктом или прототипом, а исследователь наблюдает за процессом. Наблюдатель не объясняет, не подсказывает, не оценивает. Он только смотрит и фиксирует: что делает участник, где останавливается, что говорит, какие эмоции проявляет. Соблазн помочь человеку, который очевидно застрял, очень велик. Но именно в такие моменты собирается самая ценная информация. Если участник не может найти кнопку регистрации — значит, кнопка плохо видна. Если он неправильно понимает пункт меню — значит, название выбрано неудачно.

Задания для тестирования должны быть реалистичными, отражающими реальные сценарии использования. Не «нажмите на кнопку в правом верхнем углу экрана», а «найдите информацию о стоимости и сроках доставки». Не «заполните форму регистрации», а «создайте учётную запись, чтобы начать пользоваться сервисом». Реалистичное задание позволяет пользователю самому выбрать путь к цели, и именно этот выбор интересует исследователя. Как человек ищет нужную информацию? Какие разделы проверяет первыми? Какие игнорирует? Эти паттерны поведения показывают, соответствует ли структура продукта ожиданиям аудитории.

Существует техника, которая позволяет заглянуть в мыслительный процесс участника: метод мышления вслух. Исследователь просит человека комментировать свои действия, проговаривать ход мыслей: «Сейчас я ищу раздел с ценами... Наверное, это где-то в меню... Вижу "О компании", "Услуги", "Контакты"... Может, в услугах? Нет, здесь про виды услуг... Попробую поискать в подвале страницы...» Такой поток сознания даёт доступ к информации, которая иначе осталась бы скрытой. Мы видим не только результат — нашёл или не нашёл — но и весь путь рассуждений.

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

Результаты юзабилити-тестирования — это не статистика, а качественные наблюдения. Мы не пытаемся доказать что-то со статистической значимостью. Если три человека из пяти не смогли найти кнопку регистрации — это проблема, требующая внимания, даже если выборка нерепрезентативна в строго научном смысле. Мы ищем паттерны, повторяющиеся трудности, систематические непонимания. И когда находим — исправляем.

Важное преимущество раннего тестирования: его можно проводить на любом этапе, начиная с бумажных набросков. Не обязательно ждать работающего продукта. Можно тестировать интерактивные прототипы. Можно даже тестировать бумажные каркасы, перекладывая листочки перед участником в ответ на его «нажатия». Чем раньше обнаружена проблема, тем дешевле её исправить. Изменить бумажный набросок — дело минуты. Изменить готовый код — дело дней или недель.

Мобильный опыт

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

Ограниченность пространства — первое и самое очевидное отличие. На экране шириной в несколько сантиметров невозможно разместить столько же информации, сколько на двадцатитрёхдюймовом мониторе. Попытка уместить всё приводит к катастрофе: крошечные кнопки, нечитаемый текст, невозможность что-либо разобрать. Проектирование для мобильных устройств требует жёсткого выбора: что показать, а что скрыть. Главное должно быть на виду, второстепенное — доступно, но не мешать. Вертикальная прокрутка — основной способ организации контента. Пользователи привыкли листать ленту и готовы скроллить вниз, если содержание их захватывает.

Взаимодействие с мобильным интерфейсом происходит пальцами, а не курсором мыши, и это меняет всё. Курсор мыши имеет точность в один пиксель; палец на экране смартфона — это примерно квадратный сантиметр погрешности. Элементы интерфейса должны быть достаточно большими, чтобы попасть по ним с первого раза. Минимальный рекомендуемый размер интерактивного элемента — около сорока четырёх пикселей, что соответствует примерно сантиметру на сантиметр. Расстояние между элементами должно быть достаточным, чтобы исключить случайные нажатия на соседний элемент. Нет ничего более раздражающего, чем пытаться нажать одну кнопку и постоянно попадать на другую.

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

Контекст использования мобильных приложений принципиально отличается от настольных. За компьютером человек обычно сидит в относительно спокойной обстановке, располагает временем и вниманием. Смартфоном пользуются на ходу, в очереди, в транспорте, в перерывах между другими делами. Внимание частичное, время ограничено, окружение отвлекает. Это диктует определённые требования: простота, скорость, возможность прервать действие и продолжить позже. Форма, которую нельзя сохранить незаполненной, на мобильном устройстве — преступление против пользователя.

Сеть на мобильных устройствах может быть медленной или нестабильной. В подземном переходе, в лифте, в движущемся автомобиле связь может теряться на секунды или минуты. Хорошо спроектированный мобильный продукт учитывает эту реальность. Он показывает хотя бы часть контента, пока остальное загружается. Он сохраняет введённые данные локально, чтобы они не пропали при обрыве связи. Он корректно обрабатывает ошибки сети и позволяет повторить запрос, когда соединение восстановится.

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

Доступность

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

Распространено заблуждение, что доступность — это исключительно этический вопрос, дань политкорректности, благотворительность в адрес меньшинства. В действительности это ещё и прагматичное бизнес-решение. По различным оценкам, люди с теми или иными ограничениями составляют от пятнадцати до двадцати процентов населения. Это огромный рынок, который недоступный продукт просто теряет. Но есть и ещё один аспект: доступный дизайн часто оказывается удобнее для всех пользователей. Высокий контраст между текстом и фоном помогает не только слабовидящим, но и любому человеку, который пытается прочитать что-то на экране при ярком солнечном свете. Субтитры в видео нужны не только глухим, но и тем, кто смотрит ролик в общественном месте без наушников. Простой и ясный язык понятнее не только людям с когнитивными особенностями, но и вообще всем.

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

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

При проектировании любого элемента интерфейса полезно задавать себе несколько простых вопросов. Сможет ли этим воспользоваться человек, который не видит экран и использует программу чтения с экрана? Сможет ли человек, который не может пользоваться мышью, выполнить это действие с клавиатуры? Поймёт ли смысл этого видео человек, который слышит звук, но не видит картинку? А человек, который видит картинку, но не слышит звук? Эти вопросы выявляют проблемы доступности, которые очень легко упустить, если сам не сталкиваешься с подобными ограничениями.

Работа с дизайнером

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

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

Обратная связь на представленные варианты должна быть конкретной и обоснованной. «Мне не нравится» — это не обратная связь, это тупик. Дизайнер не знает, что именно не так, и не может двигаться в конструктивном направлении. «Целевая аудитория нашего продукта — консервативные корпоративные клиенты из финансового сектора, а этот стиль выглядит слишком игривым и несерьёзным» — это полезная обратная связь. Дизайнер понимает контекст, понимает ограничение, может искать решение в нужном направлении. Конкретика помогает: вместо «как-то пусто» скажите «мне кажется, что главное предложение теряется на странице и пользователь может его не заметить».

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

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

Резюме главы

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

Информационная архитектура задаёт структуру продукта и должна отражать ментальную модель целевой аудитории — то, как пользователи естественным образом организуют информацию в своей голове. Когда структура совпадает с ожиданиями, навигация становится интуитивной; когда расходится — каждый визит требует переобучения.

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

Формы заслуживают особого внимания как основной источник трения в цифровых продуктах. Минимум обязательных полей, понятные метки, своевременная и конкретная валидация, разбивка длинных форм на шаги, умные значения по умолчанию — всё это снижает вероятность того, что пользователь бросит заполнение на полпути.

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

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

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