Запись эвристической оценки: как отделить находку, серьёзность и решение
После эвристической оценки сводите запись в карточки находок. В каждой оставьте версию экрана, шаги воспроизведения и принцип, который нарушен. Серьёзность укажите с обоснованием, а решение команды запишите отдельно. Так другой специалист сможет проверить проблему даже без встречи.
Что в записи говорит эксперт, а что показывает интерфейс
На разборе звучит: «Сохранение незаметно, люди будут нажимать снова». В одной фразе уже две записи для отчёта. Отсутствие видимого подтверждения можно перепроверить по экрану. Повторное нажатие реального пользователя — пока предположение. Если сохранить только цитату, разработчик не поймёт, какой экран открыть и что должно измениться.
При эвристической оценке специалисты сверяют интерфейс с принципами удобства. Экспертная находка может подсказать направление проверки, но сама по себе не показывает, сколько людей столкнутся с затруднением. Если у вас уже есть наблюдения за участниками, заведите отдельный отчёт по юзабилити-тестированию и свяжите с ним карточку экспертизы.
Порядок работы с записью
Соберите независимые записи до обсуждения
Дайте экспертам один объём проверки: версию, роль, устройство и список сценариев. Пусть каждый сначала составит свой список. После этого объединяйте материалы на встрече. Иначе первый комментарий может стать подсказкой, а в протоколе будет трудно отличить независимо замеченные проблемы.
Сделайте замечание воспроизводимым
Одна карточка — одно наблюдаемое поведение интерфейса. Запишите путь к экрану, действие, состояние до и после, таймкод и критерий проверки. Для замечания о сохранении укажите, был ли ответ системы получен и как это установлено. Одного слова «зависло» недостаточно.
Объединяйте совпадения по сценарию
Если двое описали один экран и один эффект, оставьте общий ID находки и ссылки на обе исходные записи. Если на другом экране подтверждение отсутствует по другой причине, сохраните отдельную карточку. Общая эвристика ещё не делает проблемы дублями.
Сохраните обоснование серьёзности
Договоритесь о шкале и попросите оценщиков назвать ожидаемую частоту ситуации, последствия и повторяемость проблемы. Не записывайте их оценки как измеренную частоту. Если один специалист считает затруднение краткой паузой, а другой ожидает потерю данных, сохраните разные предпосылки и решите, как их проверить.
Запишите решение после оценки
Серьёзность относится к последствиям проблемы. Очерёдность работ зависит также от стоимости, зависимостей и версии продукта. Запишите, что команда решила сделать, кто проверит результат и какое поведение в новой версии будет считаться улучшением.
Учебный пример: настройки сохранились без подтверждения
Вымышленный кабинет, сборка V4, экран S4. В 06:24 эксперт нажал «Сохранить». После повторного открытия формы изменения остались, но сразу после нажатия на экране не появилось видимого сообщения об успехе. Это находка E07 по принципу видимости состояния системы.
Две оценки, одна находка
Эксперт А предположил небольшую паузу: изменения можно проверить в самой форме. Эксперт Б оценил риск выше: человек может решить, что запрос не прошёл, и повторить действие. В записи нет пользовательской сессии, поэтому обе оценки остаются экспертными суждениями.
В 17:52 команда выбрала макет сообщения об успехе. Сначала нужно проверить, что сообщение показывается только после успешного сохранения, а при ошибке остаётся понятный способ повторить действие. Затем можно дать пользователям сценарий и посмотреть, понимают ли они, когда работа завершена.
| Слой карточки | Что записать для E07 | Чем подтвердить |
|---|---|---|
| Наблюдение | После «Сохранить» нет видимого статуса | V4 · S4 · видео 06:24 |
| Эвристика | Видимость состояния системы | Отсутствует обратная связь о результате |
| Серьёзность | А: средняя; Б: высокая, ожидает повтор | Два обоснования сохранены раздельно |
| Решение | Макет подтверждения, затем повторный сценарий | Обсуждение 17:52; эффект ещё не проверен |
Карточка находки для экспертного разбора
Скопируйте заготовку в рабочий документ. Заполняйте её по конкретному фрагменту; неизвестное оставляйте неизвестным.
ID и краткое название: Сборка / роль / устройство / экран: Исходное состояние и шаги: Что видно после действия: Принцип и основание: Запись экрана / таймкод: Исходные заметки и оценки экспертов: Ожидаемые последствия, которые ещё не проверены: Решение / ответственный / критерий проверки:
Что проверить перед передачей карточки в работу
Дайте повторить шаги. Попросите коллегу открыть указанную сборку и пройти сценарий по карточке. Если он видит подтверждение, выясните, отличаются ли роль, состояние формы или устройство. Сохраните расхождение, пока оно не объяснено.
Разделите речь и экран. Фраза «не сохранилось» может описывать впечатление эксперта. Проверьте результат отдельно и поставьте таймкод на видимое действие. Если видео и аудио начались в разные моменты, подпишите источник каждой отметки.
Не закрывайте находку по обещанию. «Добавим сообщение» — решение встречи. Статус «исправлено» ставьте после проверки новой сборки по заранее записанному критерию.
Где полезен Транскрибатор
Получите текст согласованного экспертного обсуждения с таймкодами. По нему можно найти основание каждой оценки и момент решения. Состояние экрана и успешность действия сверяйте по видео или повторному прохождению сценария.
Разберём детали
Можно ли использовать эвристическую оценку вместо теста с пользователями?
Она помогает найти предполагаемые проблемы на раннем этапе. Для ответа на вопрос, что реально делают пользователи, нужны наблюдения за их действиями или другие подходящие данные.
Что делать, если эксперты назвали разные эвристики?
Сохраните наблюдение один раз и укажите оба обоснования. Для карточки выберите наиболее понятную связь с поведением интерфейса. Дополнительные принципы оставьте рядом, если они помогают понять проблему.
Нужно ли усреднять оценки серьёзности?
Следуйте принятому протоколу. Если разница объясняется разными условиями, одного среднего мало: запишите предпосылки и проверьте, при каких условиях возникает более тяжёлое последствие.