The post has been translated automatically. Original language: Russian
The respondent opened the link, answered a few questions, and closed the page. For the team, this looks like "low engagement," although the problem is often not in the audience, but in the survey scenario itself.
Incomplete answers are especially painful for startups and small teams: the sample is already limited, and each lost answer reduces the quality of conclusions. Below are seven reasons that are worth checking out before the next launch.
1. The survey begins without explaining the benefits
The phrase "Take our survey" doesn't tell a person anything about why they should waste their time. It is better to answer four questions briefly on the start screen.: who is conducting the research, why the answers are needed, how long the participation will take, and what will happen to the data.
Bad option:
"Help us become better."
A clearer version:
"We are choosing which features to add to the personal account in the next quarter. The survey will take about three minutes. The answers are analyzed by the product team in a generalized form."
Such an introduction does not promise too much and gives the respondent an understandable context. If the survey is anonymous or, conversely, the answers are linked to the user's profile, this should also be reported before the first question.
2. The team asks for more than they are going to use.
Each question should have a future role: solution, segmentation, hypothesis testing, or a mandatory operational step. If the team can't tell what will change depending on the answer, it's better to remove the question.
A practical way to shorten the questionnaire is to make a table of three columns.:
- question;
- Why do I need an answer?;
- what decision will be made.
An empty third column usually indicates an unnecessary question. GOV.The UK Design System recommends understanding in advance why each question is being asked and requesting only the really necessary information. This principle is useful not only for government services: it directly reduces the burden on the respondent.
3. There are two different topics hidden in one question.
"How satisfied are you with the speed and quality of support?" is a typical double question. The user could quickly receive a weak response or wait a long time for a high-quality consultation. One value on the scale will not allow you to understand what exactly he appreciated.
Separate the wording:
"How quickly did you get the first response?"
- "How useful was the specialist's response?"
Another common problem is the leading formulation: "How convenient was our new interface?" She already assumes that the interface is user-friendly. It's more neutral to ask, "How do you rate the convenience of the new interface?" and give a symmetrical scale.
The Pew Research Center points out that ambiguous and biased questions undermine the quality of data, and the order of questions can influence subsequent answers. Therefore, the questionnaire should be checked not only for individual phrases, but also as a complete script.
4. There are too many required fields.
Being mandatory seems like a way to get a complete set of data. In practice, it creates a point of failure: a person does not want to answer a sensitive question, does not remember the exact meaning, or does not find a suitable option.
Leave only the answers required, without which the result really cannot be used. For the rest, explicitly specify "optional". Where it makes sense, add the options "I don't know", "Not applicable" or "I prefer not to answer".
You should be especially careful about the name, phone number, position, and company name. If this data is needed only for possible contact, it is better to explain it next to the field and separate the consent for communication from the main questionnaire.
5. Open-ended questions require too much effort.
An open answer is useful when you need to hear the client's wording or discover unknown reasons. But five large text fields in a row turn a short survey into a written paper.
A good compromise is to ask a closed—ended question first, and then offer an optional clarification. For example:
"Did you manage to solve the problem?" — "Yes / Partially / No."
"If you want, tell me what was missing."
The open question here gathers details, but does not block the sending of a response. If there are no options yet, you can conduct a small pilot with open questions, highlight recurring topics, and use them to prepare a closed list for the main launch. This approach is also described by the Pew Research Center.
6. The mobile scenario was tested only on a laptop
The link to the survey is often sent via messenger or email and opened on your phone. On a small screen, long matrices, small pressing areas, horizontal scrolling, a keyboard covering the field, and errors that are explained only by color become noticeable.
Minimal mobile verification before launch:
- Take a survey on a real phone, not just shrink the browser window;
- check portrait orientation;
- make sure that the answer options are readable without zooming.;
- check the keyboard operation and the transition between fields;
- trigger every validation error;
- make sure that the meaning of the error is conveyed in text, and not in a single red color.
WCAG 2.2 requires that instructions do not depend solely on the shape, color, size, or location of an element. The standard also does not recommend limiting content to a single screen orientation unless objectively necessary.
7. The respondent does not understand how much is left.
The phrase "just a little more" does not help to assess the effort. For a long scenario, an honest progress indicator or clear steps are more useful: "General questions", "Usage experience", "About you".
But the indicator itself does not correct an overloaded questionnaire. If the scale hardly shifts after answering three questions, the promise of a quick pass begins to work against trust. First shorten the path, then show the progress.
If branching is used, read the path for the different segments separately. A new client can see six questions, and a permanent client can see twelve. The same time estimate will be inaccurate for them.
How to check the survey before publishing
Don't limit yourself to editorial proofreading. Give the completed form to three to five people who were not involved in its creation, and ask them to complete it without prompting. Watch where they stop, reread the question, or choose "other."
After the test, check:
- is the promise clear on the first screen?;
- does the stated time match the actual time?;
- Does each question have a practical purpose?;
- is it possible to skip optional and sensitive questions?;
- are there any double or leading formulations;
- does the form work on the phone;
- are the errors and the next step clear?;
- whether the logic is preserved for different branches of responses.
The Pew Research Center calls pre-testing an essential part of questionnaire design.: It helps you see people's reactions to the entire survey and to individual new questions. For a small team, such a test does not have to be a big study. Even a few playthroughs often reveal problems that the creators of the form have stopped noticing.
A brief conclusion
A low completion rate is not a reason to immediately increase the number of mailings. First, you should remove unnecessary questions, reduce the obligation, rewrite ambiguous wording and go all the way on the phone. A good survey takes care of a person's time and explains in advance why each step is needed.
In Wobidobi, you can create a branded survey, publish it on your own domain, and send responses via CSV, webhook, Slack, or email. You can start with the first scenario on wobidobi.com .
Sources
- GOV.UK Design System, Question pages — design-system.service.gov.uk
- Pew Research Center, Writing Survey Questions — pewresearch.org
- W3C, How to Meet WCAG 2.2 — w3.org
Респондент открыл ссылку, ответил на несколько вопросов — и закрыл страницу. Для команды это выглядит как «низкая вовлечённость», хотя проблема часто находится не в аудитории, а в самом сценарии опроса.
Незавершённые ответы особенно болезненны для стартапов и небольших команд: выборка и без того ограничена, а каждый потерянный ответ снижает качество выводов. Ниже — семь причин, которые стоит проверить до следующего запуска.
1. Опрос начинается без объяснения пользы
Фраза «Пройдите наш опрос» ничего не говорит человеку о том, зачем тратить время. На стартовом экране лучше коротко ответить на четыре вопроса: кто проводит исследование, зачем нужны ответы, сколько времени займёт участие и что произойдёт с данными.
Плохой вариант:
«Помогите нам стать лучше».
Более ясный вариант:
«Мы выбираем, какие функции добавить в личный кабинет в следующем квартале. Опрос займёт около трёх минут. Ответы анализируются продуктовой командой в обобщённом виде».
Такое вступление не обещает лишнего и даёт респонденту понятный контекст. Если опрос анонимный или, наоборот, ответы связаны с профилем пользователя, это также нужно сообщить до первого вопроса.
2. Команда спрашивает больше, чем собирается использовать
У каждого вопроса должна быть будущая роль: решение, сегментация, проверка гипотезы или обязательный операционный шаг. Если команда не может сказать, что изменится в зависимости от ответа, вопрос лучше убрать.
Практический способ сократить анкету — сделать таблицу из трёх колонок:
- вопрос;
- зачем нужен ответ;
- какое решение будет принято.
Пустая третья колонка обычно указывает на лишний вопрос. GOV.UK Design System рекомендует заранее понимать, зачем задаётся каждый вопрос, и запрашивать только действительно необходимую информацию. Этот принцип полезен не только для государственных сервисов: он напрямую уменьшает нагрузку на респондента.
3. В одном вопросе спрятаны две разные темы
«Насколько вы довольны скоростью и качеством поддержки?» — типичный двойной вопрос. Пользователь мог быстро получить слабый ответ или долго ждать качественную консультацию. Одно значение на шкале не позволит понять, что именно он оценил.
Разделите формулировку:
— «Насколько быстро вы получили первый ответ?»
— «Насколько полезным оказался ответ специалиста?»
Ещё одна частая проблема — ведущая формулировка: «Насколько удобным оказался наш новый интерфейс?» Она уже предполагает, что интерфейс удобен. Нейтральнее спросить: «Как вы оцениваете удобство нового интерфейса?» и дать симметричную шкалу.
Pew Research Center обращает внимание, что неоднозначные и смещённые вопросы подрывают качество данных, а порядок вопросов способен влиять на последующие ответы. Поэтому анкету нужно проверять не только по отдельным фразам, но и как цельный сценарий.
4. Слишком много обязательных полей
Обязательность кажется способом получить полный набор данных. На практике она создаёт точку отказа: человек не хочет отвечать на чувствительный вопрос, не помнит точное значение или не находит подходящего варианта.
Оставляйте обязательными только ответы, без которых результат действительно нельзя использовать. Для остальных явно укажите «необязательно». Там, где это логично, добавьте варианты «Не знаю», «Не применимо» или «Предпочитаю не отвечать».
Особенно осторожно стоит относиться к имени, телефону, должности и названию компании. Если эти данные нужны только для возможного контакта, лучше объяснить это рядом с полем и отделить согласие на связь от основной анкеты.
5. Открытые вопросы требуют слишком много усилий
Открытый ответ полезен, когда нужно услышать формулировки клиента или обнаружить неизвестные причины. Но пять больших текстовых полей подряд превращают короткий опрос в письменную работу.
Хороший компромисс — сначала задать закрытый вопрос, а затем предложить необязательное уточнение. Например:
«Удалось ли вам решить задачу?» — «Да / Частично / Нет».
«Если хотите, расскажите, чего не хватило».
Открытый вопрос здесь собирает детали, но не блокирует отправку ответа. Если вариантов ещё нет, можно провести небольшой пилот с открытыми вопросами, выделить повторяющиеся темы и на их основе подготовить закрытый список для основного запуска. Такой подход также описывает Pew Research Center.
6. Мобильный сценарий проверили только на ноутбуке
Ссылка на опрос часто приходит в мессенджере или почте и открывается на телефоне. На маленьком экране становятся заметны длинные матрицы, мелкие области нажатия, горизонтальная прокрутка, клавиатура, закрывающая поле, и ошибки, которые объясняются только цветом.
Минимальная мобильная проверка перед запуском:
- пройти опрос на реальном телефоне, а не только уменьшить окно браузера;
- проверить портретную ориентацию;
- убедиться, что варианты ответа читаются без масштабирования;
- проверить работу клавиатуры и переход между полями;
- вызвать каждую ошибку валидации;
- убедиться, что смысл ошибки передаётся текстом, а не одним красным цветом.
WCAG 2.2 требует, чтобы инструкции не зависели только от формы, цвета, размера или расположения элемента. Стандарт также не рекомендует ограничивать контент одной ориентацией экрана без объективной необходимости.
7. Респондент не понимает, сколько осталось
Формулировка «ещё немного» не помогает оценить усилие. Для длинного сценария полезнее честный индикатор прогресса или понятные этапы: «Общие вопросы», «Опыт использования», «О вас».
Но индикатор сам по себе не исправляет перегруженную анкету. Если после ответа на три вопроса шкала почти не сдвигается, обещание быстрого прохождения начинает работать против доверия. Сначала сократите путь, затем показывайте прогресс.
Если используется ветвление, считайте путь для разных сегментов отдельно. Новый клиент может увидеть шесть вопросов, постоянный — двенадцать. Одинаковая оценка времени для них будет неточной.
Как проверить опрос перед публикацией
Не ограничивайтесь редакторской вычиткой. Дайте готовую форму трём–пяти людям, которые не участвовали в её создании, и попросите пройти её без подсказок. Наблюдайте, где они останавливаются, перечитывают вопрос или выбирают «другое».
После теста проверьте:
- понятно ли обещание на первом экране;
- совпадает ли заявленное время с реальным;
- есть ли у каждого вопроса практическая цель;
- можно ли пропустить необязательные и чувствительные вопросы;
- нет ли двойных или ведущих формулировок;
- работает ли форма на телефоне;
- понятны ли ошибки и следующий шаг;
- сохраняется ли логика при разных ветках ответов.
Pew Research Center называет предварительное тестирование существенной частью проектирования анкеты: оно помогает увидеть реакцию людей и на весь опрос, и на отдельные новые вопросы. Для небольшой команды такой тест не обязан быть большим исследованием. Даже несколько прохождений часто обнаруживают проблемы, которые создатели формы перестали замечать.
Краткий вывод
Низкая доля завершений — не повод сразу увеличивать число рассылок. Сначала стоит убрать лишние вопросы, снизить обязательность, переписать неоднозначные формулировки и пройти весь путь на телефоне. Хороший опрос бережно относится ко времени человека и заранее объясняет, зачем нужен каждый шаг.
В Wobidobi можно собрать брендированный опрос, опубликовать его на собственном домене и передавать ответы через CSV, webhook, Slack или email. Начать с первого сценария можно на wobidobi.com.
Источники
- GOV.UK Design System, Question pages — design-system.service.gov.uk
- Pew Research Center, Writing Survey Questions — pewresearch.org
- W3C, How to Meet WCAG 2.2 — w3.org
