Атрибут
Reliability

Атрибут Reliability в пользовательском фреймворке “Думать как пользователь” означает, что продукт или функция не просто формально существует (Functionality), а полноценно решает задачу пользователя от начала до конца. Другими словами, продукт “надежен” в смысле выполнения всей Job Story пользователя: он покрывает всю потребность, а не просто отдельные шаги.

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

Чтобы проработать атрибут Reliability, стоит придерживаться последовательности из нескольких шагов. В целом, процесс проверки состоит из подготовки и проведения Solution Interview (решенческое интевью) с пользователями, а затем анализа результатов. Ключевые этапы:

Далее рассмотрим каждый шаг подробно, с акцентом на практические детали и критерии успешности.

Атрибут Reliability изучается после проработки атрибута Functionality, то есть, тогда, когда изучены потребности пользователей, найдены скрытые возможности и изучены понятные потребности, а также сформулированы JTBD-стейтменты—Key Job Story/Job Stories и Desired Outcomes. Если на этапе проработки Reliability выявляются пробелы, их важно устранить до перехода к дальнейшим этапам (например, до финальной отрисовки дизайна или юзабилити-тестов).

Давайте подробнее разберем весь процесс.

Перед проведением Solution Interview важно определить, какие Desired Outcomes и сценарии критичны для проверки в первую очередь. Поскольку провести интервью бесконечно по всем возможным аспектам не получится, сконцентрируемся на самых существенных.

В результате приоритизации у вас получится список сценариев (ситуаций) для интервью—по одному на каждый избранный подшаг—и набор соответствующих Desired Outcomes, которые будете проверять. Теперь можно переходить к подготовке инструментария.

Для сбора и анализа данных с Solution Interview используем специальную таблицу оценок—таблицу Opportunity Score. Она поможет структурировать ответы пользователей и увидеть, насколько наш концепт улучшает ситуацию по каждой из Desired Outcomes.

Таблица содержит строки с Desired Outcomes, страницы для каждого респондента (обычно 5–8 страниц, по числу интервью) и рассчитанных метрик. В частности, фиксируем следующие показатели для каждого Desired Outcome:

Заполнив такую таблицу по итогам интервью, вы получаете сводку по всем участникам для каждой из Desired Outcomes. Это позволяет наглядно увидеть, где новое решение значительно повысило удовлетворенность, а где—нет.

Заранее занесите в таблицу все выбранные для проверки Desired Outcomes (отдельными строками). Оставьте место для оценок Importance, Satisfaction (до/после). Также можно предусмотреть столбец для комментариев, куда во время интервью будут записываться ключевые комментарии пользователя, объясняющие его оценки—это упростит анализ.

Прототип (или концепт решения)—это то, что вы покажете пользователю в ходе Solution Interview, чтобы собрать его реакцию. Очень важно, чтобы прототип покрывал ключевые Desired Outcomes, выделенные на этапе приоритизации. Пользователь должен иметь возможность попробовать или представить, как решение работает именно в важных для него аспектах.

Прототипом может быть:

Главное: респондент должен понять идею решения и то, как оно адресует его Job Story. Если какого-то элемента в прототипе не окажется (упущен важный Outcome), интервью это вскроет—пользователь может выразить обеспокоенность или сказать, что бы он сделал дополнительно. Это станет сигналом о пробеле в Reliability. Поэтому включите в прототип все функции/механизмы, закрывающие ключевые Desired Outcomes.

Показывать прототип будем пошагово, в контексте отдельных сценариев (подшагов) задачи. Готовясь к интервью, убедитесь, что для каждого сценария у вас есть необходимый экран(ы) или описание. Например, если проверяется сценарий “Измерение текущего процента жира” в фитнес-приложении, прототип должен позволять ввести данные и увидеть результат расчёта процента жира, иначе пользователь не сможет оценить надежность этого шага.

Наконец, протестируйте прототип сами или с коллегами (проведите тестовое интервью), чтобы убедиться в его работоспособности: во время интервью ничего не должно отвлекать пользователя (например, баги или недоразумения с прототипом). Помните, цель—оценить доверие к концепту, а не умение пользователя обращаться с сырым прототипом.

Когда прототип готов, спланируем сценарий Solution Interview—как именно будет проходить сессия, какие вопросы и задания получит пользователь. Интервью на надежность похоже на смесь глубинного интервью и юзабилити-тестирования, но структурировано вокруг проверки определённых сценариев использования.

Для каждого выделенного сценария (подшага) мы проходим последовательность:

Повторяем эту последовательность для каждого важного сценария.

Например, если мы делаем приложение для отслеживания питания спортсменами, набирающими мышечную массу, и там сценарий—“Определение фазы (набор массы или сушка)”, то сначала пользователь скажет, насколько для него важно правильно определить фазу, и насколько он сейчас доволен своим способом определения. Затем мы дадим ему попробовать наш прототип (функцию, которая рекомендует фазу), а после спросим, насколько он доволен тем, как наше решение это делает.

Ниже—шаблон структуры интервью для одного сценария (подшага), который следует повторить для всех ключевых подшагов:

Такой план повторяется для каждого ключевого сценария. На заключительном этапе интервью можно задать общий вопрос: “В целом, как бы вы описали надёжность решения? Решена ли ваша задача полностью?”—это даст целостную оценку. После этого—поблагодарить участника и завершить интервью.

Иногда может оказаться, что у респондента нет опыта с каким-то подшагом (например, он никогда не делал чего-то из вашего сценария). В таком случае пропустите этот сценарий—оставьте в таблице соответствующие поля пустыми, и Priority для этого Outcome автоматически пометится как “Неприменимо”. В наших данных такие пробелы тоже учитываются (таблица должна уметь обозначать, что на некоторые вопросы у пользователя нет ответа).

У сценария интервью есть 4 основные части (они похожи на проведение обычного, стандартного глубинного интервью):

Прежде чем начать интервью, нужно выстроить доверительные отношения с респондентом и показать ему, что с вами можно безопасно общаться. Вы для него—незнакомая личность, и, скорее всего, респондент никогда не принимал участия в исследованиях. Поэтому важно человеку рассказать, что вы от него хотите и что его ждет.

Скрининговые вопросы—это важный этап подготовки к Solution Interview, который обеспечивает релевантность данных и эффективность всего исследования в целом. Если респондент пришел на интервью, но у него будет отсутствовать нужный опыт, мы не получим никакой нерелевантной информации и потеряем время.

Чтобы избежать таких ситуаций, перед тем как начать детально разбирать опыт респондента, необходимо уточнить, обладает ли он нужным опытом. Это можно сделать с помощью следующих двух вопросов:

Эти вопросы помогают быстро и эффективно определить релевантность респондента для текущего исследования. В случае, если у респондента отсутствует необходимый опыт, важно корректно завершить интервью. Вот как это можно сделать:

Этот подход не только сохраняет профессиональные отношения, но и оставляет у респондента положительное впечатление, что может быть полезно для будущих исследований.

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

Дальше можно переходить к демонстрации решения—показу прототипа, и наблюдению за реакциями респондента. Здесь мы проходимся по заданиям, которые составляли в предыдущем шаге (в “Шаблон структуры интервью”), фиксируем оценки важности и удовлетворенности.

Люди любят быть полезными. Даже если интервью прошло не совсем эффективно, я всегда благодарю респондентов за участие и подсвечиваю, что обнаружил для себя много интересных инсайтов. Мне это ничего не стоит, а люди всегда от этого начинают светиться. Более того, это устанавливает доверительный контакт: в этот раз не получилось, но, возможно, в следующем исследовании этот респондент раскроется так, как никто другой. Поэтому важно сохранять с респондентами теплые отношения.

Также я всегда уточняю, можно ли приглашать респондента на другие сессии. Я еще не слышал ответа “нет”, но считаю это хорошей этикой. Например:

Для одной роли (про сегменты и роли можно почитать в атрибуте Functionality) достаточно набирать от 5 до 8 участников. Исследования показывают, что с помощью Solution Interview можно выявить основные проблемы и паттерны поведения уже на первых 5-6 интервью. Дополнительные интервью позволяют подтвердить эти находки и выявить редкие проблемы, но значительный прирост новой информации обычно замедляется после первых 8-10 интервью. Таким образом, 5-8 респондентов—это оптимальное количество для большинства UX-исследований.

Хорошо с этой задачей справляется и AI (chatGPT или DeepSeek). Попросите его сгенерировать разные источники поиска респондентов, а затем начинайте сам поиск нужных вам людей.

На этапе проведения интервью ваша задача—максимально честно выяснить, насколько пользователь доверяет решению. Здесь несколько важных рекомендаций:

Все эти подходы направлены на одно: получить честную, неискажённую картину доверия пользователя к вашему решению.

Даже опытные исследователи могут допустить ошибки, способные снизить ценность результатов. Ниже—чеклист распространённых ошибок, которых следует избегать:

Избежав этих ошибок, вы повысите качество данных и уверенность в выводах по атрибуту Reliability.

После проведения всех интервью наступает момент: нужно понять, подтвердилось ли, что ваш концепт решения надёжен и закрывает задачу пользователя, или же остались проблемные места. Анализ включает как количественную оценку (по таблице Opportunity Score), так и качественную интерпретацию (комментарии, поведение, цитаты пользователей).

Подытоживая: атрибут Reliability подтвержден, когда:

Если эти условия выполняются—смело двигайтесь дальше (к визуализации UI, тестированию удобства и пр.). Если нет—возвращайтесь к доске разработки и устраняйте проблемные места.

При анализе очень полезно классифицировать каждый интервью-кейс на три категории: полное покрытие Job Story, частичное покрытие или отсутствие покрытия. Это фактически отражает уровень доверия пользователя к решению. Рассмотрим признаки каждой ситуации:

Решение полностью закрывает задачу пользователя, и он готов ему доверять на 100%. Признаки полного покрытия:

Если большинство ваших интервью попадают в эту категорию—поздравляем, концепт демонстрирует высокую надёжность. Пользователи готовы полагаться на продукт без страхов и обходных путей. Это и есть цель атрибута Reliability.

Решение закрывает проблему лишь отчасти. Пользователь видит пользу и готов пользоваться в некоторых случаях, но у него остаются оговорки и средний уровень доверия. Признаки частичного покрытия:

Иными словами, решение закрывает часть Job Story, но не охватывает её целиком так, чтобы пользователь забыл о прежних опасениях. Доверие условное: пользователь мог бы использовать продукт и получает от него пользу, но пока не готов полагаться на него полностью.

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

Самая тревожная категория: пользователь фактически говорит, что предложенное решение не решает его задачу или делает это ненадёжно, поэтому он не собирается им пользоваться. Признаки отсутствия покрытия:

Ситуация отсутствия покрытия Job Story означает, что либо мы промахнулись мимо реальных потребностей (решение не про то, что надо пользователю), либо уровень надежности концепта настолько низок, что пользователь не готов им пользоваться даже ради потенциальной выгоды. В любом случае, такие кейсы требуют серьёзного пересмотра концепции. Надо сделать шаг назад: пересмотреть гипотезы, возможно, вернуться к атрибуту Functionality (правильно ли поняли Job Story) или кардинально переделать механизмы, отвечающие за надежность.

При анализе обращайте внимание не только на оценки, но и на сигналы в поведении и словах. Ниже—своего рода чеклист реакций и их интерпретация, чтобы декодировать, что именно пользователь чувствовал.

Сводя воедино, на этапе анализа вы должны составить резюме по каждому интервью: отмечаем, было ли покрытие Job Story полным, частичным или никаким; уровень доверия (высокий/средний/низкий); и перечисляем ключевые причины недоверия (конкретные сомнения, цитаты, неудовлетворённые Outcomes). После этого можно агрегировать результаты по всем интервью и оценить общую картину: например, сколько процентов пользователей полностью доверяют решению, скольким оно приемлемо с оговорками, а сколько его отвергли. Это напрямую поможет приоритизировать дальнейшие улучшения продукта именно по Reliability: вы увидите, какие проблемы наиболее массовые и критичные.

Атрибут Reliability—один из четырех «столпов» UX-качества продукта (наряду с функциональностью, удобством и визуальной привлекательностью). Если убрать один, вся конструкция начинает шататься. Поэтому на ранних этапах разработки крайне важно уделить должное внимание надежности: убедиться, что ваше решение реально покрывает потребности и внушает доверие пользователям. Используя описанный метод (подготовка гипотез, структурированные интервью, анализ с Opportunity Score и качественными признаками), вы получите четкое понимание, насколько ваш продукт надежен в глазах пользователей и что нужно улучшить.

Когда уверенность в Reliability будет достигнута (пользователи говорят: “Это именно то, что решает мою задачу полностью, и я ему доверяю”), можно переходить к следующим аспектам—например, визуальной “полировке”, юзабилити-тестированию и прочим улучшениям. В итоге у вас появится цифровой продукт, который пользователи любят за то, что он решает их задачи полностью, эффективно и приятно—от начала и до конца, без нервов и сомнений. Именно такой продукт имеет все шансы на успех.