Фронтенд-разработчик должен заботиться о UX. Но не все специалисты представляют, как именно фронтендер влияет на пользовательский опыт, на что нужно обращать внимание во время работы над проектом и что нужно изучать, чтобы лучше понимать UX. Чтобы разобраться в этих вопросах, пригласили опытных экспертов в области фронтенд-разработки и пользовательского опыта. Специалисты ответили на вопросы и дали конкретные рекомендации начинающим фронтендерам.
- Эксперты о пользовательском опыте
- Андрей Ситник: фронтендер — последний рубеж, который может остановить дизайн-ошибку
- Никита Дубко: фронтенд-разработчик может сделать так, чтобы клиент не только не решил свою задачу, но и никогда больше на этот сайт не вернулся
- Наталия Короткова: надо учитывать, что мнение пользователей может быть ошибочным
- Ник Мостовой: разработчик отвечает не за код, а за продукт
- Ярослав Шуваев: лучшая практика — когда все отвечают за UX
- Что нужно знать о пользовательском опыте новичкам: рекомендации специалистов Хекслета
- Фронтенд-разработчик активно влияет на пользовательский опыт вместе с другими членами команды
UX (англ. User Experience, пользовательский опыт) — восприятие пользователем взаимодействия с продуктом, системой или сервисом. Пользовательский опыт включает эмоции, предпочтения, физические, эмоциональные и поведенческие реакции, которые происходят до, во время и после взаимодействия пользователя с продуктом. Определение ISO 9241-210:2010 Ergonomics of human-system interaction.
Эксперты о пользовательском опыте
О работе с UX читателям блога Хекслета рассказали известные в отрасли экспертов: фронтенд-разработчики и UX-дизайнеры. Специалисты ответили на несколько вопросов:
- UX (user experience, пользовательский опыт) — широкое понятие. На пользовательский опыт влияет огромное количество факторов. Например, если речь идёт об интернет-магазине, на UX влияет ассортимент товаров, цены, скорость реакции службы поддержки, работа службы доставки и так далее. Может ли фронтенд-разработчик тоже влиять на UX? Если да, как это происходит?
- Если на пользовательский опыт влияют абсолютно разные факторы — от ассортимента и цены товаров до интерфейсов и скорости загрузки сайта, кто в целом отвечает за UX? Фронтендер? UX-дизайнер? UI-дизайнер? Продуктовый дизайнер? Менеджер продукта? Может, топ или владелец бизнеса?
- UX — пользовательский опыт. Как вы считаете, можно ли сказать, что опыт — субъективное понятие? Кому-то удобно, когда сайдбар находится слева, кому-то — справа. Как можно объективно улучшить UX, если опыт субъективен?
- Как вы считаете, для проектирования классных интерфейсов, которые обеспечивают отличный UX, достаточно пользоваться какими-то рекомендациями, обобщёнными результатами исследований, закономерностями? Или при разработке каждого конкретного проекта надо интересоваться у пользователей этого проекта, пытаться понять, как та или иная фича влияет на их UX? Ведь, например, у сайтов пенсионного фонда и интернет-магазина для юных альпинистов разная аудитория.
- Что фронтенд-разработчику нужно знать о UX? Что бы вы порекомендовали новичку изучить по этой теме в первый месяц работы? А где можно прокачаться не новичкам, а более или менее опытным специалистам?
Андрей Ситник: фронтендер — последний рубеж, который может остановить дизайн-ошибку
О влиянии фронтендера на пользовательский опыт
С ходу приходят в голову следующие вещи:
- Скорость загрузки
- Фризы UI по мере работы приложения (в отличие от скорости загрузки этой теме отводится слишком мало внимания в нашем сообществе)
- Интеграция с ОС и другими сервисами (например, поддержка Chromecast в видео-сервисе)
- Возможность быстро работать с приложением с помощью клавиатуры для постоянных клиентов
- Автозавершение полей и поддержка менеджерой паролей
Но гораздо важнее другое. Любой человек в команде ошибается. Отдел дизайна и продукт-менеджмента тоже. Им сложно заметить ошибки в дизайне, пока новый дизайн сделан в виде картинок, а не реального приложения.
Фронтендер — последний рубеж, который может остановить дизайн-ошибку. С одной стороны он, в отличие от дизайнера, видит все возможные состояния приложения. Например, в списке друзей может быть ситуация, когда пользователь только зарегистрировался, и его список будет пустым. В этом случае вывести «у вас нет друзей» будет ошибкой. Надо использовать этот экран для объяснения социальных взаимодействий в продукте.
С другой стороны, вы первый человек, который по-настоящему взаимодействует с дизайном. Вы видите, что какие-то кнопки неудобно нажимать на телефоне. Что какие-то дизайн-идеи неочевидные.
Возможность сказать, что у нас тут ошибка в дизайне, как мне кажется, — самое важное влияние фронтенд-команды на UX.
О сферах ответственности
Нет одного универсального UX, чтобы кто-то был за него ответственным. Точно так же нет одного UX, у каждого пользователя свой опыт.
Я считаю, что на фронтенд-команде лежит ответственность за опыт взаимодействия с интерфейсом. Если что-то не понятно — это потому что мы не сказали нет дизайнеру. Если что-то на странице тормозит или медленно грузится — это наши неправильные технически решения.
Если сайт не работает в популярных экосистемах, например, менеджер паролей не заполняет форму — это тоже ответственность фронтендера.
О субъективности и объективности UX
Верно, UX — не область естественных наук. Часть вещей можно свести к строгим сравнительным характеристикам — скорость загрузки к метрикам Lighthouse, производительность UI к длине фриза и количеству FPS, удобство к количеству кликов.
Но ту же понятность нельзя выразить такими метриками. Да и метрики в целом не всегда отражают реальность. Тот же вынос кода в параллельный поток Web Worker по факту снижает время выполнения задачи — но повышает субъективное ощущение от тормозов приложения.
Но человечество не в первый раз сталкивается с необходимостью работы с субъективными характеристиками. Для этого есть целый набор наук, которые мы называем гуманитарными. Читайте больше про гуманитарные науки и их методы.
О связи между пользовательским опытом и целевой аудиторией
Тут всё как с оптимизацией — она должна строится на профилировании, а не советах типа «двойные кавычки медленнее одинарных».
Рекомендации и советы тоже важны, но они по-другому работают. Это не ответы. Но они создают у вас интуицию, которая позволяет предугадать, где источник проблемы (но он может быть не там).
Самый лучший способ — дайте приложение друзьям, попросите что-то делать и смотрите как они им пользуются.
Для тестов производительности, купите старый дешёвый китайский андроид-телефон. Отойдите туда, где плохая связь (в Питере я спускаюсь в метро) и попробуйте попользоваться вашим сайтом.
Где и как прокачиваться в UX
Я сам фанат клипового мышления. Поэтому я просто стараюсь погружаться в сообщество — читать больше соцсетей и блогов дизайнеров.
Об эксперте
Андрей Ситник, ведущий фронтендер Злых марсиан, автор Автопрефиксера, PostCSS и Логакса.
Никита Дубко: фронтенд-разработчик может сделать так, чтобы клиент не только не решил свою задачу, но и никогда больше на этот сайт не вернулся
О влиянии фронтендера на пользовательский опыт
UX — это то, как быстро и с каким эмоциями пользователь решит задачу, которую хочет решить. Когда мы говорим о веб-сайтах, то именно фронтенд-разработчик может сделать так, чтобы клиент не только не решил свою задачу, но и никогда больше на этот сайт не вернулся. Справедливо и обратное: если разработчик задумается о том, чтобы обеспечить клиенту комфорт на сайте в виде удобного незабагованного интерфейса, уместного управления с клавиатуры, производительных анимаций, почти моментальной загрузки и плавных переходов между страницами — клиент обязательно вернётся и друзей приведёт.
О сферах ответственности
Мне кажется, за пользовательский опыт отвечает вся команда. Задача команды — обеспечить рост бизнесу. Рост возможен, когда клиент доволен. Поэтому очень круто, когда дизайнер старается продумать путь клиента по сайту до достижения цели, обсуждает это с разработчиками, спрашивает, смогут ли они такое реализовать, уточняет у продакт-оунера, действительно ли новая фича приносит пользу, а не тешит самолюбие автора идеи, и так далее. Фронтендер, как то звено, которое ближе всех к конечному пользователю, должен влиять на продукт, на его дизайн и будущую функциональность как минимум через общение внутри команды и донесение своих аргументов и идей.
О субъективности и объективности UX
Про субъективность правда. Никогда не получится сделать продукт, который будет нравится абсолютно всем. Тот же крестик для закрытия окна в Windows изначально вообще был не крестиком, а квадратиком с полоской и находился в левом углу, а на яблочных системах — кружочек в левом. Важная функция, важный элемент интерфейса, а общего мнения до сих пор нет.
Нужно наблюдать за своей целевой аудиторией. Если есть возможность — опрашивать и проводить исследования интерфейсов с живыми людьми, задавать им вопросы в процессе. Виталий Фридман из Smashing Magazine делился таким опытом на своих мастер-классах, и такие исследовательские сессии порой рождают абсолютно неочевидные идеи, которые помогают сделать ваш интерфейс лучше. Скорее всего, вы можете себе позволить проводить AB-тестирование и смотреть влияние правок на продуктовые метрики. На худой конец можно посмотреть в какой-нибудь Яндекс.Метрике реальные пользовательские сессии и глазами увидеть, какие операции на сайте реально вызывают сложности.
Ключевая идея — замерять эффекты на большой аудитории и принимать решения по результатам замеров. То есть не насаждать пользователю добро, потому что вы так субъективно решили по своему опыту, а проверить, действительно ли вы приносите пользователю и продукту добро.
О связи между пользовательским опытом и целевой аудиторией
Вопрос, в котором скрыт ответ. Когда проект только начинается, вы ещё не знаете свою аудиторию, у вас есть только догадки о том, какая она будет. В этот момент вполне нормально опираться на уже существующие исследования. Скорее всего, если вы будете использовать хорошие практики, вроде быстрой загрузки, доступности, экономии трафика, семантичной вёрстки, адаптивности и прочих — вы уже сделаете неплохой задел для продуктовых улучшений без оглядки на базовые вещи. Дальше, с ростом продукта, нужно более серьёзно изучать целевую аудиторию и подстраиваться под её требования. Вряд ли клиент попросит сделать сайт медленным, скорее — добавить новую функциональность.
Где и как прокачиваться в UX
Рано или поздно разработчик становится пользователем. Поэтому главное правило — делать так, чтобы самому себе было удобно и приятно пользоваться результатами своего труда. Любой дискомфорт — сигнал, что можно сделать лучше.
Новичку в первые месяцы работы всё же советую прокачивать базовые знания и набивать руку. UX ближе к психологии, чем к технологиям, мне кажется, поэтому постепенно это знание будет приходить на основе опыта и набитых шишек.
Я сам беру многое из пабликов «Веб-стандарты» и For Web, сайтов Smashing Magazine, A List Apart, подписываюсь в твиттере на интересных мне разработчиков и слежу за их публикациями. На YouTube есть немало записей с конференций дизайнеров, оттуда можно почерпнуть полезные знания из иногда чуждого разработчику мира — полезно посмотреть на свою работу с другого ракурса.
Об эксперте
Никита Дубко, разработчик интерфейсов в Яндексе, ведущий подкаста «Веб-стандарты».
Эксперты Nielsen Norman Group говорят, что не стоит путать UX и юзабилити. По их данным, юзабилити — качественная характеристика пользовательского интерфейса, которая показывает, насколько легко, эффективно, приятно пользоваться системой. То есть UX — более широкое понятие, а юзабилити — его часть.
Наталия Короткова: надо учитывать, что мнение пользователей может быть ошибочным
О влиянии фронтендера на пользовательский опыт
Фронтенд-разработчик влияет на UX через элементы пользовательского интерфейса, различные их состояния, навигацию, интерактивность и производительность страницы.
О сферах ответственности
За UX отвечает продуктовый дизайнер. Иногда такой роли нет, и она распределена между другими членами команды. В любом случае, это коллективная работа и ответственность. Фронтенд-разработчик создает пользовательский опыт на основе известных ему UI-паттернов, затем продуктовый дизайнер проводит исследования и предлагает улучшения.
Разработчик, как узкий специалист, может подсказать проблемные места в предстоящей реализации идеи, поэтому результат зависит от правильно выстроенной коммуникации. Я думаю, что ценообразование и ассортимент регулируются экономикой проекта и не относятся к факторам UX.
О субъективности и объективности UX
Один из способов принять решение объективно — запустить A/B тест. Всем не угодишь, но цифры наглядно покажут какой вариант эффективнее. Есть и другие интересные способы, например eye-tracking тестирование, которое расскажет многое о перемещении пользователя по странице.
О связи между пользовательским опытом и целевой аудиторией
Конечно нужно интересоваться у пользователей. Однако надо учитывать, что мнение пользователей может быть ошибочным. Нередки ситуации, когда люди очень просят что-то, но когда получают, продукт перестает им нравиться. Хороший UX строится на фундаменте из общеизвестных принципов и исследовании конкурентов, а после улучшается с помощью данных полученных от реальной аудитории. Это включает в себя не только опросы людей, но и аналитику их поведения из различных инструментов, опыт и интуицию UX специалиста.
Где и как прокачиваться в UX
Советую обратить внимание на метрики страницы (Web Vitals, аудит в Lighthouse), производительность анимаций, доступность и дизайн-системы. Новичку рекомендую начать с изучения популярных UI-библиотек, обращая внимание на набор компонентов, типографические стили и анимации.
Прокачиваться можно, анализируя решения в продуктах конкурентов, читая разборы типичных UX ошибок, а также через нетворкинг с UX-специалистами. Опытным можно поэкспериментировать на личном проекте, чтобы попрактиковаться и, возможно, заработать миллиард долларов.
Об эксперте
Наталия Короткова, Senior Frontend Developer.
Ник Мостовой: разработчик отвечает не за код, а за продукт
О влиянии фронтендера на пользовательский опыт
Сила влияния разработчика на UX часто зависит от компании. Где-то это ярко выражено, где-то меньше. Разработчик отвечает не за код, а за продукт. То есть он смотрит, как продукт развивается, насколько легко вносить изменения или что-то добавлять в него. Разработчик, конечно же, может предлагать и обсуждать решения. Продукт — это то, что трогает пользователь, что приносит деньги компании. Код в данном случае вторичен. Фронтенд-инженеры обычно «качаются» в нескольких направлениях. Они:
- могут писать код
- понимают, как работают интерфейсы, a11y и так далее
- общаются с заказчиками, менеджерами, дизайнерами, уточняют требования к продукту, описывают user stories
- имеют представление о направлении бизнеса, в котором работают. Даже если разработчик приходит без понимания процессов в бизнесе в компании, то со временем такие компетенции появляются за счет погружения в среду и общения
На этапе общения с менеджерами и заказчиками, когда команда разработки формирует видение будущей фичи, разработчики могут влиять на продукт. Например, они могут сказать:
- вот тут у нас есть селект, нам важно сделать так, чтобы он был доступен, чтобы любой пользователь смог выбрать корректно элемент
- здесь у нас появляется всплывающее окно и три кнопки, давайте выделим эту кнопку как основную, тем самым стимулируем пользователя выполнить запланированное действие
Сценариев может быть немало. Если первый сценарий в примере про доступность интерфейсов, то второй больше про какие-то субъективные решения разработчика. Это решение обсуждают на встрече и принимают решение — попробовать, протестировать или не внедрять.
Если идею решили внедрять, то ее важно верифицировать. Верификации происходят по разному. Это зависит от аудитории проекта, её объемов, вышел ли продукт на рынок или это только прототип.
Назову пару наиболее популярных способов:
- фокус-группы — берем N потенциальных пользователей продукта, показываем интерфейс(ы) просим выполнить действия. Следим за действиями. Здесь мы получаем не количественную метрику, но качественную
- АБ-тесты. Количественная метрика, которая помогает решить, сработала ли выделенная кнопка, стали ли пользователи выполнять целевые действия лучше
Как фронтенд-инженеру начать влиять на продукт? Интересуйтесь процессами в компании. Узнайте, как происходит «придумывание» и описание будущих фич. Кто отвечает за них, как распределяются роли в проекте. Все это называется product discovery — процесс, когда новая фича проходит этапы от «появилась идея» до «задача проработана и готова к разработке». Не зацикливайтесь только на product delivery этапах или, по-другому, на разработке.
И, конечно же, общайтесь со своими дизайнерами. Фронтендеры и дизайнеры выполняют общее дело — сделать так, чтобы пользователь мог выполнить свои задачи на сайте эффективно.
О сферах ответственности
Отвечают все сразу. Здесь самое важное — не стать лебедем, раком и щукой. Часто можно услышать: разработчик хочет сделать красивый код, дизайнер анимации и чтобы выглядело эффектно, а менеджер — чтобы было вчера.
На самом деле, это показатель зрелости коллектива. Разработчик должен понимать, зачем дизайнер добавляет для этой «выпадашки» анимацию (например, чтобы сфокусировать внимание пользователя, потому что на странице очень много элементов), дизайнер также может понять стремление разработчика все унифицировать. Они могут даже собраться вместе, обсудить проблемы и найти точки соприкосновения. Аналогично и с менеджером. Менеджеру нужен работающий продукт, которым пользуются. Эти специалисты могут идти на компромиссы:
- сделать прототип, чтобы после выхода на рынок поправить техдолг
- упростить некоторые интерфейсы, чтобы провести больше АБ тестов, развить удачные идеи
В зрелом коллективе команда принимает решения. UX не исключение. И важный момент в конце — разработчик должен видеть в дизайнере профессионала и доверять его действиям. Дизайнер — в разработчике. Разработчик и дизайнер в менеджере, менеджер в разработчике и дизайнере. Без доверия никакого «принимает решения» и «командной ответственности» не будет.
Здесь ещё можно заметить, что основным ответственным за проект всегда будет владелец продукта или владелец бизнеса. Потому что они отвечают за проект своей компанией, бюджетом. UX — важная часть продукта. Но сказать, что владелец продукта отвечает за UX, не совсем корректно. Если бы я был владельцем компании и отвечал за UX и все остальное, то зачем мне нанимать других специалистов? Они нанимаются для делегирования обязанностей и выполнения задач.
О субъективности и объективности UX
Посмотрите на UX сайтов 90-х или начала нулевых. Вы заметите большое количество экспериментов, так как «UX субъективен». Посмотреть можно здесь.
Со временем эти эксперименты эволюционировали, интерфейс превратился в унифицированные детали. Так и для пользователей — несмотря на то, что современные сайты окрашены по-разному, основные паттерны у пользователя остаются неизменными.
Помочь в оценке всегда могут качественные и количественные методы. Также обратите внимание на вот это видео. Внимание — это тоже пользовательский опыт.
О связи между пользовательским опытом и целевой аудиторией Нужно понимать свою аудиторию и проводить работу с ней, а не ориентироваться на абстрактные данные. Есть паттерны, которые справедливы для большинства пользователей, есть те, которые применимы для конкретной аудитории. В большинстве случаев поведение пользователя зависит от контекста.
Где и как прокачиваться в UX Новичку — подружиться с своим дизайнером, общаться больше с менеджером и разобраться как и почему те или иные решения принимаются. Понимание продуктовой сферы приведет к пониманию аудитории.
Затем набраться опыта построения интерфейсов. Здесь — читать про best practices и применять их в компании. Построение интерфейсов и хорошее знание предметной области приведет к прокачке своих UX-навыков.
Также можно посоветовать подписаться на блоги и сайты известных дизайнеров, например Илью Бирмана, но я думаю, это довольно общий совет. Опыт, на мой взгляд, важнее.
Для опытного специалиста совет будет аналогичным. Хороший специалист понимает что и каким образом он может сделать для компании, чтобы улучшить продукт, увеличить доходы. Несмотря на то, что он командный игрок, у него все еще есть автономность.
Об эксперте
Ник Мостовой, член программного комитета HolyJs, спикер и ex-lead developer в http://hh.ru. Twitter, Telegram.
Ярослав Шуваев: лучшая практика — когда все отвечают за UX
О влиянии фронтендера на пользовательский опыт
Надо сказать, что есть несколько факторов, на которые может повлиять фронтенд-разработчик. Первый и самый основной: важную часть качества пользовательского опыта составляет техническая доступность и скорость программного обеспечения. То есть то, насколько быстро и стабильно работает программный продукт. Разработчик может прямо влиять на это, создавая оптимальные в плане скорости загрузки продукты, в плане распределения запросов внутри системы. То есть разработчик может делать так, чтобы каждый экран отправлял минимум запросов к базе данных.
О сферах ответственности
Конечно, основной фокус здесь падает на дизайн — это дизайнер внутри команды разработки. И второй фокус — это владелец продукта, который занимается развитием и отвечает за бизнес-результат. Но самая лучшая практика — когда все отвечают за UX, когда нет бутылочного горлышка. То есть когда все в команде имеют экспертизу в области UX, все заинтересованы в том, чтобы пользовательский опыт был максимально качественным, а продукт максимально жизнеспособным.
О субъективности и объективности UX
Да, с одной стороны может показаться, что пользовательский опыт — субъективное понятие. Но с другой стороны можно свести качество UX к неким метрикам. Например, к самым популярным метрикам относится время удовлетворения потребности пользователя. Можно даже сказать, что основной фактор, влияющий на качество пользовательского опыта — дофамин. Чем быстрее пользователь удовлетворяет потребность, тем больше дофамина она получает.
Есть дополнительный фактор: ресурсоёмкость, когнитивная нагрузка, которая падает на пользователя. Здесь уже играет роль не только время. Здесь считается энергоёмкость выполнения тех или иных задач. Здесь сложнее посчитать, нужно использовать более сложные вычисления.
Эти два фактора позволяют достаточно точно измерить качество пользовательского опыта.
О связи между пользовательским опытом и целевой аудиторией
Что касается поведенческих паттернов, то есть как люди привыкли видеть какой-то элемент — справа или слева, как раз здесь могут хорошо помочь разработчики. Потому что Android-разработчики, iOS-разработчики и так далее используют стандартные для операционной системы паттерны. Так они снимают с пользователя нагрузку, связанную с адаптацией к новым интерфейсам. Поэтому здесь можно сказать, что разработчик делает жизнь пользователя проще за счёт того, что применяет стандартные паттерны, которые понятны пользователю.
Конечно, есть разные нюансы. Кто-то воспитывался в среде, где принято вешать логотип справа в верхнем углу. Но исследования показывают, что со временем большинство пользователей привыкает к стандартному паттерну. То есть на меньшинство не всегда стоит ориентироваться. Надо стараться сделать счастливыми максимальное количество пользователей.
Где и как прокачиваться в UX
Проектирование цифровых продуктов состоит из нескольких слоёв. Самый верхний — стиль продукта, визуальное оформление. Следующий слой — компоновка продукта, расположение элементов на экране. Третий слой — информационная архитектура, структура разделов и каталогов, различные фильтры. На четвёртом уровне — функциональность продукта. На пятом уровне стратегии, то есть на каком уровне какие проблемы решаются. На каждом уровне используются самые актуальные практики дизайна или, если по-русски, проектирования. У нас в UX Academy есть курс, который раскрывает эти практики для каждого уровня. Также есть есть методичка или небольшой гайд, который позволяет пробежаться и узнать какие-то основные инструменты для каждого слоя.
Об эксперте
Ярослав Шуваев, руководитель центра компетенций Внутренних Инноваций Ак Барс Цифровые Технологии, куратор курса UX&UI в BHSAD.
Что нужно знать о пользовательском опыте новичкам: рекомендации специалистов Хекслета
Преподаватель вёрстки на Хекслете Никита Михайлов и фронтенд-разработчик Хекслета Роман Макаров в формате вопрос-ответ дали конкретные рекомендации новичкам об изучении UX и применении лучших практик в работе.
Никита Михайлов: вёрстка — воплощение дизайна в браузере или в мобильных приложениях
— Как вёрстка связана с пользовательским опытом, как она влияет на UX?
— По сути, вёрстка — воплощение дизайна в браузере или в мобильных приложениях. То есть это последний шаг перед тем, как пользователь увидит готовый продукт. На верстальщике висит задача не только перенести то, что нарисовал дизайнер. Он должен ещё и адаптировать дизайн под правильное использование.
Например, если речь идёт о формах, верстальщик должен следить, чтобы форма всегда была понятной. Чтобы не было ситуации, когда пользователь ввёл какое-то значение, потом удалил его и не может понять, а что это за поле. Это очень распространённая проблема, когда верстальщики используют плейсхолдер и больше ничего. А пользователи не могут понять, что нужно указать в каком-то поле.
Верстальщик должен подписывать все элементы, чтобы обеспечить доступность. Когда мы говорим UX, то подразумеваем пользовательский опыт всех людей, включая людей с особенными потребностями. Для таких людей пользовательский опыт немного другой, а верстальщик должен хорошо знать эти отличия. Он должен понимать, как организовать интерфейс так, чтобы им было удобно пользоваться всем людям.
— Можно ли провести чёткие границы ответственности за пользовательский опыт: сказать, что здесь сфера ответственности дизайнера, здесь верстальщика, а вот здесь пусть отвечает фронтенд-программист?
— На мой взгляд, это коллективная ответственность. Если делить зоны ответственности, можно попасть в ситуацию, когда каждый сделал как бы свою часть работы и забил на всё остальное. Но в процессе работы верстальщик может увидеть, что вот здесь неплохо что-то переделать. Распространённая ситуация — дизайнер работает на аутсорсе. В таких условиях верстальщику нужно что-то самому переделывать. А он может что-то неправильно интерпретировать. Поэтому все отделы должны взаимодействовать.
— Первое, что приходит в голову о взаимосвязи между вёрсткой и UX — адаптивность страниц. То есть верстальщик влияет на то, чтобы пользователю было удобно работать со страницей на любом экране. Можно ли выделить ключевые рекомендации, которые должен держать в уме верстальщик, когда создаёт адаптивную страницу?
— Первое: наверное, главное, что забывают начинающие специалисты — проверять страницу не только на тех разрешениях, которые дал дизайнер. У нас очень много разных устройств, пользователи по разному взаимодействуют с сайтом. Например, некоторые люди разбивают окно браузера на несколько частей. Если мы берём стандартные вещи, смотрим, чтобы у нас всё отображалось на 1280 пикселей, на 320, 540, но при этом забываем про другие пограничные состояния, это может привести к тому, что у части пользователей всё будет рушиться. Например, появятся очень большие карточки или очень мелкий текст, когда разрешение экрана позволяет сделать его больше.
Второе: надо помнить, что мобильные устройства имеют две ориентации — вертикальную и горизонтальную. Часто верстают под вертикальную ориентацию, забывая про горизонтальную. В этом случае высота видимой области страницы становится ниже, чем необходимо. Это не очень удобно для пользователей, особенно если на странице есть плавающее меню. Оно может закрыть весь контент.
Третье: надо помнить, что пользователи могут увеличивать страницу. Нужно проверять, чтобы на таких разрешениях вёрстка не разваливалась. То есть если мы сверстали страницу под определённую ширину, но не учли возможность масштабирования, работа не сделана. Желательно проверять на стандартных разрешениях хотя бы двукратное увеличение, смотреть, чтобы здесь всё корректно отображалось.
— Ещё один аспект, влияющий на пользовательский опыт — скорость загрузки. Что в этом контексте может сделать верстальщик? Можно прямо несколько рекомендаций.
— Первое: здесь от верстальщика зависит объём контента, который подгружается на страницу. Всегда нужно следить за размером страницы. Плохо, если на странице две или три картинки, которые весят по 12 Мбайт. Обязанность верстальщика — следить за размерами и оптимизацией изображений. Надо использовать сжатие. Если у изображения нет прозрачного фона, нет смысла держать её в png. Надо следить за размером файлов CSS и HTML, использовать минификацию.
Второе: надо помнить, что обработка HTML — затратная операция для браузеров. Чем глубже вложенность блоков, тем дольше браузер этот код обрабатывает. Даже в Google PageSpeed есть показатель вложенности HTML. То есть надо делать простую вёрстку и не плодить вложенности. Чем чище и проще наш код, тем быстрее браузер его обработает и выведет результат на экран. Это справедливо даже при проблемах с сетью.
— Формы — отдельная тема, вокруг неё сломано много копий. Как ты считаешь, что может сделать верстальщик, чтобы с формами было удобно работать, чтобы у пользователя был позитивный опыт взаимодействия с ними?
— Внешний вид формы — это работа дизайнера. Но все в команде должны работать вместе. При разработке форм верстальщик должен помнить несколько вещей.
Первое: подписи полей. Нельзя полностью рассчитывать на плейсхолдеры. Когда страница с формой загружается, благодаря плейсхолдеру пользователь видит, что требуется в конкретном поле. Но как только он начинает что-то вводить, плейсхолдер исчезает. Если стереть ввод, невозможно понять, о чём поле. Поэтому надо использовать лейбл.
Второе: пользователю удобно, если поля сгруппированы. Не стоит давать пользователю поля сплошной массой. Если мы не делим поля на группы, в них легко запутаться. Стоит выделять группы заголовками. И при этом нельзя забывать про лейблы.
Третье: если у нас есть огромная форма, не стоит сразу вываливать её на пользователя. Лучше дать возможность человеку заполнить часть формы, потом нажать кнопку «Далее» и показать следующую часть. Большое количество полей может отпугнуть пользователя. Он увидит, что надо заполнить 20 или 30 полей, и уйдёт.
Четвёртое: кнопки должны быть информативными. Если у нас есть кнопки «Отправить» или «Очистить», они не должны выглядеть одинаково. Пользователь должен легко отличать их по цвету. А если цвета будут семантичными, пользователю будет намного проще понять, что одна кнопка сбрасывает, а другая отправляет форму.
— Наверное, нельзя не упомянуть навигацию — как здесь верстальщик может позаботиться о хорошем пользовательском опыте?
— Первое: с точки зрения качества пользовательского опыта важно, чтобы все ссылки на странице были понятными. Не должно быть ситуации, когда ссылка похожа на текст. Часто в угоду дизайна удаляют подчёркивание. Но даже в этом случае ссылка должна отличаться от простого текста, пользователь должен видеть её.
Второе: надо помнить про семантическую вёрстку, это прямая обязанность верстальщика. Хороший UX всегда построен на грамотной вёрстке, в том числе на семантической вёрстке. Разные устройства могут считывать информацию, ориентируясь на теги, которые мы использовали для вёрстки. Например, режим чтения в телефоне часто ориентируется на то, какие семантические теги мы использовали, в том числе теги навигации.
Третье: верстальщик должен помнить, что у любой ссылки или кнопки должно быть несколько состояний. Задача верстальщика — сделать какое-то дефолтное поведение, даже если дизайнер этого не нарисовал. Например, если пользователь наводит курсор на ссылку, она должна меняться, должна показывать, что с ней взаимодействуют. Или когда пользователь использует фокус с помощью клавиатуры, ссылка должна реагировать на это.
Четвёртое: если у нас есть подменю, оно должно быть именно подменю. Нельзя его вываливать на пользователя всем списком. Плохо, если у нас в шапке сайта 50 ссылок, и по ним трудно понять, как они относятся друг к другу. Главное меню должно быть главным, то есть в нём нужно показывать основные разделы сайта. А подразделы лучше показывать на страницах основных разделов.
— Доступность — как она влияет на пользовательский опыт? Есть ли набор рекомендаций по улучшению доступности?
Первое: верстальщик должен проверять сайт, над которым работает. Например, попробовать пройти по сайту с помощью клавиатуры. Если здесь он может увидеть все интерактивные элементы, они все выделяются, это уже большой плюс.
Второе: валидная семантическая вёрстка — это уже работа над доступностью. Поэтому всегда проверяйте сайт с помощью валидатора. Если он не находит ошибок, это ещё один плюс в копилку доступности. То есть это гарантирует, что многие скринридеры смогут правильно воспроизвести сайт.
Часто верстальщики используют неподходящие элементы. Например, вместо кнопки они используют простой <div>. Скринридеры не понимают, что этот элемент — кнопка.
Третье: указывайте атрибуты alt у изображений. В этом атрибуте нужно указывать осмысленную информацию — описание картинки. Его «прочитает» незрячий пользователь, когда попадёт на эту картинку. Понятно, что alt «фото 123» ничем такому пользователю не поможет.
— Где можно прокачиваться верстальщику, как узнавать больше о вёрстке в контексте UX?
— Первое, что приходит в голову — Google. Потом идёт знаменитая книга Стивена Круга «Не заставляйте меня думать». Также нужно интересоваться дизайном, смотреть результаты исследований, не думать, что это чисто работа дизайнера.
Нужно читать книги о дизайне интерфейсов. Здесь я рекомендую «Бюро Горбунова». У них есть отличные книги на тему типографики, пользовательских интерфейсов. У них есть курсы дизайна.
Также рекомендую смотреть сайт Awwwards. Здесь можно найти примеры отличных дизайнов и вёрсток. Наконец, отличная практика — изучать современные фреймворки, тот же Bootstrap. Этот фреймворк очень популярный, а его компоненты сделаны с учётом лучших практик UX.
Начните изучать разработку с бесплатного курса «Основы современной вёрстки». Вы научитесь создавать статические веб-страницы, стилизовать элементы, использовать редакторы кода с полезными расширениями. В конце курса вы опубликуете свой первый сайт на GitHub Pages.
Роман Макаров: разработчик должен ставить себя на место пользователей и проверять интерфейсы
— Как фронтенд-программист влияет на UX?
— С одной стороны, фронтенд-разработчик должен выполнять поставленные техзадания, а эти задания ставят люди, которые разбираются в UX. С другой стороны, есть базовые вещи, которые фронтенд-разработчик должен знать и по умолчанию делать какие-то вещи удобными для пользователей.
— То есть фронтендер делает то, что уже спроектировали дизайнеры?
— Даже не дизайнеры, а специалисты по пользовательскому опыту. Также есть аналитики, бизнес-аналитики, которые могут подсказать, как совместить видение фронтендера с интересами бизнеса.
— Можно ли провести чёткие границы ответственности за пользовательский опыт: сказать, что здесь сфера ответственности дизайнера, здесь верстальщика, а вот здесь пусть отвечает фронтенд-программист?
— Каждый из упомянутых специалистов отвечает за достаточно широкий фронт работ. Иногда люди выполняют смежные задачи. Например, у нас на проекте нет UX-дизайнера, поэтому мы работаем в связке: фронтенд-программист, верстальщик и ребята от бизнеса.
— Наверное, стоит начать с форм: можно ли дать несколько конкретных рекомендаций по проектированию форм? Как фронтенд-программист может здесь улучшить пользовательский опыт?
— Форма — сложный компонент веб-страницы, она объединяет сразу несколько интерактивных элементов. Здесь могут быть кнопки, радиокнопки, чекбоксы, текстовые инпуты, селекты и так далее. Наверное, самое большое число интерактивных элементов приходится на форму.
Первое: интерфейс должен вести себя предсказуемо, он не должен удивлять пользователя. Поэтому важно самому проверять интерфейсы, которые вы разрабатываете. Надо спрашивать себя, удобно ли пользоваться этой формой, предсказуемо ли она работает.
Второе: если в форме есть обязательные поля, их надо обозначать как обязательные.
Третье: должна быть стратегия валидации формы. Например, у новичков часто встречается ошибка — они начинают валидировать форму до момента, когда пользователь покинул поля или когда он нажал кнопку «Отправить». В этом случае пользователь вводит первый символ, а ему сразу показывается сообщение о невалидной информации, так как минимальное число символов в поле 20. С моей точки зрения, это удивляет пользователя: он только начал писать, а ему уже показывается красная плашка.
Четвёртое: если форма невалидная, у пользователя не должно быть возможности отправить её на сервер. Это можно реализовать с помощью заблокированной кнопки отправки. Также интерфейс должен подсказывать пользователю, какие поля невалидные.
Например, у нас в четвёртом проекте достаточно простой интерфейс. В нём есть однотипные модальные окна и текстовое поле для отправки сообщений. Но новички делают достаточно много ошибок даже на этом минимуме элементов. Например, часто не блокируется кнопка при асинхронных действиях, когда что-то отправляется на сервер.
— Скорость загрузки страниц — один из важных факторов, влияющих на пользовательский опыт. Даже поисковики учитывают его при ранжировании страниц. Как фронтенд-программист может повлиять на этот фактор? Есть какой-то набор рекомендаций, которые можно считать универсальными?
— Тут важно понимать, что это не прихоть поисковых систем. Люди хотят, чтобы сайт загружался максимально быстро. Поисковые системы ориентируются на желания пользователей, поэтому учитывают скорость загрузки при ранжировании сайтов.
Первое: нужно уметь загружать контент прогрессивно. То есть важные вещи должны загружаться сразу, менее важные можно отложить на потом. Для решения этой задачи есть разные приёмы. Например, мы можем в первую очередь загружать ресурсы, которые находятся в верхней части экрана, чтобы пользователь имел возможность с ними взаимодействовать.
Второе: можно загружать картинки в разном качестве или ставить на место картинок заглушки. Это выглядит так: страница загружается, все блоки уже находятся на своих местах. Благодаря этому нет визуального сдвига. Элемент, с которым собирался взаимодействовать пользователь, не будет перемещаться по экрану.
Третье: надо следить за бандлом, смотреть, всё ли там сжимается и оптимизируется. Благо, современные сборщики фронтенда позволяют это делать.
— Можно сказать, что здесь тесно переплетается вёрстка и программирование?
— Есть правила для верстальщиков, они верстают страницы так, чтобы не было этого сдвига. Например, указывают размеры картинок. Браузер в первую очередь получает разметку. И если она выполнена правильно, браузер понимает, где находятся блоки и какие у них размеры.
— Визуализация состояние элементов интерфейса — ещё один важный фактор, влияющий на UX. Может ли здесь быть набор универсальных рекомендаций? Например, выделять активные элементы, отмечать задизейбленные и так далее?
— Да, конечно, за этим нужно следить. Я всегда прошу студентов ставить себя на место пользователей и смотреть, явно ли здесь показано, что кнопка задизейбленная? Понятно ли по состоянию поля, что оно обязательное и без него невозможно отправить форму? Встречается ситуация, когда форма не отправляется, но пользователь не может понять, почему. Это происходит из-за того, что нет сообщений об ошибках или эти сообщения неинформативные.
— Баги в интерфейсах крайне негативно влияют на пользовательский опыт. Есть какие-то рекомендации по их предупреждению, мониторингу, устранению?
— Обработка ошибок — очень важная тема. Первая рекомендация: используйте Rollbar или другие системы логирования. Они нужны, чтобы мы узнавали об ошибках не от пользователей, а самостоятельно.
— А как должно приложение реагировать на ошибки?
— В веб-разработке всегда возможны ошибки. Это могут быть ошибки в приложении или внешние ошибки, например, упавшая сеть, повисший сервер.
Первая рекомендация: пользователь должен знать, что произошла ошибка, для него ситуация должна быть понятной.
Вторая рекомендация: мы должны показать возможные варианты устранения ошибки. Например, предложить пользователю перезагрузить страницу или проверить работоспособность сети или сообщить, когда сеть появится. То есть пользователь должен видеть, что соединение пропало или что оно восстановилось.
Третья рекомендация связана с внутренними ошибками приложения. Мы должны максимально рано показывать пользователю, что произошла ошибка, что что-то сломалось, мы об этом знаем и мы исправим ошибку.
— Где можно прокачаться фронтенд-программисту, чтобы лучше понимать пользовательский опыт и знать, как влиять на UX?
— У нас на Хекслете есть список рекомендуемых книг. Там есть книга Стивена Круга «Не заставляйте меня думать», советую её прочитать, это классика. Также каждый разработчик должен ставить себя на место пользователей и проверять интерфейсы. Полезно пользоваться инструментами, которые помогают по-настоящему посмотреть на сайт глазами пользователя. Например, полезно заглядывать в «Вебвизор».
Фронтенд-разработчик активно влияет на пользовательский опыт вместе с другими членами команды
Такой вывод можно сделать по итогам беседы с экспертами. Опытные специалисты рекомендуют новичкам самим пользоваться интерфейсами, которые они проектируют, и ставить себя на место пользователей. Также фронтендеру нужно интересоваться дизайном и думать о продукте, а не только о коде.
Хотите стать фронтенд-разработчиком, научиться строить классные интерфейсы и влиять на UX? Обратите внимание на профессию «Фронтенд-программист». Обучение можно пройти в группе под руководством опытного наставника.
