Эвристики usability, сформулированные больше 30 лет назад, неожиданно оказываются ключом к удобству современных инструментов — от IDE до AI-ассистентов. Эта статья впервые рассматривает интерфейс разработчика как предмет оценки эвристик юзабилити. Текст написан на понятном для разрабов языке и с примерами интерфейсов из разработки.
Привет, Хабр! Меня зовут Артур Савченко, я бывший директор по продукту GigaChat B2B (Сбер), сейчас занимаюсь своими проектами и GenAI-продуктами в B2B, до этого делал офисные productivity-предложениями. Уже два десятка лет создаю продукты, 15 из них руковожу дизайном. На FrontendConf 2025 я прочитал доклад из которого сделана эта статья. Если вам удобнее посмотреть видео, переходите по ссылке.
Программирование преследовало меня всю жизнь, но раньше мне не удавалось заниматься им профессионально. Теперь у меня есть два достаточно успешных pet-проекта, которые стартовали 5 лет назад, — это плагины для Figma:
Design System Organizer для менеджмента компонентов и стилей, где примерно 18 тыс. строк кода.
В этих проектах я всё делал сам: писал код (примерно 50%), консультировал, сейчас занимаюсь саппортом. Всё это время я был дизайнером, который пишет продакшен-код. Этот опыт сформировал редкую оптику: смотреть на интерфейсы одновременно глазами дизайнера и разработчика — человека, который не только проектирует, но и ежедневно взаимодействует с инструментами. Со временем я понял, что большая часть проблем у интерфейсов эвристическая. Причём эвристики связаны не с задачей, а с физиологией и особенностью взаимодействия с системой.
Что такое usability
Согласно стандарту (ISO 9241-110 / ГОСТ Р ИСО 9241-110-2016) пригодность использования — это свойство, при наличии которого пользователь может применять продукцию:
В определённых условиях использования. Для нас условия использования — это контекст, в котором находится пользователь: мышь, клавиатура, десктоп, сенсорный телефон и так далее.
Для достижения установленных целей. Обычно история про бизнес и продукт, «Больше фич богу фич», то есть когда мы улучшаем, мы разгоняемся.
С необходимой результативностью, эффективностью и удовлетворенностью. Но удовлетворённость — это субъективно.
Как раз про первый и последний пункт мы сегодня и поговорим.
Как измерять usability?
Мы в дизайн-департаменте используем очень простую метрику UMUX-lite. В ней всего два вопроса, которые оцениваются по шкале от 1 до 7:
Насколько возможности системы соответствуют моим потребностям?
Насколько система проста и удобна в использовании?
Есть более полная метрика SAS, но математически доказано, что они коррелируются, и достаточно задать пользователю всего два этих вопроса. В результате получаем пространство всех наших приложений:
По вертикали Usefulness (полнота фич), по горизонтали Ease of Use (простота использования).
Так можно понять, насколько просто использовать ваш продукт. Обычно в B2C-приложения более удобные, потому что пользователь принимает решение о смене приложения очень быстро. В B2B они чуть менее комфортны.
Что не так с интерфейсами?
При работе с инструментами разработки регулярно возникает ощущение «трения»: что-то непонятно, что-то раздражает, что-то требует лишних усилий.
Сначала кажется, что проблема в функциональности. Но при более внимательном анализе выясняется: большая часть таких проблем — не про фичи, а про удобство взаимодействия.
Система удобства: 10 эвристик usability
Эвристики впервые увидели свет в работе «Улучшение диалога человека и компьютера». В 1990 году Якоб Нильсен и Рольф Молич собрали и экспертно выделили среди всех респондентов 249 пользовательских проблем, затем переработав превратили их в 10 эвристик — базовых правил, которые помогают сделать удобный интерфейс. Они создают систему, которая описывает удобство, при этом каждая из эвристик важна по-своему, нужно в каждой достичь какого-то уровня.
Было много споров, насколько такое выделение эвристик корректно. Но позже Нильсен подтвердил исследованием, что знание эвристик проектировщиками интерфейса существенно уменьшает количество фактически выявленных проблем пользователями (об этом позже в статье).
Впоследствии Якоб Нильсен организовал популярное сообщество «Nielsen Norman Group».
Впоследствии Якоб Нильсен организовал популярное среди ux researchs сообщество «Nielsen Norman Group».
Интересно, что на практике дизайнеры знают всего 2—4 эвристики. Причём все знают одну — минимализм и эстетика. Однако именно остальные эвристики определяют реальный UX.
Кто на самом деле отвечает за интерфейсы
Согласно матрице RACI — это такой инструмент управления проектами, распределяющий роли и зоны ответственности, дизайнер — это «A», т. е. Accountable (Ответственный): лицо, принимающее финальное решение и отвечающее за результат. Но разработчик тоже ответственный, ведь он исполнитель, который непосредственно создаёт взаимодействие (то есть R — Responsible).
При этом именно разработчик:
добавляет микровзаимодействия;
решает, как работает интерфейс;
влияет на ощущение удобства.
Поэтому действительно важно, чтобы разработчики понимали систему эвристик.
Позже я узнал, что Nielsen Norman Group провели исследование и подтвердили: чем больше экспертов делают ревью макетов, зная принципы usability, тем больше они найдут проблем, которые позже будут выявлены на usability-тестах.
Отлично, если у вас будет три-пять экспертов в группе.
Просите дизайнеров делать демо заранее, на ранних стадиях, как можно показывать ваши проработки, и вместе обсуждаете дизайн решения, делая его лучше и удобнее.
Интерфейс разработчика как идеальный кейс
Среда разработки — отличный пример, где usability критичен. Здесь нет «красивых экранов» в классическом смысле, но есть:
высокая нагрузка;
сложные сценарии;
постоянное взаимодействие.
И именно здесь эвристики проявляются максимально ярко.
Управляемость: контроль, статус и ошибки
Первое, что важно в интерфейсе — ощущение контроля.
Разработчику нужно:
понимать, где он находится (курсор, файл, ветка);
видеть статус системы;
получать мгновенный отклик.
На картинке мой Visual Studio, TypeScript, Webpack, Babel и Git. Здесь мигает курсор. Это статус системы, который мне подсказывает, куда будет введён код, если я начну писать. Это очень помогает при взаимодействии, потому что показывает, где ты сейчас, твой фокус. При этом видно, что я буду сейчас коммитить в мастер, все изменения пойдут туда.
Также мне понятно, что какие-то правки уже были сделаны, и я нахожусь в функции traverseComponents при навигации.
Когда я вожу мышкой, система реагирует на моё взаимодействие. Она откликается и подсказывает, что будет дальше при взаимодействии элементом.
То же самое с курсором. Когда я переключаюсь, то вижу строку и статус, где находится курсор, мне не нужно на это обращать внимание, запоминать. Эти микровзаимодействия улучшают мой опыт на низком физическом уровне, создавая более комфортную среду для работы по сравнению с тем же PC 286.
Теперь про отзывчивость. Если я что-то меняю, то хочу, как и любой другой кодер, чтобы правки принялись быстро.
Изменения сейчас проходят у меня в плагине. Мне этой отзывчивости в 5-6 секунд достаточно. Но есть примеры, например Arduino IDE, где сборка простого проекта занимает 2 минуты, чтобы просто увидеть изменение. Я даже не смог так что-то написать.
Отзывчивость помогают измерить метрики Web Vitals, которые показывают конкретное значение. Но сами эвристики не дают конкретную цифру, они говорят — это важно обратить внимание. Мы все знаем, что метрики Web Vitals влияют на бизнес.
Ещё очень важна управляемость. К ней относится навигация и контроль, подсказки, понятные и предотвратимые ошибки. Я всё время что-то путаю, что-то случайно удаляют, делаю miss-клики.
Кнопка «Отменить" является ключом управляемости. Без undo/redo stack нельзя представить себе ни одно приложение в котором есть система редактирования.
Разработчикам также важно контролировать свои sources. Например, я поменял комп несколько раз и хотел бы в мобильной команде быстро перенастроить окружение.
Для этого я беру sources, заново настраиваю окружение, могу поменять инструменты. Это удобная навигация.
Все любят, когда ошибки понятные и текст ошибки описывает то, что на самом деле происходит.
Есть такие ошибки, которые неправильно отображаются. Если случайно не поставить закрывающую кавычку для одного метода класса, то система валит тебе красным столько ошибок, сколько методов в классе. Из-за этого я не могу найти другие ошибки в коде при проверке. Это сильно мешает работе.
Ещё есть такие ошибки, которые можно разбирать по 3-4 дня. Слава богу, добрые люди организовали проект Stack Overflow, с помощью которого можно поискать интересующую ошибку. У тех, кто пользуется Stack Overflow есть достаточно популярный плагин, где не надо переключаться между вкладками, он показывается по месту в VS Code.
Я не люблю что-то описывать. Но в сложных задачах, без TypeScript не обойтись. Один раз описал, продекларировал, и всё, с этого момента всем стало легче, ошибки показываются сразу при написании кода.
Также важно, чтобы система подсказывала, что делать дальше. На скриншоте она предлагает: «Объяви property сам, и тогда будет всё хорошо». Подсказывать в интерфейсах и вести пользователя очень круто, этому учат эвристики.
А вообще нужно стараться предотвращать ошибки заранее. Самое базовое предотвращение ошибки — это сборка webpack.
Webpack не собирается, если есть ошибки. Можно не тратить время на тестирование. Это похоже на компилируемый код. Но всё же, это хороший способ предотвратить лишние операции, которые приведут к ошибке в определенном сценарии.
Снижение нагрузки: думать меньше, делать быстрее
Любой интерфейс нагружает пользователя. Вместе с дизайнером разработчик может уменьшать нагрузку на пользователя, создавая ему комфортную среду.
Есть три типа нагрузки:
когнитивная (память и мышление);
механическая (операции, пробег мышки, действий);
визуальная (распознание элементов системы).
Хороший интерфейс показывает, а не заставляет запоминать, минимизирует количество действий и убирает лишнее.
Разберём эти принципы в интерфейсе разработчика.
Например, sticky header избавляет от необходимости запоминать контекст.
Не нужно запоминать номера строк, чтобы перейти к какой-то функции. Когда такие заголовки появились, стало проще понять, где остановиться, а где начать взаимодействие. Это уменьшает нагрузку на память и в целом на вычисления, помогает больше заниматься созданием алгоритмов и программ.
Или антипример и личная моя головная боль — менеджмент кавычек.
Ключевая проблема в том, что есть два типа кавычек, и они стоят как попало, и ты бегаешь вперёд-назад и догадываешься, какую писать. Я не говорю, что нужен один тип кавычек. Но точно управлять ими вручную - это лишняя работа. Есть интересные примеры функционального программирования, например Clojure Script, где без плагина просто физически не возможно писать код.
У нас есть быстрые действия для работы с курсором, которые снижают механическую нагрузку
Когда я выучил эти горячие комбинации, написание программ сильно ускорилось. Я начал быстрее взаимодействовать, быстрее двигаться вперёд, по сравнению с тем, когда я кликал в текст, как дизайнер.
Минимализм и эстетика: эффективность разработки за счёт эвристик
Минимализм в программировании нужен, чтобы выделить главное. Вот как это проявляется в коде:
через подсветку синтаксиса;
визуальные акценты;
отсутствие лишних элементов.
Для примера рассмотрим простую функцию deep clone. Если убрать подсветку кода, то строки сливаются.
А если подсветить, то становится проще видеть элементы с разделением по типу. Мы уменьшаем количество элементов благодаря расцветке кода. Фиолетовым подсвечены главные операторы, а все остальные элементы другого цвета. Так значительно комфортнее работать, взаимодействие лучше.
Ещё минимализм — это, конечно, отсутствие копипастов в одном проекте. Клоны веток — это лишние источники правды.
Также по эвристикам в интерфейсе не должно быть ничего лишнего. Я, например, убираю все лишние панели. Благодаря этому могу сконцентрироваться на алгоритме.
Давайте поговорим про эстетику. Это, конечно, дело вкуса. Лично для меня эстетика в коде — это декларативно, реактивно и иммутабельно.
Здесь конечно не реактивно и не иммутабельно, но зато декларативно. Я писал бота для Telegram и написал по быстрому свой мини-фреймворк с "коллбэками", где смог вставлять if прямо в сценарную логику. Мне так нравится. Но повторюсь, о вкусах не спорят.
Опыт, стандарты и обучение
Когда я писал статью, то первое время долго не мог найти пример для эвристики соответствия миру пользователя. Этот принцип говорит, что важно переиспользовать предыдущий опыт, сохранить его, чтобы для пользователя не было чего-то совсем нового.
На картинке обратная история — современный контроллер, который объединяет физический и цифровой мир. Для современных детей - это уже базовый опыт с детства, думаю вскоре мы увидим больше таких фических устройств, потому что они будут понятны пользователю.
В школе нас научили читать и писать, текст — это то, что формирует наш мир. Текст даёт нам быстрый старт и вход в написание программ. Именно поэтому код — это текст. Не так давно появились и другие подходы к программированию: no-code и low-code, которые опираются на интерфейс. Они могли бы быть новой формой взаимодействия, но у них есть проблема — нельзя описать всё что угодно, а это не выполняет задачу.
Прямо сейчас естественный язык описания логики стал для LLM инструментом написания кода. Думаю - это и есть новая форма и эволюция no-code и low-code инструментов. Но в это статье не об этом.
Для уменьшения нагрузки нужно следовать принципам:
унификация — одинаковые действия работают одинаково;
стандарты — код и интерфейс предсказуемы;
документация — лучше встроенная, чем отдельная.
Разработчик хочет, чтобы hot key по работе с выделением по словам работал одинаково во всех типах полей (например в тексте кода, поиске, input are и т.д). Это называется унификация опыта. Пользователи, которые работают в Vim, привыкли к какому-то типу взаимодействия, к определённым комбинациям, они хотят, чтобы Vim потом был везде — в консоли или браузере, где угодно.
Стандартизация появляется, когда я пишу константы капсом, бизнес-логику snake_case, компоненты React PascalCase и функции с маленькой буквы. Это реально помогает ориентироваться просто даже внутри моего кода.
Представьте, что стандартизация — это неважно, можно писать в как угодно. В этот момент можно легко завалить релиз, кто-то может не понять код, кто-то будет ругаться, будет тяжело. Это и есть как раз те самые базовые эвристики, которые влияют на конечный результат.
Документация по программе очень важна. Я обожаю с какой любовью разработчики создают документацию по своим библиотекам. Но эвристики говорят нам, что ещё лучше, когда документация по месту. На скриншоте ниже подключён файл figma_typeing, и figma API подсвечивается.
В сценариях конкретного взаимодействия не нужно вспоминать и тратить на это дополнительное время.
Ещё документация должна подсвечивать реальные проблемы, которые могут возникнуть в будущем.
Вот показательный кейс. Я написал код с помощью forEach, но потом Figma перевела всё на DynamicPage и асинхронные вызовы, и мне пришлось переписывать и дебажить огромное количество кода. Было бы хорошо, если бы мне заранее сказали: «Эй, чувак, у тебя будут проблемы!».
Кроме этого, хорошо, если интерфейс обучает по ходу работы. И здесь разработчики могут влиять на продуктовое решение. Именно они создают программы и могут предложить сделать в каком-то месте онбординг, обучить, что-то подсказать пользователю, показать документацию, предотвратить ошибки.
Закрепим все эвристики, о которых рассказывает статья.
Управляемость.
Понятный статус системы и отзывчивость, то есть скорость, с которой система реагирует, и статус.
Контроль и свобода. Я хотел бы иметь возможность прервать любой процесс и вообще контролировать саму систему в тех местах, где мне нужно это знать.
Понятные ошибки и восстановление после них.
Предотвращение ошибок пользователя.
Нагрузка.
Мы хотим уменьшить нагрузку на память, видеть, а не вспоминать.
Гибкость и эффективность. У нас бывает сложное взаимодействие, оно должно быть понятно визуально, но могут быть и горячие клавиши, которые созданы для уже более экспертных пользователей, профессионалов.
Минимализм и эстетика. Важно определить, что главное для задачи. У тебя возникает бизнес-задача, надо понять, что в ключевом сценарии, и показывать главные вещи и не показывать менее главные. Это на самом деле очень сложно.
Опыт и обучение.
Соответствие системы миру пользователя. Важно учитывать предыдущий опыт пользования пользователя, например, локальный. Если ты выходишь на Китай, нужно поресечить, изучить, что там происходит, и делать интерфейс под этот рынок.
Единые принципы и стандарты важно использовать при переходе пользователя, как минимум, в своей экосистеме.
Онбординг и документация. Самая классная документация — это документация по месту.
Как легко запомнить все эвристики
Это легко увидеть на одном примере плана эвакуации.
Управляемость.
Я нахожусь в левом нижнем углу. Где-то есть огнетушитель. Горит лампочка, что случился пожар. Если лампочка загорелась вовремя, я не сгорел, всё хорошо.
Я могу зайти в любую комнату и понять, где пожар. Это контроль и свобода.
Если я забегаю в тупик, мне говорят: «Тут тупик, при пожаре лучше сюда не бежать». Это понятные ошибки.
На плане эвакуации пытаются предотвратить мои ошибки. В лифт идти нельзя это опасно, нужно идти по лестнице.
Нагрузка.
Мне не нужно помнить план эвакуации, он продублирован в разных местах.
На каждом дубликате показаны новые шоткаты, я понимаю, куда мне нужно бежать, чтобы спастись.
План в целом достаточно минималистичен, тут ничего лишнего. Бывают разные планы, но если план не минималистичный, это плохо. В примере достаточно минималистичный.
Опыт и обучение.
Здесь все иконки соответствуют моему предыдущему опыту. Я понимаю, что такое огнетушитель, вроде более-менее понимаю, куда надо бежать. Все вроде понятно, с детства меня этому учили и этот опыт я сохраняю.
Есть единые принципы стандарта, СНиПы по пожарной безопасности. Они требуют использовать одинаковые значки, чтобы никто не запутался, чтобы все понимали, как будет происходить взаимодействие.
Хороший пример онбординга — это инструктаж от стюардессы перед взлётом. В самолете каждый раз показывают, где выход. Для каждого места есть документация, где дублируется информация, озвученная экипажем.
Важность
Эвристики — это не про «удобство ради удобства». Это инструмент конкуренции, который действительно важен и полезен для бизнеса:
Бесконечная плоскость для конкуренции
iPhone — 2007 ( HIG, touch zone 44x44, скевоморфизм, минимализм/эстетика, новые формы взаимодействия c аналогичной функциональностью)
Сursor, Windsurf — 2023, Claude Code/Codex — 2026 (уменьшение механической и когнитивной нагрузки)Блокировка выпуска релизов
В МойОфис мы не готовый были выпустить МойСинхронизатор так как 7 из 7 респондентов отметили непонятный статус загрузки конкретного файла во время исследования.Не выполнение эвристик может быть риском для жизни пользователя и повредить имущество
На видео выше электрический Ford в котором заблокирован руль вправо и зажата педаль газа. У пользователя нет кнопки terminate, чтобы остановить работу системы.
