BITSPARK / Статьи / Заказ, договор и приёмка

Юзабилити сайта: что это и что проверить до приёмки

Коротко: в справке Яндекс Вебмастера «Юзабилити сайта» слово расшифровано в скобках: «юзабилити (удобство в использовании)». Об оформлении информации и о дизайне Яндекс пишет в других статьях справки, у Google тема называется «удобство страницы», и слова «юзабилити» в этих текстах нет. Яндекс советует сделать суть понятной с первого экрана и не затруднять доступ к тексту. Google задаёт шесть вопросов и пишет, что единого сигнала нет, а хорошие результаты в отчётах не гарантируют высоких позиций.

Подрядчик может произнести «юзабилити сайта», когда обсуждает дизайн или сдаёт сайт. Ниже - значение слова в открытых источниках, вопросы Яндекса и Google об удобстве и список проверок для владельца сайта. Примеры вымышленные (сервис ремонта стиральных машин с сайтом example.ru), английские цитаты даны в оригинале, перевод наш.

Что значит слово «юзабилити»?

Коротко: справка Яндекс Вебмастера «Юзабилити сайта» расшифровывает слово в скобках: «юзабилити (удобство в использовании)». Отдельного определения в ней нет. Запись блога Яндекса 2011 года и текст W3C 2016 года дают свои формулировки.

Справка «Юзабилити сайта | Вебмастер» состоит из трёх абзацев. Слово объяснено в скобках, в предложении о вебмастерах, которые снижают удобство своего сайта:

«(...) снижая юзабилити (удобство в использовании) своего сайта.»

Абзаца с определением в справке нет. Слово стоит в ней как синоним: удобство в использовании сайта.

Справка отсылает к записи блога Яндекса для вебмастеров «Яндекс начинает учитывать юзабилити сайтов». Запись опубликована 5 октября 2011 года и объясняет слово так:

«Качество сайта во многом зависит от его удобства в использовании, называемом также "юзабилити" (от англ. usability). Чем удобнее сайт, тем быстрее и проще посетитель может достичь своей цели - например, найти нужную ему информацию или сделать заказ.»

Инициатива W3C по доступности (Web Accessibility Initiative) описывает слово по-английски; текст обновлён 6 мая 2016 года:

«Usability: is about designing products to be effective, efficient, and satisfying.»

Перевод наш: юзабилити - проектирование продуктов так, чтобы они были эффективными (effective), рациональными (efficient) и приносящими удовлетворение (satisfying).

Что Яндекс называет неудобным в справке «Юзабилити сайта»?

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

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

Что такое переоптимизированный текст, справка не поясняет. В записи блога «Тексты оптимизировались, переоптимизировались, но не выоптимизировались» (13 сентября 2011 года) сказано, что поиск Яндекса «негативно относится» к попыткам повысить релевантность страниц «за счет чрезмерного употребления в текстах ключевых слов». Для заказчика это вопрос к автору текстов: для кого они написаны, для посетителя или для поиска.

О действии на ранжирование справка говорит одним предложением:

«Поэтому мы научили алгоритм определять полезность для пользователей тех или иных элементов страниц и отдавать предпочтение удобным сайтам.»

Какие элементы алгоритм оценивает, справка не перечисляет. Запись блога 2011 года перечисляет «Основные проблемы юзабилити сайтов»: «отсутствие хорошей навигации, сложная или запутанная структура, неудачное расположение элементов сайта, неуместное использование рекламы». Список взят из старой записи, в справке его нет. О навигации и структуре подробно написано в статье о структуре сайта.

Что Яндекс советует об оформлении информации и о дизайне?

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

Справка «Представление информации на сайте | Вебмастер» говорит о ранжировании. Яндекс пишет, что «анализирует, насколько представленная на сайте информация удобна для восприятия пользователем». Советы по оформлению такие:

  1. «Основная суть документа должна быть понятна уже на первом экране браузера.» Первый экран - то, что видно сразу после открытия страницы.
  2. Яндекс не рекомендует «элементы оформления, делающие неочевидным доступ к тексту для пользователей» и называет примеры: «окна прокрутки, скрытые выпадающие блоки».
  3. Большой текст разбивать по нескольким страницам следует «по крупным логическим единицам», пример в справке - главы.
  4. «Текст должен быть написан грамотно и аккуратно оформлен.»

Дальше справка советует выделять заголовки тегами H1-H6 «в соответствии с иерархией документа». Теги H1-H6 - уровни заголовков в коде страницы, от главного заголовка до мелких подзаголовков. Там же сказано, что информация должна корректно отображаться во всех браузерах. Проверка в нескольких браузерах описана в статье о кроссбраузерности.

В справке «Отличия качественного сайта от некачественного | Вебмастер», в разделе «Признаки качественного сайта», о дизайне сказано так:

«Продуманный дизайн. Задача дизайна - помогать быстро находить нужную информацию на сайте.»

«Представление информации на сайте» стоит в меню справки рядом с «Юзабилити сайта».

Какие вопросы об удобстве страницы задаёт Google?

Коротко: документ Google «Анализ удобства страницы» (последнее обновление 24.09.2026) предлагает ответить на шесть вопросов: о Core Web Vitals, безопасности, показе на мобильных устройствах, рекламе, межстраничных объявлениях и различимости основного и второстепенного контента. Google оговаривает, что вопросы не охватывают все аспекты, что единого сигнала нет и что хорошие результаты в отчётах не гарантируют высоких позиций.

У Google слова «юзабилити» нет, тема называется «удобство страницы». Раздел «Как самостоятельно оценить удобство страницы» начинается так: «Если вы отвечаете "да" на приведенные ниже вопросы, то у вашей страницы высокие показатели удобства.» Вопросы такие:

  1. «Высокие ли показатели Core Web Vitals?» Так названы показатели, для которых в разделе материалов есть отдельная ссылка. Как их измерять, в статье не разбирается.
  2. «Ваши страницы выглядят безопасно?» Среди материалов страницы Google - отчёт о HTTPS в Search Console.
  3. «Нет ли проблем с показом материалов на мобильных устройствах?» О мобильных страницах написано в статье об адаптивном сайте.
  4. «Не слишком ли много на странице рекламы, которая отвлекает от основного контента или мешает его просмотру?»
  5. Вопрос о навязчивых межстраничных объявлениях и отдельный документ Google о диалоговых окнах разобраны в статье о всплывающем окне.
  6. «Позволяет ли дизайн страницы легко отличить основной контент от второстепенного?»

Список неполный, и Google пишет об этом сам:

«Эти вопросы не охватывают все аспекты взаимодействия со страницей, которые необходимо учитывать.»

В разделе вопросов и ответов Google отвечает, есть ли единый сигнал удобства и что гарантируют хорошие показатели:

«Единого сигнала нет. Наши системы ранжирования учитывают различные сигналы, связанные с удобством страницы в целом.»

  • Google Поиск, там же

«Учтите, что хорошие результаты в отчетах, например отчете о показателях Core Web Vitals в Search Console или отчетах сторонних инструментов, не гарантируют показ ваших страниц на высоких позициях в результатах поиска.»

  • Google Поиск, там же

Отдельно Google отвечает, оценивается удобство по каждой странице или по сайту, и насколько оно важно для высокого места в выдаче:

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

  • Google Поиск, там же

«Цель Google Поиска - предлагать пользователям наиболее актуальный контент, даже если он располагается на не очень удобных страницах. Однако по многим запросам можно найти массу полезного контента. В таких случаях удобство страницы может стать залогом вашего успеха.»

  • Google Поиск, там же

Для каких запросов это верно, Google не уточняет. Позиций он не обещает.

Какой размер кнопок и ссылок для телефона называет web.dev?

Коротко: текст web.dev «Доступные цели касания» (последнее обновление 31.03.2020) называет минимальный рекомендуемый размер области касания около 48 пикселей, независимых от устройства, что соответствует примерно 9 мм, и расстояние между областями около 8 пикселей. В английской версии те же числа.

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

В английской версии «Accessible tap targets» те же числа:

«A minimum recommended touch target size is around 48 device independent pixels on a site with a properly set mobile viewport.»

Перевод наш: минимальный рекомендуемый размер области касания - около 48 независимых от устройства пикселей на сайте с правильно заданной областью просмотра для мобильных устройств. Дальше приведён пример: значок шириной и высотой 24 пикселя можно довести до 48 пикселей дополнительным отступом. Область 48 на 48 пикселей соответствует примерно 9 мм, а между областями касания советуют оставлять около 8 пикселей по горизонтали и вертикали.

Текст датирован 2020 годом, русская версия - машинный перевод. Вам эти числа нужны как вопрос к подрядчику: какие размеры областей касания заданы в макете и в вёрстке.

Как увидеть, где посетителям неудобно после запуска?

Коротко: справка Яндекса «Анализ поведения пользователей» называет, за чем следить: на каких страницах посетители задерживаются, каким маршрутом идут, почему не доходят до целевых страниц и какие страницы затрудняют поиск информации. Для анализа справка рекомендует Яндекс Метрику. Настройка счётчика в статье не описана.

Такие данные появляются, когда у сайта есть посетители, то есть после запуска. Справка «Анализ поведения пользователей | Вебмастер» перечисляет, за чем следить:

«(...) на каких страницах они задерживаются, каким маршрутом они перемещаются по страницам сайта, почему могут не доходить до целевых страниц (например, до страницы заказа товара), какие страницы затрудняют поиск информации на сайте (...)»

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

Какая доля посетителей считается нормой и какая конверсия хорошая, справка не называет. До запуска достаточно одного вопроса к подрядчику: какие страницы целевые.

Как проверки выглядят у сервиса ремонта?

Коротко: пример вымышленный. Заказчик сервиса ремонта стиральных машин с сайтом example.ru открывает страницу «Заказать ремонт» с телефона и с компьютера и записывает по каждому пункту, какой источник за ним стоит.

Все результаты ниже придуманы. Запись заказчика после просмотра могла бы выглядеть так:

  • Первый экран телефона: виден заголовок и кнопка «Заказать ремонт». Опора: Яндекс, суть понятна с первого экрана.
  • Цены: лежат в раскрывающемся блоке, который открывается со второй попытки. Просим подрядчика вынести их в текст или объяснить, как блок открывается. Опора: Яндекс, элементы, скрывающие доступ к тексту.
  • Основное и второстепенное: рядом с формой заявки стоит баннер акции того же цвета и размера. Вопрос дизайнеру: чем главное отличается от второстепенного. Опора: вопрос Google о различимости контента.
  • Кнопка «Позвонить» стоит вплотную к кнопке «Написать». Вопрос подрядчику: какие размеры областей касания и расстояния между ними заданы в макете. Опора: web.dev.
  • Целевая страница «Спасибо, заявка отправлена». Её адрес записан в задании, чтобы после запуска видеть, кто до неё дошёл. Опора: Яндекс, анализ поведения пользователей.

Что решить до дизайна и что спросить у подрядчика?

Коротко: шесть вопросов ниже опираются на разделы статьи. Ответы записываются в задание дизайнеру до утверждения макета.

На главной странице BITSPARK процесс описан пятью шагами: «Задача», «Структура», «Дизайн», «Разработка», «Запуск». Шаг «Дизайн» там сформулирован так: «Формируем характер проекта: типографику, композицию, движение и систему интерфейса.» Вопросы ниже составлены для любого исполнителя.

  1. Какое действие посетитель совершает на каждой ключевой странице и какие страницы целевые? Опора: Яндекс, «Анализ поведения пользователей».
  2. Что станет понятно с первого экрана каждой страницы? Опора: Яндекс, «Представление информации на сайте».
  3. Есть ли в макете окна прокрутки, скрытые выпадающие блоки и другие элементы, усложняющие доступ к тексту? Опора: тот же текст Яндекса.
  4. Как разделён длинный текст и как заголовки расставлены по уровням H1-H6? Опора: тот же текст Яндекса.
  5. Что в макете основное и что второстепенное, где стоит реклама, если она есть, и нужны ли окна поверх страницы? Опора: два вопроса Google из списка и статья о всплывающем окне.
  6. Каков размер областей касания и расстояние между ними? Опора: web.dev, около 48 и около 8 пикселей.

О шапке написано в статье о шапке сайта, о записи решений в задании - в статье о техническом задании.

Что проверить самому при приёмке с компьютера и с телефона?

Коротко: семь проверок, у каждой есть опора в источнике. Список служит для разговора с подрядчиком, специалист и настройка инструментов для него не нужны.

  1. Откройте главную и две-три ключевые страницы с компьютера и с телефона. Для каждой ответьте, понятна ли суть сразу после открытия. Опора: Яндекс, первый экран.
  2. Найдите окна прокрутки и выпадающие блоки. Откройте каждый и проверьте, очевидно ли, как добраться до текста. Опора: Яндекс, элементы, скрывающие доступ к тексту.
  3. Определите, чем главное отличается от второстепенного, и сколько места занимает реклама, если она есть. Опора: два вопроса Google о рекламе и о различимости контента.
  4. Пройдите путь посетителя до целевой страницы, например от первой страницы до отправки заявки, с телефона и с компьютера. Опора: Яндекс, целевые страницы. Шаг «Запуск» главной страницы BITSPARK описан так: «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.»
  5. С телефона нажмите пальцем кнопки, ссылки и пункты меню. Отметьте места, где палец задевает соседний элемент, и спросите подрядчика про размер областей касания. Опора: web.dev, около 48 и около 8 пикселей.
  6. Откройте сайт ещё в одном браузере. Опора: Яндекс, информация должна корректно отображаться во всех браузерах.
  7. Проверьте, не уходит ли страница с телефона за край экрана по горизонтали и читается ли текст. Опора: рекомендации Яндекса для мобильных страниц, справка «Сайты для мобильных устройств | Вебмастер». Как их проверять, описано в статье об адаптивном сайте.

Остальное разобрано в отдельных статьях раздела, повторять их не нужно:

Чего эти источники не говорят?

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

  • Справка Яндекса «Юзабилити сайта» не содержит развёрнутого определения и списка требований. В справках «Представление информации на сайте» и «Отличия качественного сайта от некачественного» слова «юзабилити» нет.
  • Google пишет, что хорошие результаты в отчётах не гарантируют высоких позиций, и называет шесть вопросов неполным списком.
  • Запись блога Яндекса датирована 2011 годом, текст W3C обновлён в 2016 году, текст web.dev - в 2020 году. Даты справок Яндекса не указаны.
  • Чисел о том, сколько секунд посетитель готов ждать или какая доля уходит с неудобного сайта, в разобранных источниках нет.

Источники

Дата обращения к источникам: 10.10.2026.

Обсудить проект в Telegram: t.me/billioniks

Читайте по теме

Все статьи раздела «Заказ, договор и приёмка» →