The post has been translated automatically. Original language: Russian
An open question is often added to the questionnaire "just in case." As a result, the team receives dozens of short comments, reads the most emotional ones, and formulates a conclusion from memory. This approach creates the illusion of proximity to the user, but it easily turns a single opinion into a priority for the entire team.
Open answers are not useful on their own. Value appears when the team consistently separates respondents' initial formulations from observations, combines observations into topics, verifies alternative explanations, and only then links conclusions to solutions.
Don't start by counting the words.
A frequent word is not yet a problem, and a rare comment is not necessarily unimportant. For example, the word "long" may refer to registration, waiting for a support response, or uploading a report. If you count it without context, different situations will merge into one.
First, identify the research question. He sets the boundaries of the analysis: "What prevents new users from completing the setup?" more precisely than "What don't people like?". In the first case , the team is looking for obstacles at a specific stage, in the second it risks putting together an unrelated wish list.
What is considered a unit of analysis?
It is better to make the unit of analysis not the entire answer or a single word, but one complete thought. The phrase "The setup is clear, but the invitation from colleagues came too late" contains at least two observations: a clear interface and a delayed invitation.
Dividing responses into separate thoughts helps to avoid assigning only one topic to one comment and avoid losing contradictions within the response.
Prepare a spreadsheet
The first analysis does not require a complex system. A table in which each row corresponds to one thought, rather than one respondent, is sufficient.
Minimum set of columns:
- response ID without name and contacts;
- the original wording or a short precise fragment;
- user path stage;
- code is a brief description of the observed problem or need.;
- A topic is a larger group of related codes;
- a segment, if it is really needed for comparison;
- possible command action;
- degree of confidence and verification questions.
In repeated branded surveys collected in Wobidobi, it is useful to agree in advance on the same field structure and naming rules for research. This makes it easier to compare the results of different launches, and the analyst does not waste time restoring the context of each response.
Go through the five analysis steps
1. Read the entire array before encoding
The first reading is not necessary for conclusions, but for understanding the respondents' language and range of situations. Note unclear terms, contradictions, and possible contexts, but don't create a definitive system of topics after the first five answers.
The CDC recommends starting a qualitative analysis with careful re-reading: this is the only way to preserve the context, which is easily lost when the text is split into codes early.
2. Assign short codes to observations
The code should describe what is in the data, and not immediately offer a solution. For the answer "I did not understand if the questionnaire was saved after closing the tab", the codes "unclear save status" and "doubt after closing the tab" are suitable. The "add green notification" code is already a hypothesis for a solution.
Close codes are allowed on the first pass. After processing part of the array, combine the duplicates and create a short dictionary: the name of the code, its meaning, what to include and what not to include. This is especially important if the answers are marked up by several people.
3. Assemble the codes into themes
Topics should answer the research question and be specific enough to solve. The "Interface issues" group is too broad. The topics "unclear save status," "no confirmation of sending," and "errors are noticed too late" already point to different points on the user's path.
When grouping, it is useful to check two things:
- do the answers within the topic really describe one mechanism of the problem?;
- doesn't the common name hide several different reasons.
GOV.UK recommends first recording observations separately from interpretation, then grouping them by common themes and only then formulating conclusions. This order reduces the risk of adjusting the answers to a pre-selected idea.
4. Look not only for repetitions, but also for differences.
The number of mentions shows the prevalence of the topic only within the resulting array. It does not prove the scale of the problem in the entire audience, especially if the respondents came from the same channel or segment.
Compare the topics between the groups if the segmentation was planned in advance: new and experienced users, independent clients and agencies, mobile and desktop scenarios. Separately, look for answers that contradict the main picture. They may indicate a hidden condition: the problem occurs only with a specific role, device, or stage of work.
5. Turn the topic into a verifiable output
A good conclusion contains context, observation, and consequence. Instead of "Users are uncomfortable with the setup," it's better to write: "New administrators don't understand if the changes have been saved after closing the form, so they repeat the setup or ask for confirmation."
After the withdrawal, commit the following action:
- fix an obvious small problem and measure the result;
- test a hypothesis in an interview or prototype test;
- add a quantitative question to the next survey;
- leave the topic under review if there is not enough data yet.;
- cancel the action if the problem is not related to the product objectives.
Don't turn frequency into priority automatically.
A topic with ten mentions may relate to a cosmetic detail, and a single answer may relate to a blocking error in a rare but critical scenario. To prioritize, add a few more criteria to the frequency:
- severity of the consequences for the user;
- percentage of the affected target segment;
- communication with the key stage of the product;
- the presence of confirmations from analytics, appeals, or interviews;
- the cost and reversibility of the proposed change.
This will not be a "rating of complaints", but a list of hypotheses with a clear basis.
Do a short team check
Before sending the conclusions to the backlog, it is useful to let one colleague independently encode a small part of the responses. The goal is not to completely match the formulations, but to discover vague codes and hidden assumptions.
Questions to check the topic
- Is it possible to show the original answers that confirm the conclusion?
- Are there any comments that contradict it?
- Have we combined different causes under one name?
- Do we understand for which segment and stage the conclusion is correct?
- What additional research can refute our interpretation?
- Does the conclusion imply a specific solution or a follow -up experiment?
Save not only the final topics, but also the code dictionary, controversial solutions, and analysis versions. The CDC views qualitative analysis as an iterative process: codes are refined, conclusions are validated, and alternative explanations are compared with data.
A brief conclusion
Open responses become useful when the team does not retell the most prominent comments, but builds a transparent chain from the source text to the solution. Start with a research question, divide the answers into individual thoughts, create a dictionary of codes, collect topics, check the differences between the segments, and capture the confidence level.
The main result of this analysis is not a beautiful chart or the number of mentions. This is a verifiable output, for which the initial observations, limitations, and the next action of the command are visible.
Sources
Открытый вопрос часто добавляют в анкету «на всякий случай». В результате команда получает десятки коротких комментариев, читает самые эмоциональные из них и формулирует вывод по памяти. Такой подход создаёт иллюзию близости к пользователю, но легко превращает единичное мнение в приоритет для всей команды.
Открытые ответы полезны не сами по себе. Ценность появляется, когда команда последовательно отделяет исходные формулировки респондентов от наблюдений, объединяет наблюдения в темы, проверяет альтернативные объяснения и только после этого связывает выводы с решениями.
Не начинайте с подсчёта слов
Частое слово ещё не является проблемой, а редкий комментарий не обязательно неважен. Например, слово «долго» может относиться к регистрации, ожиданию ответа поддержки или загрузке отчёта. Если посчитать его без контекста, разные ситуации сольются в одну.
Сначала определите исследовательский вопрос. Он задаёт границы анализа: «Что мешает новым пользователям завершить настройку?» точнее, чем «Что людям не нравится?». В первом случае команда ищет препятствия на конкретном этапе, во втором рискует собрать несвязанный список пожеланий.
Что считать единицей анализа
Единицей анализа лучше делать не весь ответ и не отдельное слово, а одну законченную мысль. Фраза «Настройка понятная, но приглашение коллег пришло слишком поздно» содержит как минимум два наблюдения: понятный интерфейс и задержку приглашения.
Разделение ответов на отдельные мысли помогает не присваивать одному комментарию только одну тему и не терять противоречия внутри ответа.
Подготовьте рабочую таблицу
Для первого анализа не нужна сложная система. Достаточно таблицы, в которой каждая строка соответствует одной мысли, а не одному респонденту.
Минимальный набор столбцов:
- идентификатор ответа без имени и контактов;
- исходная формулировка или короткий точный фрагмент;
- этап пользовательского пути;
- код — краткое описание наблюдаемой проблемы или потребности;
- тема — более крупная группа связанных кодов;
- сегмент, если он действительно нужен для сравнения;
- возможное действие команды;
- степень уверенности и вопросы для проверки.
В повторяющихся брендированных опросах, собранных в Wobidobi, полезно заранее договориться об одинаковой структуре полей и правилах именования исследований. Тогда результаты разных запусков проще сравнивать, а аналитик не тратит время на восстановление контекста каждого ответа.
Пройдите пять шагов анализа
1. Прочитайте весь массив до кодирования
Первое чтение нужно не для выводов, а для понимания языка респондентов и диапазона ситуаций. Отмечайте непонятные термины, противоречия и возможные контексты, но не создавайте окончательную систему тем после первых пяти ответов.
CDC рекомендует начинать качественный анализ с внимательного повторного чтения: только так сохраняется контекст, который легко потерять при раннем дроблении текста на коды.
2. Назначьте короткие коды наблюдениям
Код должен описывать то, что есть в данных, а не сразу предлагать решение. Для ответа «Я не понял, сохранилась ли анкета после закрытия вкладки» подойдут коды «неясный статус сохранения» и «сомнение после закрытия вкладки». Код «добавить зелёное уведомление» уже является гипотезой решения.
На первом проходе допустимы близкие коды. После обработки части массива объедините дубли и составьте короткий словарь: название кода, его смысл, что включать и что не включать. Это особенно важно, если ответы размечают несколько человек.
3. Соберите коды в темы
Темы должны отвечать на исследовательский вопрос и быть достаточно конкретными для решения. Группа «Проблемы интерфейса» слишком широкая. Темы «непонятный статус сохранения», «нет подтверждения отправки» и «ошибки замечают слишком поздно» уже указывают на разные точки пользовательского пути.
При группировке полезно проверять две вещи:
- действительно ли ответы внутри темы описывают один механизм проблемы;
- не скрывает ли общее название несколько разных причин.
GOV.UK рекомендует сначала фиксировать наблюдения отдельно от интерпретации, затем группировать их по общим темам и только после этого формулировать выводы. Такой порядок снижает риск подогнать ответы под заранее выбранную идею.
4. Ищите не только повторы, но и различия
Количество упоминаний показывает распространённость темы только внутри полученного массива. Оно не доказывает масштаб проблемы во всей аудитории, особенно если респонденты пришли из одного канала или сегмента.
Сравните темы между группами, если сегментация была запланирована заранее: новые и опытные пользователи, самостоятельные клиенты и агентства, мобильные и десктопные сценарии. Отдельно ищите ответы, которые противоречат основной картине. Они могут указать на скрытое условие: проблема возникает только при определённой роли, устройстве или этапе работы.
5. Превратите тему в проверяемый вывод
Хороший вывод содержит контекст, наблюдение и последствие. Вместо «Пользователям неудобна настройка» лучше написать: «Новые администраторы не понимают, сохранились ли изменения после закрытия формы, поэтому повторяют настройку или обращаются за подтверждением».
После вывода зафиксируйте следующее действие:
- исправить очевидную небольшую проблему и измерить результат;
- проверить гипотезу в интервью или тесте прототипа;
- добавить количественный вопрос в следующий опрос;
- оставить тему в наблюдении, если данных пока недостаточно;
- отказаться от действия, если проблема не связана с целями продукта.
Не превращайте частоту в приоритет автоматически
Тема с десятью упоминаниями может касаться косметической детали, а единичный ответ — блокирующей ошибки в редком, но критичном сценарии. Для приоритизации добавьте к частоте ещё несколько критериев:
- серьёзность последствия для пользователя;
- доля затронутого целевого сегмента;
- связь с ключевым этапом продукта;
- наличие подтверждений из аналитики, обращений или интервью;
- стоимость и обратимость предполагаемого изменения.
Получится не «рейтинг жалоб», а список гипотез с понятным основанием.
Проведите короткую командную проверку
Перед передачей выводов в бэклог полезно дать одному коллеге независимо закодировать небольшую часть ответов. Цель не в полном совпадении формулировок, а в обнаружении размытых кодов и скрытых допущений.
Вопросы для проверки темы
- Можно ли показать исходные ответы, которые подтверждают вывод?
- Есть ли комментарии, которые ему противоречат?
- Не объединили ли мы разные причины под одним названием?
- Понимаем ли мы, для какого сегмента и этапа верен вывод?
- Какое дополнительное исследование способно опровергнуть нашу интерпретацию?
- Следует ли из вывода конкретное решение или следующий эксперимент?
Сохраняйте не только финальные темы, но и словарь кодов, спорные решения и версии анализа. CDC рассматривает качественный анализ как итеративный процесс: коды уточняются, выводы проверяются, а альтернативные объяснения сопоставляются с данными.
Краткий вывод
Открытые ответы становятся полезными, когда команда не пересказывает самые заметные комментарии, а выстраивает прозрачную цепочку от исходного текста до решения. Начните с исследовательского вопроса, разделите ответы на отдельные мысли, создайте словарь кодов, соберите темы, проверьте различия между сегментами и зафиксируйте уровень уверенности.
Главный результат такого анализа — не красивая диаграмма и не количество упоминаний. Это проверяемый вывод, для которого видны исходные наблюдения, ограничения и следующее действие команды.
Источники
Share
