Как провести эвристическую оценку: практическое руководство с AI-промптами

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

Эвристическая оценка (heuristic evaluation) — это экспертный метод инспекции, в котором 3–5 подготовленных оценщиков независимо проходят интерфейс и судят его по фиксированному набору принципов юзабилити, чаще всего по 10 эвристикам Якоба Нильсена. Каждый оценщик записывает все обнаруженные нарушения, привязывает их к конкретной эвристике, выставляет severity, и команда сводит индивидуальные списки в один приоритизированный бэклог проблем. Эвристическая оценка — самый дешёвый и быстрый способ поднять системные проблемы юзабилити в продукте до того, как деньги уйдут на разработку или формальное юзабилити-тестирование. Полный проход с тремя оценщиками по сфокусированному флоу занимает один-три дня и надёжно ловит около 75% проблем, которые иначе всплыли бы позже на юзабилити-тестах.

На какой вопрос отвечает метод?

Где этот интерфейс нарушает известные принципы юзабилити и какие нарушения самые серьёзные?
На каких экранах или флоу больше всего сконцентрированных проблем юзабилити, а какие можно отгружать как есть?
Какие очевидные проблемы стоит починить до запуска дорогого юзабилити-теста, чтобы тестовые сессии шли на реальные вопросы, а не ловили очевидные баги?
Какие дизайн-решения противоречат отраслевым конвенциям так, что мы потеряем learnability для новых пользователей?
Какие паттерны UX-долга повторяются по продукту (плохой фидбэк, отсутствие предотвращения ошибок, несогласованная терминология) и заслуживают системного фикса вместо разовой заплатки?
Для существующего живого продукта — где находятся места с самым высоким импактом для дизайн-инвестиций при ограниченном инженерном бюджете?

Когда использовать эвристическую оценку

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

Метод не подходит, когда вопрос про глубинное «почему» за поведением пользователя, его мотивацию или нераскрытые потребности — эвристическая оценка находит только нарушения известных принципов, а не новые категории проблем, не покрытые эвристиками. Метод также пропускает проблемы, зависящие от конкретной ментальной модели реальной группы пользователей (специализированная терминология, доменные воркфлоу, доступность, не покрытая эвристиками). Эвристическая оценка — это дополнение к юзабилити-тестированию, а не его замена; команды, которые отгружают продукт на одной эвристической оценке, стабильно пропускают сбои, всплывающие только когда живые пользователи пытаются выполнить реальные задачи. Наконец, это не аудит доступности или качества контента — для них нужны свои отдельные проверки (WCAG-аудит, контент-ревью).

Что получаешь на выходе (артефакты)

Workbook эвристической оценки: структурированный документ на каждого оценщика, где каждое наблюдение привязано к нарушенной эвристике, экрану или флоу, и содержит рекомендованный фикс.
Сводный список проблем: объединённый вывод всех оценщиков, дубликаты убраны, противоречия обсуждены, каждой проблеме присвоен финальный severity-рейтинг.
Бэклог с severity-рейтингами: каждая проблема оценена по стандартной шкале (обычно cosmetic / minor / major / critical, или 0–4 шкала Нильсена), чтобы команда могла приоритизировать фиксы под доступную инженерную мощность.
Кластерная карта: проблемы сгруппированы по темам (навигация, фидбэк, терминология, ошибки, формы), чтобы системные проблемы стали видны вместо плоского списка разовых багов.
Аннотированные скриншоты: каждая крупная проблема проиллюстрирована соответствующим экраном с выноской на нарушение, чтобы инженеры и PM видели то, что видел оценщик.
Action plan: топ-5–15 проблем, приоритизированных по severity, частоте и бизнес-импакту, с конкретными рекомендованными фиксами и грубой оценкой усилий.
Readout-дека или бриф: документ на 5–10 страниц или короткая презентация, которая проводит стейкхолдеров через метод, ключевые проблемы и рекомендованные следующие шаги.

Участники и сроки

Участники: напрямую нет — эвристическая оценка это экспертная инспекция. «Участники» — это 3–5 подготовленных оценщиков, которые независимо проходят интерфейс.
Оценщики: 1 оценщик ловит около 35% проблем юзабилити, 3 оценщика — около 60%, 5 оценщиков — около 75% (Nielsen 1994). Три — самая частая оптимальная точка для продуктовых команд.
Время на сетап: 0,5–1 день на определение scope, бриф оценщиков по эвристикам, подготовку скриншотов или доступа к тесту, выбор инструмента логирования.
Независимая оценка: 2–4 часа на оценщика для сфокусированного флоу, больше для сложного продукта. Каждый оценщик работает один, не видя находок других.
Консолидация: от полудня до полного дня, чтобы свести находки, обсудить расхождения, откалибровать severity и собрать проблемы в кластеры.
Синтез и написание: 0,5–1 день на бриф, аннотированные скриншоты и приоритизированный action plan.
Общее wall-clock время: 1–3 дня от старта до финала на типичный продуктовый флоу с тремя оценщиками.

Как провести эвристическую оценку (пошагово)

1. Определи scope и группу пользователей

Реши, какую часть продукта будешь оценивать, до того как брифовать оценщиков. Возьми 1–3 критичных пользовательских флоу, которые мапятся на ценные задачи (онбординг, чекаут, основной job-to-be-done), а не пытайся покрыть весь продукт. Явно укажи, какие экраны, состояния, устройства и типы пользователей внутри scope, а какие — вне. Узкий scope даёт конкретные действенные находки; широкий scope даёт расплывчатый отчёт, насыщенный мнениями. Зафиксируй, какой тип пользователя должны принять оценщики — новичок, который пробует продукт впервые, и power user, который проходит рутинную задачу, заметят совершенно разные проблемы.

2. Выбери набор эвристик и проведи бриф оценщикам

Для большинства продуктовых команд правильная отправная точка — 10 эвристик юзабилити Якоба Нильсена, потому что они хорошо документированы, широко применимы и мгновенно узнаваемы каждым, кто работал в UX. Для специализированных доменов добавь сверху доменный набор — Bastien & Scapin для эргономической глубины, Gerhardt-Powals для когнитивной инженерии, WCAG quick reference для доступности. Брифуй каждого оценщика по выбранному набору перед началом. Если команда никогда не проводила эвристическую оценку вместе, проведи 30-минутный разогрев на стороннем продукте (приложение погоды, маленький SaaS-лендинг), чтобы все откалибровались на том, что считается нарушением.

3. Реши, как логировать находки

Выбери один общий шаблон и потребуй от каждого оценщика им пользоваться. Стандартный формат — строка на наблюдение со столбцами: экран или флоу, что ломается, нарушенная эвристика, severity, рекомендованный фикс. Избегай свободных инструментов вроде комментариев в Figma или стикеров — они превращают консолидацию в кошмар. Общая таблица (Google Sheets, Airtable) подходит для большинства проектов; для визуальных оценок подойдут бесплатный workbook-PDF NN/g или Miro-доска с одним workspace на оценщика. Какой бы инструмент ни был выбран, каждый оценщик должен сначала логировать находки приватно; шаринг во время независимого прохода смещает всю оценку.

4. Пройди интерфейс дважды

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

5. Логируй каждое наблюдение как структурированную проблему

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

6. Оцени severity по фиксированной шкале

После независимой оценки, но до консолидации, каждый оценщик присваивает каждой проблеме оценку по одной и той же шкале severity. Самая распространённая — 4-балльная: cosmetic (визуальный полиш, нет влияния на задачу), minor (заметное трение, но задача выполняется), major (значительное трение, вероятно вызывает ошибки или колебания), critical (блокирует выполнение задачи или вызывает необратимые ошибки). Оригинальная 0–4 шкала Нильсена (no problem, cosmetic, minor, major, catastrophe) работает не хуже. Правило простое: если проблема блокирует кому-то выполнение работы — это critical; если просто раздражает — это minor или cosmetic. Согласованный severity — это то, что делает сводный бэклог действенным.

7. Сведи и объедини списки

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

8. Сгруппируй проблемы в темы

Сгруппируй сводные проблемы в 3–7 тематических кластеров: навигация и информационная архитектура, фидбэк и состояние системы, предотвращение ошибок и восстановление, терминология и контент, формы и инпуты, визуальный дизайн и иерархия, доступность. Кластеризация превращает 30–60 индивидуальных проблем в горстку headline-паттернов, которые стейкхолдеры могут удержать в голове и на которые могут действовать. Команда, которая выйдет с readout-встречи, помня «у нас проблема с фидбэком и проблема с навигацией», отгрузит лучшие фиксы, чем команда, получившая в руки таблицу из 47 строк.

9. Приоритизируй и напиши action plan

Оцени каждый кластер (или каждую проблему, если список короткий) по трём измерениям: severity (насколько сильно бьёт по пользователю), частота (как часто пользователи на это натыкаются), бизнес-импакт (насколько влияет на активацию, удержание, конверсию или стоимость поддержки). Сложи оценки или используй простую матрицу high/medium/low. Возьми топ-5–15 пунктов в следующий спринт. Заверши конкретными рекомендованными фиксами и грубой оценкой усилий; бриф, который отгружает только диагнозы без рекомендаций, продуктовым командам гораздо сложнее взять в работу.

10. Напиши бриф и презентуй стейкхолдерам

Сделай бриф на 5–10 страниц или короткую деку, открывающуюся scope и методом, на первой странице суммируй ключевые находки, потом пройдись по каждой основной теме с аннотированными скриншотами и цитатами оценщиков, заверши приоритизированным action plan. Презентуй продуктовому, дизайн- и инженерному лидам лично, а не отсылай документ по почте; обсуждение на readout — это место, где стейкхолдеры калибруют severity, договариваются о приоритетах и берут фиксы в работу. Полный бэклог и сводную таблицу оставь приложенными как референс для команды, которая фактически будет имплементировать изменения.

Как AI меняет эвристическую оценку

AI compatibility: partial (частично). Современные мультимодальные LLM могут читать скриншоты и проводить достоверный первый проход по 10 эвристикам Нильсена, но недавние peer-reviewed исследования (Zhong, McDonald, Hsieh 2025; Vasiu et al. 2026) показывают, что AI-оценщики ловят другой и частично пересекающийся набор проблем по сравнению с человеческими экспертами, с заметными слепыми зонами на контекстно-зависимых проблемах. Реалистичный сплит — AI берёт на себя рутинные поверхностные проверки (loading-состояния, лейблы кнопок, ошибки форм, контраст цветов, ясность копирайтинга), а люди принимают решения про scope, бизнес-контекст, severity и проблемы, зависящие от реальной ментальной модели пользователя.

Что AI умеет

Провести первый проход по скриншотам: Мультимодальные модели типа Claude, GPT-4o и Gemini могут взять набор скриншотов, пройти каждый и выдать структурированный список кандидатских нарушений по 10 эвристикам Нильсена за минуты. Обычно это около 50–70% полноты по сравнению с человеком-экспертом на рутинных флоу — полезная отправная точка для оценщика-человека.
Сгенерировать чек-лист эвристик под конкретный флоу: По описанию флоу и целевого пользователя LLM может выдать кастомный набор yes/no вопросов на каждую из 10 эвристик, заточенный под конкретные экраны. Это сжимает подготовку для человеческой команды с нескольких часов до нескольких минут.
Тегать и сводить находки разных оценщиков: Когда несколько оценщиков сдают свободные текстовые наблюдения, LLM может прочитать сырые списки, дедуплицировать похожие проблемы, предложить имена кластеров и подготовить сводный бэклог с severity-рейтингами — работа, которая раньше занимала полдня встреч консолидации.
Согласованно оценивать severity: Дрейф калибровки между оценщиками-людьми — хроническая проблема. LLM, применяющий фиксированный severity-рубрик к каждой проблеме, выдаёт согласованные защитимые оценки, которые человек потом может переопределить кейс за кейсом, а не оценивать с нуля.
Кросс-чекать находки против доступности (WCAG) одновременно: Модель может применять эвристики Нильсена и критерии WCAG 2.2 в одном проходе, помечая проблемы, нарушающие оба, и выдавая комбинированный score риска. Инструменты типа Heurilens, Stark AI и Figma-плагины эвристической оценки автоматизируют этот кросс-чек.
Сделать драфт readout-брифа: По сводному списку проблем LLM может выдать первый драфт брифа, организованного по темам, с headline-находками, аннотированными примерами и рекомендованными фиксами. Исследователь-человек потом переписывает его под голос команды и заостряет приоритизацию.

Что требует исследователя-человека

Определение scope и пользовательской перспективы: AI с радостью прогонит оценку по любому флоу, на который ему укажешь, но решение, какие флоу важнее всего, какой тип пользователя принять и что оставить за кадром — это продуктовое суждение, зависящее от знания бизнеса. Ошибись здесь — и находки AI будут точными, но бесполезными.
Поимка контекстно-зависимых нарушений: AI стабильно пропускает проблемы, где нарушение зависит от ментальной модели пользователя, окружающего воркфлоу или доменных конвенций, которых модель никогда не видела. Специализированные B2B-инструменты, регулируемые индустрии и культурно специфичные флоу — самые сложные слепые зоны.
Калибровка severity под бизнес-реальность: Модель может оценить severity по обобщённой рубрике, но знание, что «колебания на странице биллинга» — это критический сигнал churn в этой конкретной компании, а «несогласованность в settings» — это cosmetic, требует знания бизнес-модели и клиентской базы продукта.
Различение реальных нарушений и намеренных дизайн-компромиссов: Гамбургер-меню нарушают «recognition rather than recall», но это правильное решение на мобильных. AI-оценщики стабильно помечают их как реальные проблемы; человек знает, когда нужно защитить компромисс. Без этого фильтра отчёт AI становится шумом.
Обсуждение консолидации: Ценность нескольких оценщиков идёт от встречи, где они сводят свои списки, а не от самих списков. AI может дедуплицировать и кластеризовать, но разговор, где «проблема навигации» одного оценщика оказывается «проблемой предотвращения ошибок» другого, — это место, где появляются headline-находки.

AI-усиленный workflow

До AI эвристическая оценка сфокусированного флоу с тремя оценщиками занимала 2–3 дня от начала до конца: полдня на подготовку, четыре часа на оценщика в независимой работе, полдня на консолидацию и выставление severity, полдня на бриф. Узкое место — независимый проход оценки: три толковых дизайнера, каждый проходит одни и те же экраны и записывает одни и те же рутинные проблемы.

С AI в workflow тот же проект сжимается до одного-двух дней. Лид-исследователь тратит час на формулировку scope и типа пользователя, потом скармливает скриншоты каждого экрана мультимодальной модели с кастомным промптом, который проходит по 10 эвристикам Нильсена. Модель за минуты возвращает структурированный список кандидатских проблем на экран. Двое оценщиков-людей берут этот первый проход как отправную точку, сами проходят те же флоу, чтобы подтвердить, расширить, переопределить и добавить контекстно-зависимые проблемы, которые модель упустила. Оценщики тратят время на суждение, а не на повторяющиеся механические проверки. Консолидация идёт быстрее, потому что у проблем уже общая структура и словарь; калибровка severity идёт быстрее, потому что модель уже предварительно оценила всё по одной рубрике. Бриф получает первый драфт от модели и финальный проход от исследователя-человека.

Подвох тот же, что и в AI-ассистированном desk research: сэкономленное время зависит от настоящего человеческого прохода верификации над выводом AI. Исследования, измерявшие AI-only эвристические оценки против human-only, нашли false positives (модель помечала проблемы, которых не было), false negatives (модель пропускала проблемы, которые имели значение) и склонность переоценивать визуальные мелочи, недооценивая контекстно-зависимые проблемы. Исследователи, получающие максимум ценности от AI здесь, относятся к нему как к тщательному, но наивному джуниор-оценщику: полезен для первого прохода, никогда не считается финальным ответом, всегда в паре с человеком, знающим продукт.

Инструменты

Workbook’и и шаблоны эвристической оценки: бесплатный workbook-PDF от NN/g, шаблон Maze, форма UX heuristic evaluation от Eleken, Figma-плагин эвристической оценки, CSIR-шаблоны промптов от AIPrm.

Логирование в таблицах и документах: Google Sheets, Airtable, базы Notion — стандартный формат для логирования проблем со строкой на наблюдение и согласованными столбцами.

Визуальные workspace и консолидация: Miro, Mural, FigJam — полезны на фазе консолидации, когда команда кластеризует стикеры по темам; создавай один workspace на оценщика до встречи консолидации.

AI-ассистированная эвристическая оценка: Claude, GPT-4o, Gemini для оценки первого прохода по скриншотам; Heurilens для автоматизированной оценки против эвристик Нильсена; специализированные GPT, обученные на эвристиках Нильсена; AI-компоненты Lookback, Marvin и Dovetail для синтеза вывода нескольких оценщиков.

Кросс-чек доступности: WAVE, axe DevTools, Stark для Figma, Lighthouse и расширение Microsoft Accessibility Insights — пара к эвристической оценке, когда доступность в scope.

Инструменты аннотированных скриншотов: CleanShot X, Snagit, Loom (для видео-walkthrough), Markup.io, Shottr — используются для прикрепления визуальных доказательств, которые нужны каждой проблеме в readout.

С чем хорошо сочетается

Usability Testing Moderated (Ut) — Модерируемое юзабилити-тестирование: Эвристическая оценка — каноническая прелюдия к модерируемому юзабилити-тестированию. Сначала эвристическая оценка чистит очевидные проблемы, потом юзабилити-тест фокусируется на вопросах, на которые могут ответить только живые пользователи. Nielsen Norman Group документирует эту пару тридцать лет.
Cognitive Walkthrough (Cw) — Когнитивный walkthrough: Оба метода — экспертные инспекции, но задают разные вопросы: эвристическая оценка проверяет дизайн против принципов, когнитивный walkthrough проверяет, может ли пользователь-новичок понять следующий шаг на каждом экране. Прогон вместе даёт более полную картину для ранних этапов дизайна.
Accessibility Testing (At) — Тестирование доступности: Эвристическая оценка и тестирование доступности обе инспектируют интерфейс на соответствие правилам; парный прогон в одном проходе ловит проблемы, нарушающие и эвристики Нильсена, и WCAG, и выдаёт один общий бэклог вместо двух.
Контент-анализ: Когда эвристическая оценка поднимает кластер «контент и терминология», следующим шагом запускай контент-анализ реального пользовательского фидбэка (тикеты поддержки, отзывы), чтобы подтвердить, действительно ли проблемы терминологии, помеченные оценщиками, спотыкают живых пользователей.
Survey (Sv) — Опрос: Короткий пост-task опрос (например, SUS или SUPR-Q) на живых пользователях дополняет эвристическую оценку, квантифицируя воспринимаемую severity проблем со стороны пользователя. Вместе они дают гораздо более убедительный бизнес-кейс, чем по отдельности.

Пример из практики

B2B SaaS-компания выкатила новый дашборд цен и биллинга для своих enterprise-клиентов и через две недели после запуска увидела всплеск тикетов поддержки на 30% с жалобой «не могу найти инвойс». Продакт-менеджер хотел понять причину до того, как авторизовать редизайн, и имел недельный бюджет. Юзабилити-тест занял бы три недели с учётом рекрутинга, а команде поддержки нужен был ответ быстрее.

Лид-исследователь провела эвристическую оценку за три дня. Она определила scope как «enterprise-админы, пытающиеся найти и скачать свои инвойсы за последние три месяца», взяла 10 эвристик Нильсена плюс быстрый WCAG 2.2 проход и привлекла двух дизайнеров из соседних команд как второго и третьего оценщика. Каждый оценщик прошёл флоу дважды (часовой ориентационный проход плюс двухчасовой оценочный) и логировал находки в общую Google Sheet в строгом формате: экран, элемент, эвристика, что ломается, severity, рекомендованный фикс. Она также скормила скриншоты в Claude с кастомным промптом, который провёл первый проход по тем же эвристикам, и затем использовала вывод модели как четвёртого «джуниор-оценщика» — приняв одни находки и переопределив другие там, где Claude неверно прочитал контекст.

Консолидация заняла полдня и подняла 38 проблем в шести темах. Headline-находка была однозначной: редизайн перенёс скачивание инвойса с primary-действия на лендинг-странице биллинга в трёхкликовый под-флоу внутри вкладки «История аккаунта», что нарушало эвристики #6 (recognition rather than recall) и #7 (flexibility and efficiency of use) и объясняло почти все тикеты поддержки. Главная рекомендация — вынести кнопку «Скачать последний инвойс» на лендинг-страницу биллинга; инженерные затраты оценили в полспринта. Фикс выкатили через две недели, тикеты поддержки за неделю после релиза вернулись к baseline, а эвристическая оценка стоила примерно 18 часов исследовательского времени по команде — против 60+ часов, которые занял бы сравнимый юзабилити-тест.

Ошибки начинающих

Пропуск независимого прохода

Самая большая отдельная failure-точка — позволить оценщикам видеть находки друг друга до завершения независимого walkthrough. Вся статистическая база использования 3–5 оценщиков в том, что каждый ловит свой подмножество проблем; если они синхронизируются рано, ты сжимаешь три перспективы в одну, и покрытие падает примерно до того, что поймал бы один оценщик. Всегда проводи независимый проход в приватных блокнотах или отдельных листах и шарь списки только на встрече консолидации.

Логирование мнений вместо наблюдений

Заметки типа «это сбивает с толку» или «вёрстка какая-то мутная» бесполезны в сводном бэклоге, потому что на них никто не может действовать. Каждая проблема должна включать конкретный элемент, наблюдаемое поведение, нарушенную эвристику и конкретный рекомендованный фикс. Дисциплина писать «кнопка Submit остаётся серой без сообщения об ошибке, когда поле email пустое (#9 — error recovery)» вместо «форма какая-то багнутая» — это то, что отделяет эвристическую оценку, которая ведёт к фиксам, от той, которую игнорируют.

Отношение к каждому нарушению эвристики как к реальной проблеме

Эвристики — это руководящие принципы, а не законы. Гамбургер-меню нарушают «recognition rather than recall», но это правильное решение для большинства мобильных дизайнов. Confirm-модалы нарушают «user control and freedom», но они необходимы для необратимых действий. Эвристический оценщик, который помечает каждое учебное нарушение, не проверяя, является ли компромисс намеренным, выдаёт шумный отчёт, теряющий доверие дизайн-команды. Всегда проверяй намерение дизайна до того, как залогировать нарушение как реальную проблему.

Размытая или несогласованная шкала severity

Severity — это рычаг, который превращает 38 проблем в список из 5 вещей, которые нужно починить в этом спринте. Если двое оценщиков работают с разными ментальными моделями «minor» и «major», сводный бэклог бессмыслен. Возьми одну явную шкалу (4-балльную cosmetic/minor/major/critical или 0–4 шкалу Нильсена), определи каждый уровень одним предложением-тестом («блокирует ли выполнение задачи?»), и перекалибровывай на встрече консолидации каждый раз, когда оценщики расходятся.

Пропуск шага приоритизации

Эвристическая оценка, заканчивающаяся таблицей в 47 строк без action plan, редко приводит хоть к какому-то фиксу. Команда получает документ, прокручивает его один раз и возвращается к существующему roadmap. Всегда заканчивай проект явным топ-5–15 приоритизированным списком, оценённым по severity, частоте и бизнес-импакту, и презентуй его лично, а не отсылай таблицу. Разговор на readout — это место, где фиксы берут в работу.

AI-промпты для этого метода

4 готовых AI-промптов с placeholder’ами — скопируйте и подставьте свой контекст. Все промпты для «эвристической оценки» →.